From repenno@cisco.com Mon Jun 3 14:49:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F315811E8130 for ; Mon, 3 Jun 2013 14:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2ojQYBAHHGu for ; Mon, 3 Jun 2013 14:49:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 294EF11E80ED for ; Mon, 3 Jun 2013 14:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=600; q=dns/txt; s=iport; t=1370296038; x=1371505638; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=1e58mITemcI6jFFXrvnSpz10nr/hj+7mSHdsSkH76VY=; b=CoqD3JyC66vpkwEGlEgyqg5gi5L4bVttlMTspSimG/7T9nvJ73Yy5mWb aUhxYvNuUAQ67vNzaIIma2hoypYStQEI6QETQ0J/4shGq/cHTynMRN3dw FT0PMkddXISkjhY56S3MW94OVHTCHeLVaP3Sjo/OHWFje+ImRJqutZAUX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAO8NrVGtJV2d/2dsb2JhbABZgwkwgnW8E4EIFm0HgiUBBB0dUQEaEBQFPRcOAgQbiAUMm0ahAI1lgRE4gndhA5hnkBeBWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,795,1363132800"; d="scan'208";a="218297330" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jun 2013 21:47:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r53Ll895016113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Jun 2013 21:47:08 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 16:47:08 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WGLC on Learn NAT64 PREFIX64s using PCP (http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-02) Thread-Index: AQHOYKPl2FRxXzekIEWx2LLHMjc/bg== Date: Mon, 3 Jun 2013 21:47:08 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040909D968@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907BDAA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.247.80] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D7B214395B1B24AAF7511041BB8BA61@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WGLC on Learn NAT64 PREFIX64s using PCP (http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-02) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:49:37 -0000 This email communicates the start of a new Working Group Last Call for the following draft: Title : Learn NAT64 PREFIX64s using PCP URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-02 Authors: M. Boucadair The WGLC ends May Jun 17th. If this draft is important to your implementation or architecture, now is the last chance to provide comments and request changes. Silence means you agree with everything in it. Beyond general comments, we also need official reviewers for the draft. If you are willing to volunteer, please send an email. Regards, Reinaldo From repenno@cisco.com Mon Jun 3 14:49:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E058211E80ED for ; Mon, 3 Jun 2013 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpL3-USybk7C for ; Mon, 3 Jun 2013 14:49:37 -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 33D8B11E8106 for ; Mon, 3 Jun 2013 14:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=665; q=dns/txt; s=iport; t=1370296058; x=1371505658; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RavzTBd7fMmxmZSZEzHpkR1bgo8rK3KLE++UZqaDM90=; b=gFHCNsOPZrzFXl3qMjHlVNk0cFiR4lInk8Sz6n6/1G6H8E/U2FckDdPh 6+SdQuDEqObsO2S/OrEXX8Y3JlM92cIEZWm+s1q6dbnFWM5HJJxNimrIW ELJWDyrSIUqCHyQqOvzy88YiBtW466hLXGEhqTuNa2E1Eg5ny5+t4JXQY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8FAKQOrVGtJV2c/2dsb2JhbABZgwkwgnW8E4EIFm0HgiUBBB0dUQEaEBRCFxAEG4gFDJtHoQGNZYERgy9hA5hnkBeBWIE3gXE2 X-IronPort-AV: E=Sophos;i="4.87,795,1363132800"; d="scan'208";a="218278883" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jun 2013 21:47:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53LlbIA029007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Jun 2013 21:47:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 16:47:37 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-01) Thread-Index: AQHOYKP2k2fyrZe6G0i/BJKuhhw5cg== Date: Mon, 3 Jun 2013 21:47:36 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040909D979@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.247.80] Content-Type: text/plain; charset="us-ascii" Content-ID: <89332BC5CCC18248ACCE1782900156F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-01) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:49:55 -0000 This email communicates the start of a new Working Group Last Call for the following draft: Title : PCP Description Option URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-0 1 Authors: M. Boucadair et al. The WGLC ends Jun 17th. If this draft is important to your implementation or architecture, now is the last chance to provide comments and request changes. Silence means you agree with everything in it. Beyond general comments, we also need official reviewers for the draft. If you are willing to volunteer, please send an email. Regards, Reinaldo From mohamed.boucadair@orange.com Tue Jun 4 03:42:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7789B21F9C77 for ; Tue, 4 Jun 2013 03:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhfdQ0LcUdmO for ; Tue, 4 Jun 2013 03:42:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 33DCA21F9AB9 for ; Tue, 4 Jun 2013 02:39:15 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DA7B83B472E; Tue, 4 Jun 2013 11:39:13 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B00EB35C065; Tue, 4 Jun 2013 11:39:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 4 Jun 2013 11:39:13 +0200 From: To: pcp issue tracker , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" , "ssenthil@cisco.com" Date: Tue, 4 Jun 2013 11:39:12 +0200 Thread-Topic: [pcp] #63: Handling multiple prefixes Thread-Index: Ac5eUcWLojvgUmY4SxafcmilHZ637ACnZOLg Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CCFCA0@PUEXCB1B.nanterre.francetelecom.fr> References: <087.ac7253502d63a2734c727a805a0fb5f7@tools.ietf.org> In-Reply-To: <087.ac7253502d63a2734c727a805a0fb5f7@tools.ietf.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:42:48 -0000 SGkgU2VudGhpbCwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KDQpUaGUgY3VycmVudCB0 ZXh0IHNheXMgdGhlIGZvbGxvd2luZzoNCg0KICAgV2hlbiBtdWx0aXBsZSBwcmVmaXhlcyBhcmUg Y29uZmlndXJlZCBpbiBhIG5ldHdvcmssIHRoZSBQQ1Agc2VydmVyDQogICBNQVkgYmUgY29uZmln dXJlZCB0byByZXR1cm4gbXVsdGlwbGUgUFJFRklYNjQgb3B0aW9ucyBpbiB0aGUgc2FtZQ0KICAg bWVzc2FnZSB0byB0aGUgUENQIGNsaWVudC4gIFRoZSBQQ1Agc2VydmVyIGluY2x1ZGVzIGluIHRo ZSBmaXJzdA0KICAgUFJFRklYNjQgb3B0aW9uLCB3aGljaCBhcHBlYXJzIGluIHRoZSBQQ1AgbWVz c2FnZSBpdCBzZW5kcyB0byB0aGUgUENQDQogICBjbGllbnQsIHRoZSBwcmVmaXggdG8gcGVyZm9y bSBsb2NhbCBJUHY2IGFkZHJlc3Mgc3ludGhlc2lzIFtSRkM2MDUyXS4NCiAgIFJlbWFpbmluZyBQ UkVGSVg2NCBvcHRpb25zIGNvbnZleSBhbnkgb3RoZXIgUHJlZjY0OjovbiB2YWx1ZXMNCiAgIGNv bmZpZ3VyZWQgLiBSZXR1cm5pbmcgdGhlc2UgcHJlZml4ZXMgYWxsb3dzIGFuIGVuZCBob3N0IHRv IGlkZW50aWZ5DQogICB0aGVtIGFzIHRyYW5zbGF0ZWQgYWRkcmVzc2VzLCBhbmQgaW5zdGVhZCBw cmVmZXIgSVB2NCBvciBhbg0KICAgYWx0ZXJuYXRpdmUgbmV0d29yayBpbnRlcmZhY2UgaW4gb3Jk ZXIgdG8gYXZvaWQgYW55IE5BVDY0IGRlcGxveWVkIGluDQogICB0aGUgbmV0d29yay4NCg0KRG9l c24ndCB0aGlzIHRleHQgc29sdmVzIHlvdXIgY29uY2Vybj8gT3IgeW91IHRoaW5rIG1vcmUgZWxh Ym9yYXRpb24gaXMgbmVlZGVkPw0KDQpDaGVlcnMsDQpNZWQNCg0KDQo+LS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+RGXCoDogcGNwIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xz LmlldGYub3JnXQ0KPkVudm95w6nCoDogc2FtZWRpIDEganVpbiAyMDEzIDAwOjU0DQo+w4DCoDog ZHJhZnQtaWV0Zi1wY3AtbmF0NjQtcHJlZml4NjRAdG9vbHMuaWV0Zi5vcmc7IHNzZW50aGlsQGNp c2NvLmNvbQ0KPkNjwqA6IHBjcEBpZXRmLm9yZw0KPk9iamV0wqA6IFtwY3BdICM2MzogSGFuZGxp bmcgbXVsdGlwbGUgcHJlZml4ZXMNCj4NCj4jNjM6IEhhbmRsaW5nIG11bHRpcGxlIHByZWZpeGVz DQo+DQo+IFRoZSBvbmx5IGNvbW1lbnQgSSBoYXZlIGlzIHRoaXMgZG9jdW1lbnQgZG9lc24ndCBh ZGRyZXNzIHRoZSBtdWx0aXBsZQ0KPiBwcmVmaXhlcyB0aGF0IGNvdWxkIGJlIHByZXNlbnQgb24g YSBOQVQ2NCBkZXZpY2UuDQo+IEFueSBndWlkZWxpbmVzIG9uIHdoaWNoIHByZWZpeCBzaG91bGQg YmUgcmVwb3J0ZWQgd291bGQgYmUgdXNlZnVsLg0KPg0KPi0tDQo+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IFJlcG9ydGVyOiAgU2VudGhpbCBTaXZha3VtYXIgICAgICAgIHwgICAgICBPd25lcjogIGRy YWZ0LWlldGYtcGNwLQ0KPiAgKHNzZW50aGlsKSA8c3NlbnRoaWxAY2lzY28uY29tPiAgICB8ICBu YXQ2NC1wcmVmaXg2NEB0b29scy5pZXRmLm9yZw0KPiAgICAgVHlwZTogIGRlZmVjdCAgICAgICAg ICAgICAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCj4gUHJpb3JpdHk6ICBtYWpvciAgICAgICAg ICAgICAgICAgICAgfCAgTWlsZXN0b25lOg0KPkNvbXBvbmVudDogIG5hdDY0LXByZWZpeDY0ICAg ICAgICAgICB8ICAgIFZlcnNpb246DQo+IFNldmVyaXR5OiAgLSAgICAgICAgICAgICAgICAgICAg ICAgIHwgICBLZXl3b3JkczoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5UaWNrZXQgVVJMOiA8 aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcGNwL3RyYWMvdGlja2V0LzYzPg0KPnBjcCA8 aHR0cDovL3Rvb2xzLmlldGYub3JnL3BjcC8+DQoNCg== From simon.perreault@viagenie.ca Tue Jun 4 06:30:27 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8921F9B6B for ; Tue, 4 Jun 2013 06:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRvh8vE+IsF5 for ; Tue, 4 Jun 2013 06:30:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4751A21F9B93 for ; Tue, 4 Jun 2013 04:57:18 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ADDFF40402 for ; Tue, 4 Jun 2013 07:57:17 -0400 (EDT) Message-ID: <51ADD61C.1040106@viagenie.ca> Date: Tue, 04 Jun 2013 13:57:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pcp@ietf.org" References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> In-Reply-To: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:30:27 -0000 WG, He have published a new draft in SOFTWIRE describing how a Lightweight 4over6 CPE can use PCP for provisioning. It makes use of the PORT_SET extension. In this WG we're looking for feedback specific to our proposed usage of PCP. Is it correct or is it fatally flawed? Could it be improved? Anything PCP-specific that we should have considered? If you would like to comment on the high-level softwire framework, please use softwire@ietf.org instead. Thanks, Simon -------- Message original -------- Sujet: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Date : Tue, 04 Jun 2013 01:54:06 -0700 De : internet-drafts@ietf.org Pour : Chongfeng Xie , Cathy Zhou , Simon Perreault A new version of I-D, draft-perreault-softwire-lw4over6-pcp-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Filename: draft-perreault-softwire-lw4over6-pcp Revision: 00 Title: Provisioning Lightweight 4over6 (lw4o6) with the Port Control Protocol (PCP) Creation date: 2013-06-03 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-perreault-softwire-lw4over6-pcp-00.txt Status: http://datatracker.ietf.org/doc/draft-perreault-softwire-lw4over6-pcp Htmlized: http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00 Abstract: This memo defines the procedures that a Lightweight B4 uses for provisioning its parameters with the Port Control Protocol. The IETF Secretariat From mohamed.boucadair@orange.com Tue Jun 4 09:57:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC2021F9A87 for ; Tue, 4 Jun 2013 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAhjSCU9ZhuV for ; Tue, 4 Jun 2013 09:57:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4A21F9A84 for ; Tue, 4 Jun 2013 07:44:58 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 50DD9324AC9; Tue, 4 Jun 2013 16:44:57 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 32DA035C0BC; Tue, 4 Jun 2013 16:44:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 4 Jun 2013 16:44:56 +0200 From: To: Dave Thaler Date: Tue, 4 Jun 2013 16:44:55 +0200 Thread-Topic: Comments on draft-ietf-pcp-nat64-prefix64-02 Thread-Index: Ac5eXnzFuvsf6bqRT0e9D2Vte/Z4hAC03IHw Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CCFE93@PUEXCB1B.nanterre.francetelecom.fr> References: <4ca214b2e2264f409935b918f6b71ab2@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: <4ca214b2e2264f409935b918f6b71ab2@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ED4CCFE93PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:57:32 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ED4CCFE93PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Thank you for the review. I accepted most of your proposed modifications. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave = Thaler Envoy=E9 : samedi 1 juin 2013 02:34 =C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org Cc : pcp@ietf.org Objet : [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02 Looks pretty good. My marked up copy is at http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.pdf (or for those who can use .docx: http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.doc= x). Summary: 1) Text appears contradictory as to whether remembering which server a= Pref64 was from is required or just a SHOULD. My preference is to change the SHOUL= D to a MUST, and then the rest of the text is fine. 2) Add reference to draft-ietf-behave-nat64-discovery-heuristic and ex= plain what cases this handles that the simple heuristic cannot. 3) Steal a few phrases from draft-ietf-behave-nat64-discovery-heuristi= c that are applicable here too. 4) Various grammatical corrections/suggestions. -Dave --_000_94C682931C08B048B7A8645303FDC9F36ED4CCFE93PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,<= /span>

 

Thank you for the review.

I accepted most of your proposed modifications.

=

 

Med

 

De : pcp-bounce= s@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave ThalerEnvoy=E9 : samedi 1 juin 2013 02:34
=C0 : draf= t-ietf-pcp-nat64-prefix64@tools.ietf.org
Cc : pcp@ietf.orgObjet : [pcp] Comments on draft-ietf-pcp-nat64-prefix64-02

 

Looks pretty good.  My marked up= copy is at

http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-pref= ix64-02.pdf

(or for those who can use .docx:

http://research.microsoft.com/~dthaler/d= raft-ietf-pcp-nat64-prefix64-02.docx).

 

Summary:

1)&= nbsp;     Text appears contra= dictory as to whether remembering which server a Pref64

was from is required or ju= st a SHOULD. My preference is to change the SHOULD

to a MUST, and then the rest of= the text is fine.

2)  &n= bsp;   Add reference to draft-ietf-beha= ve-nat64-discovery-heuristic and explain what

cases this handles that the simple h= euristic cannot.

3)  &nbs= p;   Steal a few phrases from draft-iet= f-behave-nat64-discovery-heuristic that are

applicable here too.

4)      Various grammatical corrections/suggestions.

=

 

=

-Dave

= --_000_94C682931C08B048B7A8645303FDC9F36ED4CCFE93PUEXCB1Bnante_-- From ssenthil@cisco.com Tue Jun 4 13:07:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6478D21F96C6 for ; Tue, 4 Jun 2013 13:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOGsTRC8MAmD for ; Tue, 4 Jun 2013 13:06:57 -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 7939A21F9A9F for ; Tue, 4 Jun 2013 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1370372829; x=1371582429; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kOmemgJKxgpo3za/y1TefLXWrWP5SfX4T0pv1OaRA4w=; b=jRP2vbYm/1EaduIGkJieJHb84t9Sogr2u3zb4PPm8Na/X/w3VvQCyFTp DFui2hFWHU4/LrICDyGjn0cxipfJInJhjBGei0H0UgWRVW+iCqmlk+CdS iwsxQcHUDLbEpWHtcKVZxnNsgEuI0UhVAXe8DYSwY4yFa9RRRA1onm8sp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMI5rlGtJV2a/2dsb2JhbABQCoMJML8pexZ0giUBBHkSAQgiHTkUEQIEAQ0FCIgFDL1ijWgUdzEHgnphA4hoiwWEe4p3hSCDD4In X-IronPort-AV: E=Sophos;i="4.87,801,1363132800"; d="scan'208";a="218734803" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jun 2013 19:07:02 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r54J72Fx001662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Jun 2013 19:07:02 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 14:07:01 -0500 From: "Senthil Sivakumar (ssenthil)" To: "mohamed.boucadair@orange.com" , "pcp issue tracker" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Thread-Topic: [pcp] #63: Handling multiple prefixes Thread-Index: AQHOXlHExdMnhekn80OxiNm3pUsvuJklpesAgABblgA= Date: Tue, 4 Jun 2013 19:07:01 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CCFCA0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.112] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7DD363353DF3C2429FDCEB899BE1907A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 20:07:03 -0000 Hi Med, On 6/4/13 5:39 AM, "mohamed.boucadair@orange.com" wrote: >Hi Senthil, > >Thank you for the review. > >The current text says the following: > > When multiple prefixes are configured in a network, the PCP server > MAY be configured to return multiple PREFIX64 options in the same > message to the PCP client. The PCP server includes in the first > PREFIX64 option, which appears in the PCP message it sends to the PCP > client, the prefix to perform local IPv6 address synthesis [RFC6052]. > Remaining PREFIX64 options convey any other Pref64::/n values > configured . Returning these prefixes allows an end host to identify > them as translated addresses, and instead prefer IPv4 or an > alternative network interface in order to avoid any NAT64 deployed in > the network. > >Doesn't this text solves your concern? Or you think more elaboration is >needed? I have two questions/comments about this text. 1. How should the server order these prefixes? 2.How does the server know which prefix should be the first prefix handed to the requesting client? Thanks Senthil > >Cheers, >Med > > >>-----Message d'origine----- >>De : pcp issue tracker [mailto:trac@tools.ietf.org] >>Envoy=E9 : samedi 1 juin 2013 00:54 >>=C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org; ssenthil@cisco.com >>Cc : pcp@ietf.org >>Objet : [pcp] #63: Handling multiple prefixes >> >>#63: Handling multiple prefixes >> >> The only comment I have is this document doesn't address the multiple >> prefixes that could be present on a NAT64 device. >> Any guidelines on which prefix should be reported would be useful. >> >>-- >>-------------------------------------+----------------------------------- >>-- >> Reporter: Senthil Sivakumar | Owner: draft-ietf-pcp- >> (ssenthil) | nat64-prefix64@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >>Component: nat64-prefix64 | Version: >> Severity: - | Keywords: >>-------------------------------------+----------------------------------- >>-- >> >>Ticket URL: >>pcp > From cheshire@apple.com Tue Jun 4 16:40:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7221F8EEA for ; Tue, 4 Jun 2013 16:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18ujHoBEjKYF for ; Tue, 4 Jun 2013 16:40:39 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2B21F8EF2 for ; Tue, 4 Jun 2013 16:40:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNW00FXR72I9VA1@mail-out.apple.com> for pcp@ietf.org; Tue, 04 Jun 2013 16:39:58 -0700 (PDT) X-AuditID: 1180715a-b7f506d000007d18-f1-51ae7acea524 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B1.CE.32024.ECA7EA15; Tue, 04 Jun 2013 16:39:58 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNW00C0072MGL30@spicerack.apple.com> for pcp@ietf.org; Tue, 04 Jun 2013 16:39:58 -0700 (PDT) From: Stuart Cheshire Message-id: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Date: Tue, 04 Jun 2013 16:39:58 -0700 To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42IRbCjW0D1XtS7QYP8tGYvJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+XKx+wFy3gq2o6tYGtgvMrZxcjJISFgIvGl9xMzhC0mceHe ejYQW0hgMpPEwlm+XYxcQPYKJonDW08wgiTYBLQkXny+AlbEDGSv33mcCcLWlnjy7gIriC0s oCKxa9U+MJtXwEaic+cNMJtFQFXiwamLYPUiAooSB7bdYIeo0ZPYNncbG8QRshKvn79hmcDI OwvJillIVsxC0rKAkXkVo0BRak5ipZleYkFBTqpecn7uJkZwwBRG7WBsWG51iFGAg1GJh/fB p7WBQqyJZcWVuYcYJTiYlUR4QxPWBQrxpiRWVqUW5ccXleakFh9ilOZgURLnXScHlBJITyxJ zU5NLUgtgskycXBKNTCa3Jy2o9tM7VVFrOjtcA9eqdUXtm8yW7048tTe1T0vb7uuu9Jp/4jb 1Dv+X0bIMhHbLV/asi8aFDVPX8j6wbStfltdQXWDtW57hef3LV83Ft4x+bq7uMTW2Eba8aXE rT9zvwd84vpx+kzlrbtf/DfE5H15sf1U460rnmkyX81LFkx+vGlFiPkPJZbijERDLeai4kQA lhvT7xQCAAA= Subject: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 23:40:45 -0000 It looks like we're starting to accumulate a growing list of issues to document in an addendum to RFC 6887. If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match an existing explicit dynamic mapping, but the mapping nonce does not match, the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each explicit dynamic mapping. Here's the problem: 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins. 2. Client reboots, or similar, and picks new nonce. 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins. 4. NOT_AUTHORIZED! And now the client is locked out of listening on its own TCP port 22 for the next 24 hours. Ironically, it *does* still have an external address and port mapped to its internal TCP port 22 -- but the NAT gateway won't tell it *what* external address and port, making it not very useful. I think we need to remove the server nonce check. If the client asks for a mapping to 10.0.0.2:22, and there is in fact *already* a mapping to 10.0.0.2:22, the the server should say so, and not pretend otherwise. And if the server were to delete the old mapping in this situation, it creates an easy DoS attack were someone can delete your mapping just by trying to renew it with the wrong nonce. Stuart Cheshire From repenno@cisco.com Tue Jun 4 17:06:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51221F9A2C for ; Tue, 4 Jun 2013 17:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLcKAcS-SXf1 for ; Tue, 4 Jun 2013 17:06:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 29EBD21F9A30 for ; Tue, 4 Jun 2013 17:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2590; q=dns/txt; s=iport; t=1370390797; x=1371600397; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Qeprh1B/GpO2E7DCaoO64Uk3B0MhuA7Csn9UdEy/63M=; b=b4ELzIdSR76K2oo1YqvyNNLpvLtk4MB77ueVtMOV0345hOXipcKQE67E uJiZEinVoBX16glescwxcHvQ482Uke4uohWF/WBOzOwLZO9Wx9iWnW6Sp xVrOyI46NtLywZXBJ5PaWXxMsQKMZqWCNNsqVqVJ679o+2G604iyQVHL0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACiArlGtJXHB/2dsb2JhbABSCIMJML8qfhZ0giUBBAEBATc0HQEIIhQ3CyUCBAESCIgFDL1yjW6BBTiCemEDmGiQF4MPgWokGQ X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="218859162" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jun 2013 00:06:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5506aRg014171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 00:06:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:06:35 -0500 From: "Reinaldo Penno (repenno)" To: Stuart Cheshire , "pcp@ietf.org" Thread-Topic: [pcp] Problem with nonce checking Thread-Index: AQHOYXzyOPbrxwGqNk6eMhTg3IquF5kmX6EA Date: Wed, 5 Jun 2013 00:06:35 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A04CF@xmb-rcd-x04.cisco.com> In-Reply-To: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.247.141] Content-Type: text/plain; charset="us-ascii" Content-ID: <820E61D6065FA545BA2019EBD6EA8AA9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 00:06:43 -0000 Hi Stuart, I think this scenario is not new, but now more people are getting more operational experience and bring more voices to the discussions. This specific scenario was discussed on this list a few times. Med and I documented on http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 under "PCP Client crash". "If the PCP Client does not store the explicit dynamic mappings and new Mapping Nonces are assigned, the PCP Server will reject to refresh these mappings. Proposed Action: This issue can be solved if the PCP Client uses GET OpCode (Appendix B) to recover the mapping nonces used when instantiating the mappings if PCP authentication is used or Mapping Nonce validation check is disabled. " Thanks, Reinaldo On 6/4/13 8:39 PM, "Stuart Cheshire" wrote: >It looks like we're starting to accumulate a growing list of issues to >document in an addendum to RFC 6887. > > If operating in the Simple Threat Model (Section 18.1), and the > internal port, protocol, and internal address match an existing > explicit dynamic mapping, but the mapping nonce does not match, the > request MUST be rejected with a NOT_AUTHORIZED error with the > lifetime of the error indicating duration of that existing mapping. > The PCP server only needs to remember one Mapping Nonce value for > each explicit dynamic mapping. > >Here's the problem: > >1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh >logins. >2. Client reboots, or similar, and picks new nonce. >3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive >ssh logins. >4. NOT_AUTHORIZED! > >And now the client is locked out of listening on its own TCP port 22 for >the next 24 hours. Ironically, it *does* still have an external address >and port mapped to its internal TCP port 22 -- but the NAT gateway won't >tell it *what* external address and port, making it not very useful. > >I think we need to remove the server nonce check. > >If the client asks for a mapping to 10.0.0.2:22, and there is in fact >*already* a mapping to 10.0.0.2:22, the the server should say so, and not >pretend otherwise. > >And if the server were to delete the old mapping in this situation, it >creates an easy DoS attack were someone can delete your mapping just by >trying to renew it with the wrong nonce. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Tue Jun 4 18:11:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D6321F9A28 for ; Tue, 4 Jun 2013 18:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CigFhlwGYcSv for ; Tue, 4 Jun 2013 18:11:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB821F9A12 for ; Tue, 4 Jun 2013 18:11:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9A20E20629; Tue, 4 Jun 2013 21:07:46 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZGdHFTqXYyU; Tue, 4 Jun 2013 21:07:43 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 4 Jun 2013 21:07:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E9AE4498; Tue, 4 Jun 2013 21:11:12 -0400 (EDT) From: Sam Hartman To: Stuart Cheshire References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Date: Tue, 04 Jun 2013 21:11:12 -0400 In-Reply-To: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> (Stuart Cheshire's message of "Tue, 04 Jun 2013 16:39:58 -0700") 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] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 01:11:24 -0000 >>>>> "Stuart" == Stuart Cheshire writes: we added the nonce to avoid introducing security attacks against PCP. We explicitly realized that we were making certain usability issues more difficult; I believe we had explicit discussion of approximately this issue when we discussed removing the ability to flush mappings under the simple threat model. I have two recommendations: 1) make it easier for the client to retrieve the existing mapping (but not learn the nonce). We'd need to do security analysis of that but I think it's OK. 2) Implement authentication. Once you have an MTI security mechanism and are giving your users an option, it seems reasonable to relax the configuration when your users do not choose to turn onauthentication. This particular relaxation seems like one of the more common cases that should come up when advanced threat model is used with auth disabled. however I do not support changing our minds about what the simple threat model means. If the simple threat model really is unworkable, I'd support replacing PCP with a new version including a MTI security mechanism. --Sam From dwing@cisco.com Tue Jun 4 19:32:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F09D21F9A97 for ; Tue, 4 Jun 2013 19:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElElpMXe5liK for ; Tue, 4 Jun 2013 19:32:21 -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 64D0E21F9B0D for ; Tue, 4 Jun 2013 19:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1370399248; x=1371608848; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zm0/T6zuDqnUM3ARZy1RYXNvDyMB20nfjsl2kdA6z3I=; b=XdiYbA2ubjoGFiysJv4zfop6WyH7vJoyAuHprytIQWLI7yGXDcSfcUIP Th5lOk1BjEsTVk0xqVhnrOpc63F8BStJiJRKlS7W/aSkOPKSZVY2Eo0On cFfzNpLYWRAOfPUMuq7FngXS1MqMpTsqQtKeR/fm/mGxcBz9SVxzarcrF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAC6hrlGrRDoG/2dsb2JhbABSCIMJML8qgQAWdIIjAQEBAwEBAQE3NAsFCwtGJzAGE4gHBQ29RgSNboEDMweCemEDiSCOH4YeiyKDLxw X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="79759665" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 05 Jun 2013 02:27:00 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r552QxnJ008068; Wed, 5 Jun 2013 02:26:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Date: Tue, 4 Jun 2013 19:26:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <05D1C90B-5B1B-40D3-8EE3-FEC22D48FC4C@cisco.com> References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1503) Cc: "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 02:32:25 -0000 On Jun 4, 2013, at 4:39 PM, Stuart Cheshire wrote: > It looks like we're starting to accumulate a growing list of issues to = document in an addendum to RFC 6887. >=20 > If operating in the Simple Threat Model (Section 18.1), and the > internal port, protocol, and internal address match an existing > explicit dynamic mapping, but the mapping nonce does not match, the > request MUST be rejected with a NOT_AUTHORIZED error with the > lifetime of the error indicating duration of that existing mapping. > The PCP server only needs to remember one Mapping Nonce value for > each explicit dynamic mapping. >=20 > Here's the problem: >=20 > 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive = ssh logins. > 2. Client reboots, or similar, and picks new nonce. Can the client remember its nonce across reboots, or similar? -d > 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can = receive ssh logins. > 4. NOT_AUTHORIZED! >=20 > And now the client is locked out of listening on its own TCP port 22 = for the next 24 hours. Ironically, it *does* still have an external = address and port mapped to its internal TCP port 22 -- but the NAT = gateway won't tell it *what* external address and port, making it not = very useful. >=20 > I think we need to remove the server nonce check. >=20 > If the client asks for a mapping to 10.0.0.2:22, and there is in fact = *already* a mapping to 10.0.0.2:22, the the server should say so, and = not pretend otherwise. >=20 > And if the server were to delete the old mapping in this situation, it = creates an easy DoS attack were someone can delete your mapping just by = trying to renew it with the wrong nonce. >=20 > Stuart Cheshire >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Tue Jun 4 19:32:34 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8287421F9B19 for ; Tue, 4 Jun 2013 19:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Pp4hiQ4Mp3 for ; Tue, 4 Jun 2013 19:32:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 957B421F9A98 for ; Tue, 4 Jun 2013 19:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1370399249; x=1371608849; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tbU/Z3N5Z+cpfX2mSSKZua1/trjJyZmZfmN3exFzfLU=; b=XTifQZG4Zs5cAivpFU14twtRwg3+OjZQj27P4eouPCzXrMvWAtLiB+q7 BLKklMh+LQS6tDfy3m0Np0WtdvNmpzDoq/yxRpTUKSd3YZN4I/GcdDQbq lMUJA0noU8DfhCIs7MwUWXV8FzfbsHR0kJC6RAsvilTlj3qPEqwo9R4wx U=; X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="82779287" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 05 Jun 2013 02:27:04 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r552QxnK008068; Wed, 5 Jun 2013 02:27:03 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A04CF@xmb-rcd-x04.cisco.com> Date: Tue, 4 Jun 2013 19:27:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84B3321A-0FB6-4946-A3DF-D53DD6DBA618@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A04CF@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1503) Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 02:32:34 -0000 On Jun 4, 2013, at 5:06 PM, Reinaldo Penno (repenno) = wrote: > Hi Stuart, >=20 > I think this scenario is not new, but now more people are getting more > operational experience and bring more voices to the discussions. >=20 > This specific scenario was discussed on this list a few times. >=20 > Med and I documented on > http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 under > "PCP Client crash". >=20 > "If the PCP Client does not store the explicit dynamic mappings and > new Mapping Nonces are assigned, the PCP Server will reject to > refresh these mappings. >=20 > Proposed Action: This issue can be solved if the PCP Client uses > GET OpCode (Appendix B) to recover the mapping nonces used when > instantiating the mappings if PCP authentication is used or > Mapping Nonce validation check is disabled. > " That destroys the security protection of Nonce. visitor: Let me into the castle. guard: To enter the castle, tell me the password. visitor: Ok. What is the password? guard: 385932 visitor: Let me in to the castle. guard: To enter the castle, tell me the password. visitor: 385932 guard: Didn't Monte Python do that skit? -d >=20 >=20 >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > On 6/4/13 8:39 PM, "Stuart Cheshire" wrote: >=20 >> It looks like we're starting to accumulate a growing list of issues = to >> document in an addendum to RFC 6887. >>=20 >> If operating in the Simple Threat Model (Section 18.1), and the >> internal port, protocol, and internal address match an existing >> explicit dynamic mapping, but the mapping nonce does not match, the >> request MUST be rejected with a NOT_AUTHORIZED error with the >> lifetime of the error indicating duration of that existing mapping. >> The PCP server only needs to remember one Mapping Nonce value for >> each explicit dynamic mapping. >>=20 >> Here's the problem: >>=20 >> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive = ssh >> logins. >> 2. Client reboots, or similar, and picks new nonce. >> 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can = receive >> ssh logins. >> 4. NOT_AUTHORIZED! >>=20 >> And now the client is locked out of listening on its own TCP port 22 = for >> the next 24 hours. Ironically, it *does* still have an external = address >> and port mapped to its internal TCP port 22 -- but the NAT gateway = won't >> tell it *what* external address and port, making it not very useful. >>=20 >> I think we need to remove the server nonce check. >>=20 >> If the client asks for a mapping to 10.0.0.2:22, and there is in fact >> *already* a mapping to 10.0.0.2:22, the the server should say so, and = not >> pretend otherwise. >>=20 >> And if the server were to delete the old mapping in this situation, = it >> creates an easy DoS attack were someone can delete your mapping just = by >> trying to renew it with the wrong nonce. >>=20 >> Stuart Cheshire >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Tue Jun 4 19:33:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6583B21F9B0E for ; Tue, 4 Jun 2013 19:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PcIOBUgW0GW for ; Tue, 4 Jun 2013 19:33:14 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF221F9A27 for ; Tue, 4 Jun 2013 19:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1626; q=dns/txt; s=iport; t=1370399411; x=1371609011; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NqNy/qICBcP5vuSv/M66Z1DPRm3BJfVNj9EKLdobY3k=; b=AfmVERHn+vha+PwWuVEA5pjERZikeE5QB2CzXBM0VdR3AkDQeRU6gkCv Z7xWTna+CkMJotekDiHLEeqSzqKdHDP7eUdJeMubXbVLFnwo2CcGk0Dx/ R9pcHq8CmYML1WslRmb4wkpCjpzuthersV2TKjWMoIwbmjzjzLzkuj8DV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAACirlGrRDoI/2dsb2JhbABagwkwvyqBABZ0giMBAQEDAQEBATc0CwULC0YnMAYTiAcFDb1DBI5xMweCemEDiSCOH4YeiyKDLxw X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="82779359" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 05 Jun 2013 02:29:47 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r552TkDV019568; Wed, 5 Jun 2013 02:29:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Tue, 4 Jun 2013 19:29:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> To: Sam Hartman X-Mailer: Apple Mail (2.1503) Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 02:33:18 -0000 On Jun 4, 2013, at 6:11 PM, Sam Hartman = wrote: >>>>>> "Stuart" =3D=3D Stuart Cheshire writes: >=20 >=20 > we added the nonce to avoid introducing security attacks against PCP. > We explicitly realized that we were making certain usability issues = more > difficult; I believe we had explicit discussion of approximately this > issue when we discussed removing the ability to flush mappings under = the > simple threat model. >=20 > I have two recommendations: >=20 > 1) make it easier for the client to retrieve the existing mapping (but > not learn the nonce). > We'd need to do security analysis of that but I think it's OK. I like that approach to retrieve the existing mapping. Seems that = solves Stuart's case without adding new burden for storing state on the = client. -d > 2) Implement authentication. Once you have an MTI security mechanism > and are giving your users an option, it seems reasonable to relax the > configuration when your users do not choose to turn onauthentication. > This particular relaxation seems like one of the more common cases = that > should come up when advanced threat model is used with auth disabled. >=20 > however I do not support changing our minds about what the simple = threat > model means. If the simple threat model really is unworkable, I'd > support replacing PCP with a new version including a MTI security > mechanism. >=20 > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Tue Jun 4 22:19:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95021F86F4 for ; Tue, 4 Jun 2013 22:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m5CKzXTB6Gd for ; Tue, 4 Jun 2013 22:19:48 -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 9EFA821F99E4 for ; Tue, 4 Jun 2013 22:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3787; q=dns/txt; s=iport; t=1370409588; x=1371619188; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CEfyMaoTFEHzTwt/dhEN4DicWtMSJWfGXQ1rVdu5Tng=; b=g7RyGIrYOuGTQfTZd+NwPFl0N91mS6UNF6tuJYOBaA2nYtAvIfOFHM07 Ix+vwgvj0HTGK5UBNlbwx/LPw5KQyunLKW67bVI8ld744GYHORQ7vHoBq xZkPWS4jxGVYbiVbhYRrr02x/jjD3FClCqY9j0wGu/jXg+P4EMpC1Q1gE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADvKrlGtJV2b/2dsb2JhbABSCIMJML8qgQEWdIIjAQEBBAEBATc0CxIBCBgKDgYGMQslAgQOBQiIBQyvAI1mjW6BBTEHGIJiYQOYaJAXgw+BaiQZ X-IronPort-AV: E=Sophos;i="4.87,804,1363132800"; d="scan'208";a="218894693" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jun 2013 05:19:48 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r555Jl5f011989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 05:19:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 00:19:47 -0500 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" Thread-Topic: [pcp] Problem with nonce checking Thread-Index: AQHOYXzyOPbrxwGqNk6eMhTg3IquF5kmX6EAgABZi4D///31gA== Date: Wed, 5 Jun 2013 05:19:47 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A05D0@xmb-rcd-x04.cisco.com> In-Reply-To: <84B3321A-0FB6-4946-A3DF-D53DD6DBA618@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.250.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <28E634B10CE91743A63DE6E96B9D21C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 05:19:53 -0000 Yes, sounds like Monty Python. And no, does not destroy protection of nonce because it assumes authentication is enabled. "..if PCP authentication is enabled..". Or alternatively if nonce is disabled which means there was no nonce check to begin with. On 6/4/13 11:27 PM, "Dan Wing" wrote: > >On Jun 4, 2013, at 5:06 PM, Reinaldo Penno (repenno) >wrote: > >> Hi Stuart, >>=20 >> I think this scenario is not new, but now more people are getting more >> operational experience and bring more voices to the discussions. >>=20 >> This specific scenario was discussed on this list a few times. >>=20 >> Med and I documented on >> http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 under >> "PCP Client crash". >>=20 >> "If the PCP Client does not store the explicit dynamic mappings and >> new Mapping Nonces are assigned, the PCP Server will reject to >> refresh these mappings. >>=20 >> Proposed Action: This issue can be solved if the PCP Client uses >> GET OpCode (Appendix B) to recover the mapping nonces used when >> instantiating the mappings if PCP authentication is used or >> Mapping Nonce validation check is disabled. >> " > >That destroys the security protection of Nonce. > >visitor: Let me into the castle. >guard: To enter the castle, tell me the password. >visitor: Ok. What is the password? >guard: 385932 >visitor: Let me in to the castle. >guard: To enter the castle, tell me the password. >visitor: 385932 >guard: > >Didn't Monte Python do that skit? > >-d > > >>=20 >>=20 >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> On 6/4/13 8:39 PM, "Stuart Cheshire" wrote: >>=20 >>> It looks like we're starting to accumulate a growing list of issues to >>> document in an addendum to RFC 6887. >>>=20 >>> If operating in the Simple Threat Model (Section 18.1), and the >>> internal port, protocol, and internal address match an existing >>> explicit dynamic mapping, but the mapping nonce does not match, the >>> request MUST be rejected with a NOT_AUTHORIZED error with the >>> lifetime of the error indicating duration of that existing mapping. >>> The PCP server only needs to remember one Mapping Nonce value for >>> each explicit dynamic mapping. >>>=20 >>> Here's the problem: >>>=20 >>> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive >>>ssh >>> logins. >>> 2. Client reboots, or similar, and picks new nonce. >>> 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive >>> ssh logins. >>> 4. NOT_AUTHORIZED! >>>=20 >>> And now the client is locked out of listening on its own TCP port 22 >>>for >>> the next 24 hours. Ironically, it *does* still have an external address >>> and port mapped to its internal TCP port 22 -- but the NAT gateway >>>won't >>> tell it *what* external address and port, making it not very useful. >>>=20 >>> I think we need to remove the server nonce check. >>>=20 >>> If the client asks for a mapping to 10.0.0.2:22, and there is in fact >>> *already* a mapping to 10.0.0.2:22, the the server should say so, and >>>not >>> pretend otherwise. >>>=20 >>> And if the server were to delete the old mapping in this situation, it >>> creates an easy DoS attack were someone can delete your mapping just by >>> trying to renew it with the wrong nonce. >>>=20 >>> Stuart Cheshire >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > From internet-drafts@ietf.org Wed Jun 5 01:17:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AE21F9A82; Wed, 5 Jun 2013 01:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oif8YsLYvIew; Wed, 5 Jun 2013 01:17:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4C21F8CDD; Wed, 5 Jun 2013 01:17:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605081748.7790.69447.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2013 01:17:48 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:17:49 -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 : Learning NAT64 PREFIX64s using PCP Author(s) : Mohamed Boucadair Filename : draft-ietf-pcp-nat64-prefix64-03.txt Pages : 15 Date : 2013-06-05 Abstract: This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed Jun 5 01:19:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8721F9A3C for ; Wed, 5 Jun 2013 01:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBmrefxM1R2H for ; Wed, 5 Jun 2013 01:19:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B32D721F9AAD for ; Wed, 5 Jun 2013 01:19:23 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 17EFE3250DE; Wed, 5 Jun 2013 10:19:23 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F199827C053; Wed, 5 Jun 2013 10:19:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 5 Jun 2013 10:19:22 +0200 From: To: "teemu.savolainen@nokia.com" , "pcp@ietf.org" Date: Wed, 5 Jun 2013 10:19:20 +0200 Thread-Topic: My review of draft-ietf-pcp-nat64-prefix64-02 Thread-Index: Ac5dHuevWC0dHYarTvOOt4eFkySJdgAE4xHAADJ54/AA8izlIA== Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD0034@PUEXCB1B.nanterre.francetelecom.fr> References: <916CE6CF87173740BC8A2CE44309696204718CB6@008-AM1MPN1-051.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36ED3A083DC@PUEXCB1B.nanterre.francetelecom.fr> <916CE6CF87173740BC8A2CE44309696204727C80@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204727C80@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.5.34520 Subject: Re: [pcp] My review of draft-ietf-pcp-nat64-prefix64-02 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:19:49 -0000 Hi Teemu, Thanks for your answer. I tried to integrate your comments. Please check the new version available = at: http://www.ietf.org/id/draft-ietf-pcp-nat64-prefix64-03.txt=20 If you still have any concern please let me know. Cheers, Med >-----Message d'origine----- >De=A0: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] >Envoy=E9=A0: vendredi 31 mai 2013 14:56 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org >Objet=A0: RE: My review of draft-ietf-pcp-nat64-prefix64-02 > >Hi Med, > >Thanks for quick reply. > >> [Med] I added this text: >> A more elaborated discussion can be found at >> [I-D.ietf-behave-nat64-learn-analysis]. A solution which solves some >> of these issues is specified in >> [I-D.ietf-behave-nat64-discovery-heuristic]. > >I guess that is enough. Some discussion around might be nice (e.g. >comparison, additional thoughts for why PCP option was standardized and wh= y >heuristic was not enough), but I'm not sure it is actually required. > >> [Med] I added this text to Section 3.2: >> This section provides some use cases to illustrate the problem space. > > More details can be found at Section 4 of > > [I-D.ietf-behave-nat64-learn-analysis]. > >Ok. > >>>Now that you have explicit tool for provisioning Pref64::/n, why do you >>>not provision also the suffix introduced in RFC6052? Wouldn't that make >>>this more future proof? The format shown in 4.1 could have variable >>>length suffix field. In fact, having suffix included would allow *fixed >>>length* >>>128 bit field-length, which might be optimized to be 96 bit field >>>(128-32, with first bits for prefix and remaining for suffix - dropping >>>bits for IPv4). >>[Med] I'm not sure there is a value to configure the suffix. The >implementation I'm aware does not allow to configure other suffixes. My >personal opinion is we should not include it in the option format. > >AFAIK the suffix is defined in RFC6052 for some possible future uses >(there's some discuss in RFC6052 section 4.1). If the PCP option would >support delivery of the suffix information (esp. if suffix were to be a >static value per deliver Pref64::/n and not e.g. facility for providing >checksum neutrality), it might be more future proof if some use for suffix >is actually taken into use some day. > >However, if the decision is not to deliver suffix, it could be worthwhile >to have couple of word saying that in the generation of synthetic IPv6 >addresses, suffix of zero MUST be used and that if in the future the suffi= x >is taken into use in protocol translation system, and the host can be >involved in setting the suffix in sensible manner, a new PCP option may be >needed. > >> [Med] I guess you are referring to what we had in >http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option- >02#page-6. The support of this >case will complicates the design option fo= r >a corner case. I added this sentence: >> This option does not solve the destination-dependent Pref64::/n > > discovery problem discussed in Section 5.1 of > > [I-D.ietf-behave-nat64-discovery-heuristic]. > >Oh I had missed that draft revision text:) Sure, it would complicate. >However, this consideration was really wanted to be included in the >heuristic-draft, and hence I think it should be included in this document >as well. > >Best regards, > > Teemu From mohamed.boucadair@orange.com Wed Jun 5 01:21:35 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9406021F9248 for ; Wed, 5 Jun 2013 01:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yT7wtHdDAsK for ; Wed, 5 Jun 2013 01:21:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 67FBF21F8551 for ; Wed, 5 Jun 2013 01:21:30 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2C26D3B4231; Wed, 5 Jun 2013 10:21:26 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0260A35C05A; Wed, 5 Jun 2013 10:21:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 5 Jun 2013 10:21:25 +0200 From: To: "Senthil Sivakumar (ssenthil)" , pcp issue tracker , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Date: Wed, 5 Jun 2013 10:21:24 +0200 Thread-Topic: [pcp] #63: Handling multiple prefixes Thread-Index: AQHOXlHExdMnhekn80OxiNm3pUsvuJklpesAgABblgCAAMy/0A== Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD0039@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36ED4CCFCA0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 08:21:35 -0000 Hi Senthil, You can find this text in the new version available at: http://www.ietf.org= /id/draft-ietf-pcp-nat64-prefix64-03.txt The PCP server is supposed to be able to disambiguate prefixes used for IPv6 address synthesis and other prefixes used to avoid any NAT64 deployed in the network. The PCP server can be configured with a customized IPv6 prefix list (i.e., specific to a PCP client or a group of PCP clients) or system-wise IPv6 prefix list (i.e., the same list is return for any PCP client). Please let me know if this text answers your two question. Cheers, Med >-----Message d'origine----- >De=A0: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] >Envoy=E9=A0: mardi 4 juin 2013 21:07 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp issue tracker; draft-ietf-pcp-nat6= 4- >prefix64@tools.ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] #63: Handling multiple prefixes > >Hi Med, > >On 6/4/13 5:39 AM, "mohamed.boucadair@orange.com" > wrote: > >>Hi Senthil, >> >>Thank you for the review. >> >>The current text says the following: >> >> When multiple prefixes are configured in a network, the PCP server >> MAY be configured to return multiple PREFIX64 options in the same >> message to the PCP client. The PCP server includes in the first >> PREFIX64 option, which appears in the PCP message it sends to the PCP >> client, the prefix to perform local IPv6 address synthesis [RFC6052]. >> Remaining PREFIX64 options convey any other Pref64::/n values >> configured . Returning these prefixes allows an end host to identify >> them as translated addresses, and instead prefer IPv4 or an >> alternative network interface in order to avoid any NAT64 deployed in >> the network. >> >>Doesn't this text solves your concern? Or you think more elaboration is >>needed? > >I have two questions/comments about this text. >1. How should the server order these prefixes? >2.How does the server know which prefix should be the first prefix handed >to the requesting client? > >Thanks >Senthil >> >>Cheers, >>Med >> >> >>>-----Message d'origine----- >>>De : pcp issue tracker [mailto:trac@tools.ietf.org] >>>Envoy=E9 : samedi 1 juin 2013 00:54 >>>=C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org; ssenthil@cisco.com >>>Cc : pcp@ietf.org >>>Objet : [pcp] #63: Handling multiple prefixes >>> >>>#63: Handling multiple prefixes >>> >>> The only comment I have is this document doesn't address the multiple >>> prefixes that could be present on a NAT64 device. >>> Any guidelines on which prefix should be reported would be useful. >>> >>>-- >>>-------------------------------------+----------------------------------= - >>>-- >>> Reporter: Senthil Sivakumar | Owner: draft-ietf-pcp- >>> (ssenthil) | nat64-prefix64@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>>Component: nat64-prefix64 | Version: >>> Severity: - | Keywords: >>>-------------------------------------+----------------------------------= - >>>-- >>> >>>Ticket URL: >>>pcp >> From simon.perreault@viagenie.ca Wed Jun 5 01:39:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6421F9A48 for ; Wed, 5 Jun 2013 01:39:23 -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_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JGTYofeOSAg for ; Wed, 5 Jun 2013 01:39:23 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1397C21F9A41 for ; Wed, 5 Jun 2013 01:39:23 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6628440452 for ; Wed, 5 Jun 2013 04:39:22 -0400 (EDT) Message-ID: <51AEF93A.9040300@viagenie.ca> Date: Wed, 05 Jun 2013 10:39:22 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> In-Reply-To: <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 08:39:23 -0000 Le 2013-06-05 04:29, Dan Wing a écrit : >> 1) make it easier for the client to retrieve the existing mapping (but >> not learn the nonce). >> We'd need to do security analysis of that but I think it's OK. > > I like that approach to retrieve the existing mapping. Seems that solves Stuart's case without adding new burden for storing state on the client. What if, when the server receives a MAP request matching an already-mapped internal port but with the wrong nonce, instead of returning NOT_AUTHORIZED, it would send a success response containing the external address+port, remaining lifetime, and a dummy nonce? I can't see anything that would break. Seems like we don't need a different opcode at all to make this use case work. And one round-trip saved. (But seriously the client should just remember nonces across reboots.) Simon From simon.perreault@viagenie.ca Wed Jun 5 01:41:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFEA21F99D1 for ; Wed, 5 Jun 2013 01:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1weMXmtWTIP for ; Wed, 5 Jun 2013 01:41:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B943221F99CF for ; Wed, 5 Jun 2013 01:41:30 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2AF0E40452 for ; Wed, 5 Jun 2013 04:41:30 -0400 (EDT) Message-ID: <51AEF9BA.6070601@viagenie.ca> Date: Wed, 05 Jun 2013 10:41:30 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> <51AEF93A.9040300@viagenie.ca> In-Reply-To: <51AEF93A.9040300@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 08:41:32 -0000 Le 2013-06-05 10:39, Simon Perreault a écrit : > Le 2013-06-05 04:29, Dan Wing a écrit : >>> 1) make it easier for the client to retrieve the existing mapping (but >>> not learn the nonce). >>> We'd need to do security analysis of that but I think it's OK. >> >> I like that approach to retrieve the existing mapping. Seems that >> solves Stuart's case without adding new burden for storing state on >> the client. > > What if, when the server receives a MAP request matching an > already-mapped internal port but with the wrong nonce, instead of > returning NOT_AUTHORIZED, it would send a success response containing > the external address+port, remaining lifetime, and a dummy nonce? I > can't see anything that would break. Further insight: from the point of view of the client, the existing mapping with a nonce it doesn't know about is just like a static mapping. The client can't modify it, but it can use MAP to discover its existence. Simon > > Seems like we don't need a different opcode at all to make this use case > work. And one round-trip saved. > > (But seriously the client should just remember nonces across reboots.) > > Simon > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From mohamed.boucadair@orange.com Wed Jun 5 01:59:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7021F9AAB for ; Wed, 5 Jun 2013 01:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Ua92m1TG7n for ; Wed, 5 Jun 2013 01:59:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 66AB021F9AA6 for ; Wed, 5 Jun 2013 01:59:13 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 83E10264BED; Wed, 5 Jun 2013 10:59:12 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 699F627C066; Wed, 5 Jun 2013 10:59:12 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 5 Jun 2013 10:59:12 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Wed, 5 Jun 2013 10:59:11 +0200 Thread-Topic: [pcp] Problem with nonce checking Thread-Index: Ac5hfPDWLO3u6135Qp6gafq48TcpPAAS5tuQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD0088@PUEXCB1B.nanterre.francetelecom.fr> References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> In-Reply-To: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 08:59:17 -0000 Hi Stuart, This is indeed a failure scenario we should be aware of.=20 We have documented various failure scenarios which are exacerbated by nonce= validation checks. You may refer to http://tools.ietf.org/html/draft-bouca= dair-pcp-failure-06 (search for nonce). Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: mercredi 5 juin 2013 01:40 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] Problem with nonce checking > >It looks like we're starting to accumulate a growing list of issues to >document in an addendum to RFC 6887. > > If operating in the Simple Threat Model (Section 18.1), and the > internal port, protocol, and internal address match an existing > explicit dynamic mapping, but the mapping nonce does not match, the > request MUST be rejected with a NOT_AUTHORIZED error with the > lifetime of the error indicating duration of that existing mapping. > The PCP server only needs to remember one Mapping Nonce value for > each explicit dynamic mapping. > >Here's the problem: > >1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh >logins. >2. Client reboots, or similar, and picks new nonce. >3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive ss= h >logins. >4. NOT_AUTHORIZED! > >And now the client is locked out of listening on its own TCP port 22 for >the next 24 hours. Ironically, it *does* still have an external address an= d >port mapped to its internal TCP port 22 -- but the NAT gateway won't tell >it *what* external address and port, making it not very useful. > >I think we need to remove the server nonce check. > >If the client asks for a mapping to 10.0.0.2:22, and there is in fact >*already* a mapping to 10.0.0.2:22, the the server should say so, and not >pretend otherwise. > >And if the server were to delete the old mapping in this situation, it >creates an easy DoS attack were someone can delete your mapping just by >trying to renew it with the wrong nonce. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Wed Jun 5 02:07:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5515621F9AAB for ; Wed, 5 Jun 2013 02:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji77Zpg8f29W for ; Wed, 5 Jun 2013 02:07:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9B05A21F99FF for ; Wed, 5 Jun 2013 02:07:35 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3A46E3B4E05; Wed, 5 Jun 2013 11:07:34 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A21034C05D; Wed, 5 Jun 2013 11:07:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 5 Jun 2013 11:07:33 +0200 From: To: Simon Perreault , "Reinaldo Penno (repenno)" Date: Wed, 5 Jun 2013 11:07:32 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5dRxK2T5R4Ie1jTZKugowhSv2oAwEg/96Q Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD00A0@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040908D901@xmb-rcd-x04.cisco.com> <51A76AA0.4030803@viagenie.ca> In-Reply-To: <51A76AA0.4030803@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 09:07:40 -0000 Hi Simon, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca] >Envoy=E9=A0: jeudi 30 mai 2013 17:05 >=C0=A0: Reinaldo Penno (repenno) >Cc=A0: BOUCADAIR Mohamed OLNC/OLN; Stuart Cheshire; pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >Le 2013-05-30 16:51, Reinaldo Penno (repenno) a =E9crit : >>>>> No. I'm not talking about reply packets, which could work if the NAT >>>>> tracks sessions. I'm talking about packets not associated with an >>>>> existing session, sent by the internal host to the outside, with >>>>> 100.0.0.2:80 as source. Where should those go? >>>> >>>> If destination is within the pool controlled by the NAT46, it goes >>>> there, >>>> otherwise it goes through NAT44. >>> >>> No. This is what I meant by "A mapping being endpoint-independent by PC= P >>> MAP definition, we can't use the destination to answer that question." >> >> There are two NATs, two mappings. EIM applies to the same NAT. > >I'm not too sure what you mean by "two NATs". In our examples so far >there is a single PCP-controlled device that performs multiple NATxy >functions. In this particular one, the PCP-controlled device does NAT44 >and NAT46. It MUST NOT simultaneously map the same internal IPv4 port to >an IPv4 and an IPv6 external ports. Otherwise, the PCP client has no >idea where its packets will go. > >In other words, going back to the numerical example: > >(1) 2000::1, 10000 <-> 100.0.0.2:80 >(2) 200.0.0.2, 10000 <-> 100.0.0.2:80 > >Those two mappings, having been handed out by the PCP server to the PCP >client and therefore needing to obey the PCP protocol definition of what >a mapping is, impose conflicting requirements on the PCP-controlled device= : > >(1) Packets sourced from 100.0.0.2:80 MUST be translated to 2000::1, 10000= . >(2) Packets sourced from 100.0.0.2:80 MUST be translated to 200.0.0.2, >10000. > >There is no way the PCP-controlled device can simultaneously obey those >two requirements. [Med] you have other state tables to look at, for example: * look of the destination IPv6 address is not maintained in a binding table= (to extract the IPv6 @ from the destination IPv4@) * routing: check if there is any specific entry=20 BTW, this problem is not related to PCP but it is more a deployment-specifi= c issue which is exacerbated by the use of EIM. An IPv4 application has no incentive to use several ports: one of them will= be used to receive packets from native IPv4 hosts while another port will = be used to handle IPv4 packets sourced with IPv4 addresses representing IPv= 6 hosts in the IPv4 domain. > >Now, all this doesn't apply if there are two PCP-controlled devices. > >Simon >-- >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange.com Wed Jun 5 02:17:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12F321F9A67 for ; Wed, 5 Jun 2013 02:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vT9Jihujz1Z for ; Wed, 5 Jun 2013 02:17:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2321F9A21 for ; Wed, 5 Jun 2013 02:17:48 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8BD7122D2C2; Wed, 5 Jun 2013 11:17:47 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6F12D27C053; Wed, 5 Jun 2013 11:17:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 5 Jun 2013 11:17:47 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Wed, 5 Jun 2013 11:17:46 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5dTHyy9lwzrVBnTY2YNzwse65wMAEf6R5Q Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> In-Reply-To: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.5.34520 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 09:17:54 -0000 Stuart, I'm objecting your proposal because I don't want to add a new failure case = to the list we already have.=20 There is a risk that some PCP clients won't try all AFs for the same PCP se= rver and therefore the host won't be able to receive incoming packets via t= hat PCP-controlled device. Consider an IPv6-only client behind a NAT64. If = the pcp client asks for IPv6 external address, the server will reject it wi= th the error you are proposing. If the pcp client does not try another AF, = the IPv6-only host cannot receive incoming sessions from an IPv4-only host. An application does not care about the AF of the remote machine; what it sh= ould care about is how to maximize the chance to place successful session w= ith hosts wanting to do so.=20 A PCP server that assigns only addresses of only one AF should return an ad= dress of the AF it manages. It is up to the client to decide to make use of= it or not. If the PCP server manages several AFs, the PCP server will make it best to = accommodate the suggested AF and if it cannot an alternate AF can be propos= ed to the client. Again, it is up to the client to decide whether it will m= ake use of that address of not. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: jeudi 30 mai 2013 17:44 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On 30 May 2013, at 4:30 AM, mohamed.boucadair@orange.com wrote: > >> Unlike MAP4/MAP6, the server receiving a MAP request is not obliged to >return an IP address following the indication included in the suggested >external IP address field. It will try to best accommodate it, but if not, >it would be fine if it returns another AF address; then it is up to the >client to make use of it or not. >> >> In another words: we should not use Suggested IP Address as PREFER_AF >option ;-) > >RFC 6887 states that the client uses the appropriate all-zeros address in >the Suggested External Address field to control what family of external >address it gets: > > When operating a server (see Sections 10.1 and 10.2), the PCP client > knows if it wants an IPv4 listener, IPv6 listener, or both on the > Internet. The PCP client also knows if it has an IPv4 address or > IPv6 address configured on one of its interfaces. It takes the union > of this knowledge to decide to which of its PCP servers to send the > request (e.g., an IPv4 address or an IPv6 address), and whether to > send one or two MAP requests for each of its interfaces (e.g., if the > PCP client has only an IPv4 address but wants both IPv6 and IPv4 > listeners, it sends a MAP request containing the all-zeros IPv6 > address in the Suggested External Address field, and sends a second > MAP request containing the all-zeros IPv4 address in the Suggested > External Address field). If the PCP client has both an IPv4 and IPv6 > address, and only wants an IPv4 listener, it sends one MAP request > from its IPv4 address (if the PCP server supports NAT44 or IPv4 > firewall) or one MAP request from its IPv6 address (if the PCP server > supports NAT64). The PCP client can simply request the desired > mapping to determine if the PCP server supports the desired mapping. > >and > > the application constructs a PCP message with the MAP Opcode, with > the external address set to the appropriate all-zeros address, > depending on whether it wants a public IPv4 or IPv6 address. > >We really need WG consensus on whether the external address family is a >firm requirement or merely a hint, so client writers know what to expect. > >I don't see any benefit in requiring client writers to handle the client >unexpectedly getting an address family it doesn't want. > >That's also a code path that's likely to be poorly tested. I can imagine >lots of IPv4-only devices being tested with IPv4-only NATs and shipped >today, and then, a couple of years from now, crashing the first time they >unexpectedly get handed an IPv6 address. > >We'll be shooting ourselves in the foot if we choose that path. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Wed Jun 5 04:59:06 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616F821F9A01 for ; Wed, 5 Jun 2013 04:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6kiWH1ALQhe for ; Wed, 5 Jun 2013 04:59:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EF75C21F9A19 for ; Wed, 5 Jun 2013 04:58:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BC8DD2DC3C5; Wed, 5 Jun 2013 13:58:58 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8FD3535C058; Wed, 5 Jun 2013 13:58:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 5 Jun 2013 13:58:58 +0200 From: To: Dan Wing , Reinaldo Penno Date: Wed, 5 Jun 2013 13:58:57 +0200 Thread-Topic: [pcp] Problem with nonce checking Thread-Index: Ac5hlPNH19PEQ3KlRxyVBqDK09dZ7AATr5MQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD019B@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A04CF@xmb-rcd-x04.cisco.com> <84B3321A-0FB6-4946-A3DF-D53DD6DBA618@cisco.com> In-Reply-To: <84B3321A-0FB6-4946-A3DF-D53DD6DBA618@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 11:59:06 -0000 Hi Dan, It doesn't. Please re-read the text. This point is explicitly discussed in Section 2.2 of the failure draft: If the same port number is used but a distinct Mapping Nonce is generated, the request will be rejected with a NOT_AUTHORIZED error with the Lifetime of the error indicating duration of that existing mapping (see Section 2.7 of [I-D.boucadair-pcp-flow-examples]). Proposed Action: A solution to recover the Mapping Nonce used when instantiating the mapping may be envisaged; this solution may not be viable if PCP authentication is not in use. Mapping Nonce recovery in the simple PCP threat model (especially when Mapping Check validation is enabled) induces the same security threated as those discussed in [RFC6887]. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Da= n >Wing >Envoy=E9=A0: mercredi 5 juin 2013 04:27 >=C0=A0: Reinaldo Penno >Cc=A0: Stuart Cheshire; pcp@ietf.org >Objet=A0: Re: [pcp] Problem with nonce checking > > >On Jun 4, 2013, at 5:06 PM, Reinaldo Penno (repenno) >wrote: > >> Hi Stuart, >> >> I think this scenario is not new, but now more people are getting more >> operational experience and bring more voices to the discussions. >> >> This specific scenario was discussed on this list a few times. >> >> Med and I documented on >> http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 under >> "PCP Client crash". >> >> "If the PCP Client does not store the explicit dynamic mappings and >> new Mapping Nonces are assigned, the PCP Server will reject to >> refresh these mappings. >> >> Proposed Action: This issue can be solved if the PCP Client uses >> GET OpCode (Appendix B) to recover the mapping nonces used when >> instantiating the mappings if PCP authentication is used or >> Mapping Nonce validation check is disabled. >> " > >That destroys the security protection of Nonce. > >visitor: Let me into the castle. >guard: To enter the castle, tell me the password. >visitor: Ok. What is the password? >guard: 385932 >visitor: Let me in to the castle. >guard: To enter the castle, tell me the password. >visitor: 385932 >guard: > >Didn't Monte Python do that skit? > >-d > > >> >> >> >> Thanks, >> >> Reinaldo >> >> >> On 6/4/13 8:39 PM, "Stuart Cheshire" wrote: >> >>> It looks like we're starting to accumulate a growing list of issues to >>> document in an addendum to RFC 6887. >>> >>> If operating in the Simple Threat Model (Section 18.1), and the >>> internal port, protocol, and internal address match an existing >>> explicit dynamic mapping, but the mapping nonce does not match, the >>> request MUST be rejected with a NOT_AUTHORIZED error with the >>> lifetime of the error indicating duration of that existing mapping. >>> The PCP server only needs to remember one Mapping Nonce value for >>> each explicit dynamic mapping. >>> >>> Here's the problem: >>> >>> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ss= h >>> logins. >>> 2. Client reboots, or similar, and picks new nonce. >>> 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive >>> ssh logins. >>> 4. NOT_AUTHORIZED! >>> >>> And now the client is locked out of listening on its own TCP port 22 fo= r >>> the next 24 hours. Ironically, it *does* still have an external address >>> and port mapped to its internal TCP port 22 -- but the NAT gateway won'= t >>> tell it *what* external address and port, making it not very useful. >>> >>> I think we need to remove the server nonce check. >>> >>> If the client asks for a mapping to 10.0.0.2:22, and there is in fact >>> *already* a mapping to 10.0.0.2:22, the the server should say so, and >not >>> pretend otherwise. >>> >>> And if the server were to delete the old mapping in this situation, it >>> creates an easy DoS attack were someone can delete your mapping just by >>> trying to renew it with the wrong nonce. >>> >>> Stuart Cheshire >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Wed Jun 5 06:28:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED61721F9ABB for ; Wed, 5 Jun 2013 06:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHsHUQm56X-v for ; Wed, 5 Jun 2013 06:28: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 1E68F21F9A82 for ; Wed, 5 Jun 2013 06:28:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B41D020637; Wed, 5 Jun 2013 09:25:02 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne-DlozZr9VK; Wed, 5 Jun 2013 09:25:02 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 5 Jun 2013 09:25:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5D66B4498; Wed, 5 Jun 2013 09:28:31 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> <51AEF93A.9040300@viagenie.ca> Date: Wed, 05 Jun 2013 09:28:31 -0400 In-Reply-To: <51AEF93A.9040300@viagenie.ca> (Simon Perreault's message of "Wed, 05 Jun 2013 10:39:22 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 13:28:41 -0000 >>>>> "Simon" == Simon Perreault writes: Rather than a dummy nonce, I think the server should use the client's nonce from the new map request. And yes, it's like a static mapping from the POV of the client as you suggest. --Sam From simon.perreault@viagenie.ca Wed Jun 5 06:50:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFE721F9B48 for ; Wed, 5 Jun 2013 06:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnpqW3OAd4mH for ; Wed, 5 Jun 2013 06:50:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B7ABE21F9B47 for ; Wed, 5 Jun 2013 06:50:41 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EA39B403F8; Wed, 5 Jun 2013 09:50:40 -0400 (EDT) Message-ID: <51AF4231.3040902@viagenie.ca> Date: Wed, 05 Jun 2013 15:50:41 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <648DDFDF-7CBC-489E-8F95-DB7D8F74D986@cisco.com> <51AEF93A.9040300@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 13:50:42 -0000 Le 2013-06-05 15:28, Sam Hartman a écrit : > Rather than a dummy nonce, I think the server should use the client's > nonce from the new map request. Makes total sense. Simon From dwing@cisco.com Wed Jun 5 07:13:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C521F9947 for ; Wed, 5 Jun 2013 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHNAvZj6LSaa for ; Wed, 5 Jun 2013 07:12:55 -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 4D7A821F9133 for ; Wed, 5 Jun 2013 07:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5050; q=dns/txt; s=iport; t=1370441575; x=1371651175; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MYJoLXUscou5Ub79RZT2v23z3jYufuBhgcGS5MNv3Qs=; b=BVj+GdrraxZqz4285/4LSM/m3rCjGH8bEqqjLBEpRqRHYhC5TaWwHR2M lsR1AQnHkT1cZ+SwG8T3MS4O9mz/TLCCD9LZAel/lJDhnIhW1qEJo14yH MOJvOBxTn5F04009J2VAMW4hXc64/JaddKs6eoqQp3t5POaNkxvII5cb6 c=; X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="80308664" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 05 Jun 2013 14:12:55 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55ECsDS009538; Wed, 5 Jun 2013 14:12:54 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CD019B@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 5 Jun 2013 07:12:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A04CF@xmb-rcd-x04.cisco.com> <84B3321A-0FB6-4946-A3DF-D53DD6DBA618@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED4CD019B@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1503) Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 14:13:00 -0000 On Jun 5, 2013, at 4:58 AM, wrote: > Hi Dan, >=20 > It doesn't. Please re-read the text. >=20 > This point is explicitly discussed in Section 2.2 of the failure = draft: >=20 > If the same port number is used but a distinct Mapping Nonce is > generated, the request will be rejected with a NOT_AUTHORIZED error > with the Lifetime of the error indicating duration of that existing > mapping (see Section 2.7 of [I-D.boucadair-pcp-flow-examples]). >=20 > Proposed Action: A solution to recover the Mapping Nonce used = when > instantiating the mapping may be envisaged; this solution may not > be viable if PCP authentication is not in use. =20 Sorry I misread the double negative. -d > Mapping Nonce > recovery in the simple PCP threat model (especially when Mapping > Check validation is enabled) induces the same security threated = as > those discussed in [RFC6887]. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = Dan >> Wing >> Envoy=E9 : mercredi 5 juin 2013 04:27 >> =C0 : Reinaldo Penno >> Cc : Stuart Cheshire; pcp@ietf.org >> Objet : Re: [pcp] Problem with nonce checking >>=20 >>=20 >> On Jun 4, 2013, at 5:06 PM, Reinaldo Penno (repenno) = >> wrote: >>=20 >>> Hi Stuart, >>>=20 >>> I think this scenario is not new, but now more people are getting = more >>> operational experience and bring more voices to the discussions. >>>=20 >>> This specific scenario was discussed on this list a few times. >>>=20 >>> Med and I documented on >>> http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#page-4 = under >>> "PCP Client crash". >>>=20 >>> "If the PCP Client does not store the explicit dynamic mappings and >>> new Mapping Nonces are assigned, the PCP Server will reject to >>> refresh these mappings. >>>=20 >>> Proposed Action: This issue can be solved if the PCP Client uses >>> GET OpCode (Appendix B) to recover the mapping nonces used when >>> instantiating the mappings if PCP authentication is used or >>> Mapping Nonce validation check is disabled. >>> " >>=20 >> That destroys the security protection of Nonce. >>=20 >> visitor: Let me into the castle. >> guard: To enter the castle, tell me the password. >> visitor: Ok. What is the password? >> guard: 385932 >> visitor: Let me in to the castle. >> guard: To enter the castle, tell me the password. >> visitor: 385932 >> guard: >>=20 >> Didn't Monte Python do that skit? >>=20 >> -d >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Reinaldo >>>=20 >>>=20 >>> On 6/4/13 8:39 PM, "Stuart Cheshire" wrote: >>>=20 >>>> It looks like we're starting to accumulate a growing list of issues = to >>>> document in an addendum to RFC 6887. >>>>=20 >>>> If operating in the Simple Threat Model (Section 18.1), and the >>>> internal port, protocol, and internal address match an existing >>>> explicit dynamic mapping, but the mapping nonce does not match, the >>>> request MUST be rejected with a NOT_AUTHORIZED error with the >>>> lifetime of the error indicating duration of that existing mapping. >>>> The PCP server only needs to remember one Mapping Nonce value for >>>> each explicit dynamic mapping. >>>>=20 >>>> Here's the problem: >>>>=20 >>>> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can = receive ssh >>>> logins. >>>> 2. Client reboots, or similar, and picks new nonce. >>>> 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can = receive >>>> ssh logins. >>>> 4. NOT_AUTHORIZED! >>>>=20 >>>> And now the client is locked out of listening on its own TCP port = 22 for >>>> the next 24 hours. Ironically, it *does* still have an external = address >>>> and port mapped to its internal TCP port 22 -- but the NAT gateway = won't >>>> tell it *what* external address and port, making it not very = useful. >>>>=20 >>>> I think we need to remove the server nonce check. >>>>=20 >>>> If the client asks for a mapping to 10.0.0.2:22, and there is in = fact >>>> *already* a mapping to 10.0.0.2:22, the the server should say so, = and >> not >>>> pretend otherwise. >>>>=20 >>>> And if the server were to delete the old mapping in this situation, = it >>>> creates an easy DoS attack were someone can delete your mapping = just by >>>> trying to renew it with the wrong nonce. >>>>=20 >>>> Stuart Cheshire >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Wed Jun 5 08:42:02 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6354721F9AF8 for ; Wed, 5 Jun 2013 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEw9KnfD2l-9 for ; Wed, 5 Jun 2013 08:41:47 -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 3C65C21F9AFF for ; Wed, 5 Jun 2013 08:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=667; q=dns/txt; s=iport; t=1370446907; x=1371656507; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yaZ2MeTsUTMvFCCCCH1CVDopUWIpbQZxzf5R2j0wxOY=; b=KDbInRlgeL7WHVHENJ+mosEmqsgGH9C5sTaMYipqHSpXqqcL3vOyI0i6 g23crsvWsDSExw5u4S/xCS1NSEP6ugh/pv/5f/52KYAwcRrJeVuvKVQyB MuH43WlVU4nwj/wy/sOF8fr1xmYQAgrzT1Qmgj8AcwanzCLmOKyfwAKKY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAAJbr1GtJV2a/2dsb2JhbABagwkwgnW8N30WdIIlAQQBAQE3NAsSAQgiFDcLJQIEAQ0FCIgFDL0oBI56MQeCemEDqH+DD4In X-IronPort-AV: E=Sophos;i="4.87,807,1363132800"; d="scan'208";a="218925082" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 15:41:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55FfkBh011497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 15:41:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 10:41:46 -0500 From: "Reinaldo Penno (repenno)" To: Sam Hartman , Simon Perreault Thread-Topic: [pcp] Problem with nonce checking Thread-Index: AQHOYfCSOPbrxwGqNk6eMhTg3IquF5knZAGA Date: Wed, 5 Jun 2013 15:41:46 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A093A@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.252] 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] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 05 Jun 2013 15:42:02 -0000 Good suggestion. Whether the PCP application crashed or the host got a new IP, a client should be able to find out existing mappings to certain ports it would like to use. On 6/5/13 10:28 AM, "Sam Hartman" wrote: >>>>>> "Simon" =3D=3D Simon Perreault writes: > > >Rather than a dummy nonce, I think the server should use the client's >nonce from the new map request. >And yes, it's like a static mapping from the POV of the client as you >suggest. > >--Sam >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Thu Jun 6 00:42:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAE821F8FB3 for ; Thu, 6 Jun 2013 00:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp3F6zHUMXhi for ; Thu, 6 Jun 2013 00:42:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8959921F96E9 for ; Thu, 6 Jun 2013 00:42:34 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 51BA52DC295; Thu, 6 Jun 2013 09:42:33 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 37EDC23805E; Thu, 6 Jun 2013 09:42:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 6 Jun 2013 09:42:33 +0200 From: To: Simon Perreault , "pcp@ietf.org" Date: Thu, 6 Jun 2013 09:42:31 +0200 Thread-Topic: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Thread-Index: Ac5hJ7CzhzSgyHDhT2CP5UkrE+1zegBWaWdA Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> In-Reply-To: <51ADD61C.1040106@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.6.64518 Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 07:42:39 -0000 Hi Simon, I suggest pcp for lw4o6 to follow the some design choices as those of ds-li= te. In particular: * adopt the plaine IPv6 mode which is currently supported by various vendor= s. * use the updated server discovery procedure (if no pcp server is explicitl= y configured, use the lwAFTR as pcp server instead of the default router). It would be useful to include a section to discuss the behavior of the PCP = server. The server may be tweaked to accept only MAP with PORT_SET. Other o= ptions and OpCodes can be disabled. On the client side, you may indicate there is no need to include THIRD_PART= Y, PREFER_FAILURE and FILTER options in MAP requests. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si= mon >Perreault >Envoy=E9=A0: mardi 4 juin 2013 13:57 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] Fwd: New Version Notification for draft-perreault-softwire= - >lw4over6-pcp-00.txt > >WG, > >He have published a new draft in SOFTWIRE describing how a Lightweight >4over6 CPE can use PCP for provisioning. It makes use of the PORT_SET >extension. > >In this WG we're looking for feedback specific to our proposed usage of >PCP. Is it correct or is it fatally flawed? Could it be improved? >Anything PCP-specific that we should have considered? > >If you would like to comment on the high-level softwire framework, >please use softwire@ietf.org instead. > >Thanks, >Simon > > >-------- Message original -------- >Sujet: New Version Notification for >draft-perreault-softwire-lw4over6-pcp-00.txt >Date : Tue, 04 Jun 2013 01:54:06 -0700 >De : internet-drafts@ietf.org >Pour : Chongfeng Xie , Cathy Zhou >, Simon Perreault > > >A new version of I-D, draft-perreault-softwire-lw4over6-pcp-00.txt >has been successfully submitted by Chongfeng Xie and posted to the >IETF repository. > >Filename: draft-perreault-softwire-lw4over6-pcp >Revision: 00 >Title: Provisioning Lightweight 4over6 (lw4o6) with the Port >Control >Protocol (PCP) >Creation date: 2013-06-03 >Group: Individual Submission >Number of pages: 6 >URL: >http://www.ietf.org/internet-drafts/draft-perreault-softwire-lw4over6-pcp- >00.txt >Status: >http://datatracker.ietf.org/doc/draft-perreault-softwire-lw4over6-pcp >Htmlized: >http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00 > > >Abstract: > This memo defines the procedures that a Lightweight B4 uses for > provisioning its parameters with the Port Control Protocol. > > > > > >The IETF Secretariat > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Jun 6 01:02:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA83921F96FC for ; Thu, 6 Jun 2013 01:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drwnl0kU8EJr for ; Thu, 6 Jun 2013 01:02: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 8413521F8952 for ; Thu, 6 Jun 2013 01:01:58 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C2F4340437; Thu, 6 Jun 2013 04:01:57 -0400 (EDT) Message-ID: <51B041F6.6040800@viagenie.ca> Date: Thu, 06 Jun 2013 10:01:58 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 08:02:11 -0000 X-List-Received-Date: Thu, 06 Jun 2013 08:02:11 -0000 Le 2013-06-06 09:42, mohamed.boucadair@orange.com a écrit : > I suggest pcp for lw4o6 to follow the some design choices as those of > ds-lite. In particular: * adopt the plaine IPv6 mode which is > currently supported by various vendors. I'm well aware of this, but it is problematic. Consider the use case of a load-balanced lwAFTR. The load balancing is based on L4 hashing. You have a bunch of IPv4-over-IPv6 tunnels being load-balanced this way over a bunch of lwAFTRs. For those tunnel, the L4 hash is calculated over a 3-tuple: source IPv6 address, destination IPv6 address, and protocol number. No port numbers are available to build a 5-tuple. Now, you want PCP to be load-balanced to the same lwAFTR as the IPv4-over-IPv6 tunnel. With the plain IPv6 mode, that's not going to work since the PCP flow will be hashed on the UDP 5-tuple. The way to ensure that the PCP traffic reaches the correct lwAFTR is to put PCP inside the tunnel. So that's the problem we have. Solution ideas would be much appreciated. > * use the updated server discovery procedure (if no pcp server is > explicitly configured, use the lwAFTR as pcp server instead of the > default router). Right, that would follow if we used the plain IPv6 mode. > It would be useful to include a section to discuss the behavior of > the PCP server. The server may be tweaked to accept only MAP with > PORT_SET. Other options and OpCodes can be disabled. Sure. If you could send text that would be great. > On the client side, you may indicate there is no need to include > THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests. Good suggestion. Isn't THIRD_PARTY needed with plain IPv6 mode? Simon From mohamed.boucadair@orange.com Thu Jun 6 01:17:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807BC21F8DDD for ; Thu, 6 Jun 2013 01:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljubC6C4ZgjR for ; Thu, 6 Jun 2013 01:17:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4126021F96E1 for ; Thu, 6 Jun 2013 01:17:19 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E709C2DCC17; Thu, 6 Jun 2013 10:17:17 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C63344C015; Thu, 6 Jun 2013 10:17:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 6 Jun 2013 10:17:17 +0200 From: To: Simon Perreault Date: Thu, 6 Jun 2013 10:17:16 +0200 Thread-Topic: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Thread-Index: Ac5ijB/iof+PtFBOT1O9hWbwnrXCOAAAHL8w Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> In-Reply-To: <51B041F6.6040800@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.6.64518 Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 08:17:53 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca] >Envoy=E9=A0: jeudi 6 juin 2013 10:02 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] Fwd: New Version Notification for draft-perreault- >softwire-lw4over6-pcp-00.txt > >Le 2013-06-06 09:42, mohamed.boucadair@orange.com a =E9crit : >> I suggest pcp for lw4o6 to follow the some design choices as those of >> ds-lite. In particular: * adopt the plaine IPv6 mode which is >> currently supported by various vendors. > >I'm well aware of this, but it is problematic. > >Consider the use case of a load-balanced lwAFTR. The load balancing is >based on L4 hashing. You have a bunch of IPv4-over-IPv6 tunnels being >load-balanced this way over a bunch of lwAFTRs. For those tunnel, the L4 >hash is calculated over a 3-tuple: source IPv6 address, destination IPv6 >address, and protocol number. No port numbers are available to build a >5-tuple. [Med] This is deployment-specific. The hash computation can be updated to r= ely on IP-based information, no port numbers would be needed. > >Now, you want PCP to be load-balanced to the same lwAFTR as the >IPv4-over-IPv6 tunnel. With the plain IPv6 mode, that's not going to >work since the PCP flow will be hashed on the UDP 5-tuple. The way to >ensure that the PCP traffic reaches the correct lwAFTR is to put PCP >inside the tunnel. [Med] Load-balancing can be achieved in various manners. Another scheme wou= ld be to avoid the use of anycast-based LB but dispatch CPE to the enabled = lwAFTR by returning unicast addresses. > >So that's the problem we have. Solution ideas would be much appreciated. > >> * use the updated server discovery procedure (if no pcp server is >> explicitly configured, use the lwAFTR as pcp server instead of the >> default router). > >Right, that would follow if we used the plain IPv6 mode. > >> It would be useful to include a section to discuss the behavior of >> the PCP server. The server may be tweaked to accept only MAP with >> PORT_SET. Other options and OpCodes can be disabled. > >Sure. If you could send text that would be great. [Med] Ok, I will do. > >> On the client side, you may indicate there is no need to include >> THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests. > >Good suggestion. > >Isn't THIRD_PARTY needed with plain IPv6 mode? [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to successfully d= o NAT in the AFTR, the lw4o6 only requires the IPv6@ of the lwB4 and not th= e internal IPv4 address. This another reason to adopt the plain IPv6 mode. = The binding table will associate an IPv6@ with {IPv4@, Port Set}.=20 > >Simon From simon.perreault@viagenie.ca Thu Jun 6 01:24:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298F821F9195 for ; Thu, 6 Jun 2013 01:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5zuX95S+8DY for ; Thu, 6 Jun 2013 01:24:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5404321F883B for ; Thu, 6 Jun 2013 01:24:47 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A1A8446FC0; Thu, 6 Jun 2013 04:24:46 -0400 (EDT) Message-ID: <51B0474F.6080707@viagenie.ca> Date: Thu, 06 Jun 2013 10:24:47 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 08:24:54 -0000 Le 2013-06-06 10:17, mohamed.boucadair@orange.com a écrit : >> Isn't THIRD_PARTY needed with plain IPv6 mode? > [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to > successfully do NAT in the AFTR, the lw4o6 only requires the IPv6@ of > the lwB4 and not the internal IPv4 address. This another reason to > adopt the plain IPv6 mode. The binding table will associate an IPv6@ > with {IPv4@, Port Set}. How would the PCP server know the difference between a request for an internal IPv4 mapping and a request for an internal IPv6 mapping if both are sent over IPv6 and there is no THIRD_PARTY option? I mean, the CPE could want to use PCP to control an plain IPv6 firewall for example. Do you mean that all requests sent to the lwAFTR IPv6 address will implicitly be IPv4 internal? That seems like a dangerous assumption to me... Simon From mohamed.boucadair@orange.com Thu Jun 6 01:37:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2021F9648 for ; Thu, 6 Jun 2013 01:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBmBzAhPv30b for ; Thu, 6 Jun 2013 01:37:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C611F21F8EA5 for ; Thu, 6 Jun 2013 01:37:27 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3840D3B4F9B; Thu, 6 Jun 2013 10:37:27 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1DCA14C06D; Thu, 6 Jun 2013 10:37:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 6 Jun 2013 10:37:27 +0200 From: To: Simon Perreault Date: Thu, 6 Jun 2013 10:37:25 +0200 Thread-Topic: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Thread-Index: Ac5ij08BvUorC8x4ReaVXS6TL0AALgAAMFlg Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD042D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> <51B0474F.6080707@viagenie.ca> In-Reply-To: <51B0474F.6080707@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.6.80616 Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 08:37:33 -0000 >-----Message d'origine----- >De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca] >Envoy=E9=A0: jeudi 6 juin 2013 10:25 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] Fwd: New Version Notification for draft-perreault- >softwire-lw4over6-pcp-00.txt > >Le 2013-06-06 10:17, mohamed.boucadair@orange.com a =E9crit : >>> Isn't THIRD_PARTY needed with plain IPv6 mode? >> [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to >> successfully do NAT in the AFTR, the lw4o6 only requires the IPv6@ of >> the lwB4 and not the internal IPv4 address. This another reason to >> adopt the plain IPv6 mode. The binding table will associate an IPv6@ >> with {IPv4@, Port Set}. > >How would the PCP server know the difference between a request for an >internal IPv4 mapping and a request for an internal IPv6 mapping if both >are sent over IPv6 and there is no THIRD_PARTY option? [Med] I'm assuming the following PCP deployment mode fro lw4ov6: * The server assigns an external IPv4 address and a port set. * The CPE will use the external port set for its NAT operations, including = port forwarding purposes/ * The use of a PCP proxy is optional.=20 * port forwarding can be dynamically instructed using UPnP IGD or PCP * PCP requests issued from internal hosts are handled by the CPE itself if = the CPE embeds a PCP server. I mean, the CPE >could want to use PCP to control an plain IPv6 firewall for example. [Med] Which firewall? Why you need it?=20 Do >you mean that all requests sent to the lwAFTR IPv6 address will >implicitly be IPv4 internal?=20 [Med] I'm assuming, PCP is needed for lw4o6 to retrieve the port set and IP= v4 address. No additional port control feature is needed. That seems like a dangerous assumption to >me... [Med] Why? > >Simon From bingxuere@gmail.com Thu Jun 6 02:07:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C844921F9631 for ; Thu, 6 Jun 2013 02:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JhzmQHp2cSG for ; Thu, 6 Jun 2013 02:07:54 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8851A21F961B for ; Thu, 6 Jun 2013 02:07:54 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so1763267vbb.37 for ; Thu, 06 Jun 2013 02:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G3EfLq24zV6xLhaOUw1bXFIQs4/q71BPEZdrIOc7Rrc=; b=p+u7QVqck3DjwP2SG0XN6jzlwQ4OmLxQTfiQeqlaUPOisdDxDg31oLqEqNOkkZI/9Y H9hLgHlqoxYBLZHXaiRfBBFS339NHO24OZfK+UkAYkEPB7iBzm0IBK+ChUfx8DGQ1PiK ZnLsug0zgNxbtfHDB/xupPFVeYD5yNdOJi9rfj4y5c7qWlVGzVdk6gnV/Cq8BHTHVW3U ih3ygjQUWvG5cj7aHRLnqwB/LH9GsNeo3+8KscFx6HXn0GRbypL5m1SPcoCzlw7vFtyC 6UHYrypqO+1f8Tig52flNFTQpH8E6WySmHnrLKQAMZlQcAV5HsdPeU4HUEPZnIORhQ/B /DSw== X-Received: by 10.52.94.16 with SMTP id cy16mr5054407vdb.54.1370509673766; Thu, 06 Jun 2013 02:07:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.115.3 with HTTP; Thu, 6 Jun 2013 02:07:13 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> From: Qiong Date: Thu, 6 Jun 2013 17:07:13 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=20cf307f337e4426ad04de78a696 Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:07:55 -0000 --20cf307f337e4426ad04de78a696 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Med, Thanks for your comments! See my reply inline. On Thu, Jun 6, 2013 at 4:17 PM, wrote: > Re-, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De : Simon Perreault [mailto:simon.perreault@viagenie.ca] > >Envoy=C3=A9 : jeudi 6 juin 2013 10:02 > >=C3=80 : BOUCADAIR Mohamed OLNC/OLN > >Cc : pcp@ietf.org > >Objet : Re: [pcp] Fwd: New Version Notification for draft-perreault- > >softwire-lw4over6-pcp-00.txt > > > >Le 2013-06-06 09:42, mohamed.boucadair@orange.com a =C3=A9crit : > >> I suggest pcp for lw4o6 to follow the some design choices as those of > >> ds-lite. In particular: * adopt the plaine IPv6 mode which is > >> currently supported by various vendors. > [Qiong] DS-Lite would also have the same problem when deploying anycast-based load balancing. I strongly suggest that DS-Lite should also include this tunnel mode especially for this scenario. > > > >I'm well aware of this, but it is problematic. > > > >Consider the use case of a load-balanced lwAFTR. The load balancing is > >based on L4 hashing. You have a bunch of IPv4-over-IPv6 tunnels being > >load-balanced this way over a bunch of lwAFTRs. For those tunnel, the L4 > >hash is calculated over a 3-tuple: source IPv6 address, destination IPv6 > >address, and protocol number. No port numbers are available to build a > >5-tuple. > [Med] This is deployment-specific. [Qiong] Yes. I agree anycast-based load balancing is a deployment choice. But if you use this tunnel mode, it can also be deployed in unicast scenario. So I recommend this tunnel mode in lw4over6. Is there some problem when we apply tunnel mode in particular ? > > The hash computation can be updated to rely on IP-based information, no > port numbers would be needed. > [Qiong] That will cost a lot, especially when lwAFTR is deployed in more a centralized way that a lot of routers along the path all need to be updated. > > > >Now, you want PCP to be load-balanced to the same lwAFTR as the > >IPv4-over-IPv6 tunnel. With the plain IPv6 mode, that's not going to > >work since the PCP flow will be hashed on the UDP 5-tuple. The way to > >ensure that the PCP traffic reaches the correct lwAFTR is to put PCP > >inside the tunnel. > [Med] Load-balancing can be achieved in various manners. Another scheme > would be to avoid the use of anycast-based LB but dispatch CPE to the > enabled lwAFTR by returning unicast addresses. > [Qiong] Agree. But in this deployment model, you will need another system to compute which CPE will be assigned to which lwAFTR dynamically. Anycast solution do not need to introduce this functionality. > > > > > > > > >> On the client side, you may indicate there is no need to include > >> THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests. > > > >Good suggestion. > > > >Isn't THIRD_PARTY needed with plain IPv6 mode? > [Med] Unlike DS-Lite case for which THIRD_PARTY is needed to successfully > do NAT in the AFTR, the lw4o6 only requires the IPv6@ of the lwB4 and not > the internal IPv4 address. This another reason to adopt the plain IPv6 > mode. The binding table will associate an IPv6@ with {IPv4@, Port Set}. > [Qiong] I do not quite understand why this is the reason for plain IPv6 mode. Even in the tunnel mode, the binding table can also associate the {IPv6@, IPv4@, Port set}. The IPv4 address inside the tunnel is the well-known address and do not need to be kept in the mapping table. Best wishes Qiong > > > > >Simon > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --20cf307f337e4426ad04de78a696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Med,

Thanks for your comments!= See my reply inline.


On Thu, Jun 6, 2013 at 4:17 PM, <mohamed.boucada= ir@orange.com> wrote:
Re-,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=C2=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=C3=A9=C2=A0: jeudi 6 juin 2013 10:02
>=C3=80=C2=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=C2=A0: pcp@ietf.org
>Objet=C2=A0: Re: [pcp] Fwd: New Version Notification for draft-perreaul= t-
>softwire-lw4over6-pcp-00.txt
>
>Le 2013-06-06 09:42, mohamed.boucadair@orange.com a =C3=A9crit :
>> I suggest pcp for lw4o6 to follow the some design choices as those= of
>> ds-lite. In particular: * adopt the plaine IPv6 mode which is
>> currently supported by various vendors.
[Qiong] DS-Lite would also have the same problem when deploying anyc= ast-based load balancing. I strongly suggest that DS-Lite should also inclu= de this tunnel mode=C2=A0especially=C2=A0for this scenario.
>
>I'm well aware of this, but it is problematic.
>
>Consider the use case of a load-balanced lwAFTR. The load balancing is<= br> >based on L4 hashing. You have a bunch of IPv4-over-IPv6 tunnels being >load-balanced this way over a bunch of lwAFTRs. For those tunnel, the L= 4
>hash is calculated over a 3-tuple: source IPv6 address, destination IPv= 6
>address, and protocol number. No port numbers are available to build a<= br> >5-tuple.
[Med] This is deployment-specific.
=C2=A0
=
[Qiong] Yes. I agree anycast-based load balancing is a deployment choi= ce. But if you use this tunnel mode, it can also be deployed in unicast sce= nario. So I recommend this tunnel mode in lw4over6. Is there some problem w= hen we apply tunnel mode in particular ?
=C2=A0
The hash computation can be updated to rely on IP-based information, no por= t numbers would be needed.
[Qiong] That will cos= t a lot,=C2=A0especially when lwAFTR is deployed in more a centralized way = that a lot of routers along the path all need to be updated. =C2=A0=C2=A0= =C2=A0
>
>Now, you want PCP to be load-balanced to the same lwAFTR as the
>IPv4-over-IPv6 tunnel. With the plain IPv6 mode, that's not going t= o
>work since the PCP flow will be hashed on the UDP 5-tuple. The way to >ensure that the PCP traffic reaches the correct lwAFTR is to put PCP >inside the tunnel.
[Med] Load-balancing can be achieved in various manners. Another sche= me would be to avoid the use of anycast-based LB but dispatch CPE to the en= abled lwAFTR by returning unicast addresses.
[Qiong] Agree. But in this deployment model, you will need another system t= o compute which CPE will be assigned to which lwAFTR dynamically. Anycast s= olution do not need to introduce this functionality.

>
>
>
>> On the client side, you may indicate there is no need to include >> THIRD_PARTY, PREFER_FAILURE and FILTER options in MAP requests. >
>Good suggestion.
>
>Isn't THIRD_PARTY needed with plain IPv6 mode?
[Med] Unlike DS-Lite case for which THIRD_PARTY is needed to successf= ully do NAT in the AFTR, the lw4o6 only requires the IPv6@ of the lwB4 and = not the internal IPv4 address. This another reason to adopt the plain IPv6 = mode. The binding table will associate an IPv6@ with {IPv4@, Port Set}.
[Qiong] I do not quite understand why this is the r= eason for plain IPv6 mode. Even in the tunnel mode, the binding table can a= lso associate the {IPv6@, IPv4@, Port set}. The IPv4 address inside the tun= nel is the well-known address and do not need to be kept in the mapping tab= le.

Best wishes
Qiong=C2=A0

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



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>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
--20cf307f337e4426ad04de78a696-- From simon.perreault@viagenie.ca Thu Jun 6 02:42:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF93621F8EC3 for ; Thu, 6 Jun 2013 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQLmfluCJzwh for ; Thu, 6 Jun 2013 02:42:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B45821F8FAF for ; Thu, 6 Jun 2013 02:42:04 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:2905:fce2:6a47:af4e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AABCE4011E; Thu, 6 Jun 2013 05:41:55 -0400 (EDT) Message-ID: <51B05964.1080208@viagenie.ca> Date: Thu, 06 Jun 2013 11:41:56 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Qiong References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 09:42:05 -0000 Le 2013-06-06 11:07, Qiong a écrit : > The hash computation can be updated to rely on IP-based information, > no port numbers would be needed. > > [Qiong] That will cost a lot, especially when lwAFTR is deployed in more > a centralized way that a lot of routers along the path all need to be > updated. I think this is a core issue that needs discussion. Qiong, are you referring to ECMP? Simon From bingxuere@gmail.com Thu Jun 6 06:27:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83421F9A0D for ; Thu, 6 Jun 2013 06:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FRJCbOPEczJ for ; Thu, 6 Jun 2013 06:27:19 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE9C21F9A0B for ; Thu, 6 Jun 2013 06:27:19 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q11so3338527pdj.38 for ; Thu, 06 Jun 2013 06:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=Jq9JBee+M5PsAe9n0Zf7mnB9nMMAaYlTbUNuBW0FPmo=; b=v0MFiPnbymNgZ4RjuEFlscmEgF1ZMsyOumpoHCxPL9oUc7kAgV/lZS+RTsg5wkCk2X Y5ixlzeihY/D33NC5lt5Is0zhMuNjiaaDjuIry+bIay7epgo2VB+6O/+uGR2hOWH4VUD aDlkWLc4YfTdjW/vAQ2i2Cqtzgyx+xw6lVwz9CNf9JFaRWGW0GeWjsqWkjITonEK6REb huQSZlceOco3rMPLUU8jQNYa+Cb6GSq4ej4w/N0jgiFm05q7UwELd9ceUtRnUqykh4Fz t/x7S66azfxr5SnqLT+kKpJ22FEPatd4r1D9OS/9Kfta+gbiDihcGloig1aAFKvRn3SI CJuA== X-Received: by 10.68.230.195 with SMTP id ta3mr38095803pbc.60.1370525238838; Thu, 06 Jun 2013 06:27:18 -0700 (PDT) Received: from [192.168.11.9] ([114.254.97.168]) by mx.google.com with ESMTPSA id tb7sm72881873pbc.14.2013.06.06.06.27.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 06:27:18 -0700 (PDT) References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> <51B05964.1080208@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <51B05964.1080208@viagenie.ca> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Message-Id: <4BCA290E-BBD9-4AF5-976A-24B9644A62C4@gmail.com> X-Mailer: iPad Mail (10A8500) From: "bingxuere@gmail.com" Date: Thu, 6 Jun 2013 21:27:13 +0800 To: Simon Perreault Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:27:25 -0000 Hi Simon, On 2013-6-6, at 17:41, Simon Perreault wrote: > Le 2013-06-06 11:07, Qiong a =A8=A6crit : >> The hash computation can be updated to rely on IP-based information, >> no port numbers would be needed. >>=20 >> [Qiong] That will cost a lot, especially when lwAFTR is deployed in more >> a centralized way that a lot of routers along the path all need to be >> updated. >=20 > I think this is a core issue that needs discussion. >=20 > Qiong, are you referring to ECMP? [Qiong] Right, exactly. Currently, our routers from different vendors even w= ith different versions may implement ECMP differently. Best wishes Qiong >=20 > Simon From ssenthil@cisco.com Thu Jun 6 06:32:22 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E521F9590 for ; Thu, 6 Jun 2013 06:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HItskaOaDFv for ; Thu, 6 Jun 2013 06:32:06 -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 78B3421F8EA5 for ; Thu, 6 Jun 2013 06:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3730; q=dns/txt; s=iport; t=1370525526; x=1371735126; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WncvBfnMXidbSUHaygEyF9E5QY4IzSzaKfN2/lc5sEQ=; b=GTIi+gJO0YWO8xQ8aknEvjElGKQI9EDi6/gyzUeWZ0mjA2jwaepMQzm+ l779tiWCa6Rstq3CxhCtX82yS5vOFf9Wjlf/bRnLv3H9hD/AjQdlsyM+V jD3/MMgktqRbSMWy9iPMWEsAC8Yh74TFOHNDuAqbvqrRXbrn5/MPcezND Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAP6NsFGtJXHA/2dsb2JhbABPCoMJML9HeBZ0giMBAQEEeRIBCBgKHTkUEQIEAQ0FCAGIBAy7GY12FHUCMQeCemEDiGiLBYR7ineFIIMPgic X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219350934" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 06 Jun 2013 13:32:06 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r56DW5k9015546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 13:32:05 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 08:32:05 -0500 From: "Senthil Sivakumar (ssenthil)" To: "mohamed.boucadair@orange.com" , "pcp issue tracker" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Thread-Topic: [pcp] #63: Handling multiple prefixes Thread-Index: AQHOXlHExdMnhekn80OxiNm3pUsvuJklpesAgABblgCAAMy/0IAB+lOA Date: Thu, 6 Jun 2013 13:32:04 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED4CD0039@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.112] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <889377CE40B9E54E98F709816BE9C315@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:32:22 -0000 Hi Med, Can you please revise the first sentence as "The PCP server is required to disambiguate", the rest of the text clarifies the questions that I had. Thanks Senthil On 6/5/13 4:21 AM, "mohamed.boucadair@orange.com" wrote: >Hi Senthil, > >You can find this text in the new version available at: >http://www.ietf.org/id/draft-ietf-pcp-nat64-prefix64-03.txt > >The PCP server is supposed to be able to disambiguate > prefixes used for IPv6 address synthesis and other prefixes used > to avoid any NAT64 deployed in the network. The PCP server can be > configured with a customized IPv6 prefix list (i.e., specific to a > PCP client or a group of PCP clients) or system-wise IPv6 prefix > list (i.e., the same list is return for any PCP client). > > >Please let me know if this text answers your two question. > >Cheers, >Med > >>-----Message d'origine----- >>De : Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] >>Envoy=E9 : mardi 4 juin 2013 21:07 >>=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp issue tracker; draft-ietf-pcp-nat64= - >>prefix64@tools.ietf.org >>Cc : pcp@ietf.org >>Objet : Re: [pcp] #63: Handling multiple prefixes >> >>Hi Med, >> >>On 6/4/13 5:39 AM, "mohamed.boucadair@orange.com" >> wrote: >> >>>Hi Senthil, >>> >>>Thank you for the review. >>> >>>The current text says the following: >>> >>> When multiple prefixes are configured in a network, the PCP server >>> MAY be configured to return multiple PREFIX64 options in the same >>> message to the PCP client. The PCP server includes in the first >>> PREFIX64 option, which appears in the PCP message it sends to the PCP >>> client, the prefix to perform local IPv6 address synthesis [RFC6052]. >>> Remaining PREFIX64 options convey any other Pref64::/n values >>> configured . Returning these prefixes allows an end host to identify >>> them as translated addresses, and instead prefer IPv4 or an >>> alternative network interface in order to avoid any NAT64 deployed in >>> the network. >>> >>>Doesn't this text solves your concern? Or you think more elaboration is >>>needed? >> >>I have two questions/comments about this text. >>1. How should the server order these prefixes? >>2.How does the server know which prefix should be the first prefix handed >>to the requesting client? >> >>Thanks >>Senthil >>> >>>Cheers, >>>Med >>> >>> >>>>-----Message d'origine----- >>>>De : pcp issue tracker [mailto:trac@tools.ietf.org] >>>>Envoy=E9 : samedi 1 juin 2013 00:54 >>>>=C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org; ssenthil@cisco.com >>>>Cc : pcp@ietf.org >>>>Objet : [pcp] #63: Handling multiple prefixes >>>> >>>>#63: Handling multiple prefixes >>>> >>>> The only comment I have is this document doesn't address the multiple >>>> prefixes that could be present on a NAT64 device. >>>> Any guidelines on which prefix should be reported would be useful. >>>> >>>>-- >>>>-------------------------------------+--------------------------------- >>>>-- >>>>-- >>>> Reporter: Senthil Sivakumar | Owner: draft-ietf-pcp- >>>> (ssenthil) | nat64-prefix64@tools.ietf.org >>>> Type: defect | Status: new >>>> Priority: major | Milestone: >>>>Component: nat64-prefix64 | Version: >>>> Severity: - | Keywords: >>>>-------------------------------------+--------------------------------- >>>>-- >>>>-- >>>> >>>>Ticket URL: >>>>pcp >>> > From mohamed.boucadair@orange.com Thu Jun 6 06:42:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE50A21F9246 for ; Thu, 6 Jun 2013 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqMaakjjs7TT for ; Thu, 6 Jun 2013 06:42:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3421F91CE for ; Thu, 6 Jun 2013 06:42:39 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C86013258AC; Thu, 6 Jun 2013 15:42:37 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8040727C092; Thu, 6 Jun 2013 15:42:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 6 Jun 2013 15:42:37 +0200 From: To: "Senthil Sivakumar (ssenthil)" , pcp issue tracker , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Date: Thu, 6 Jun 2013 15:42:35 +0200 Thread-Topic: [pcp] #63: Handling multiple prefixes Thread-Index: AQHOXlHExdMnhekn80OxiNm3pUsvuJklpesAgABblgCAAMy/0IAB+lOA///yBmA= Message-ID: <94C682931C08B048B7A8645303FDC9F36ED4CD05BA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36ED4CD0039@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:42:44 -0000 Hi Senthil, Fixed in my local copy. Thanks. Cheers, Med >-----Message d'origine----- >De=A0: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] >Envoy=E9=A0: jeudi 6 juin 2013 15:32 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp issue tracker; draft-ietf-pcp-nat6= 4- >prefix64@tools.ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] #63: Handling multiple prefixes > >Hi Med, >Can you please revise the first sentence as >"The PCP server is required to disambiguate", the rest of the text >clarifies the questions that I had. > >Thanks >Senthil > >On 6/5/13 4:21 AM, "mohamed.boucadair@orange.com" > wrote: > >>Hi Senthil, >> >>You can find this text in the new version available at: >>http://www.ietf.org/id/draft-ietf-pcp-nat64-prefix64-03.txt >> >>The PCP server is supposed to be able to disambiguate >> prefixes used for IPv6 address synthesis and other prefixes used >> to avoid any NAT64 deployed in the network. The PCP server can be >> configured with a customized IPv6 prefix list (i.e., specific to a >> PCP client or a group of PCP clients) or system-wise IPv6 prefix >> list (i.e., the same list is return for any PCP client). >> >> >>Please let me know if this text answers your two question. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] >>>Envoy=E9 : mardi 4 juin 2013 21:07 >>>=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp issue tracker; draft-ietf-pcp-nat6= 4- >>>prefix64@tools.ietf.org >>>Cc : pcp@ietf.org >>>Objet : Re: [pcp] #63: Handling multiple prefixes >>> >>>Hi Med, >>> >>>On 6/4/13 5:39 AM, "mohamed.boucadair@orange.com" >>> wrote: >>> >>>>Hi Senthil, >>>> >>>>Thank you for the review. >>>> >>>>The current text says the following: >>>> >>>> When multiple prefixes are configured in a network, the PCP server >>>> MAY be configured to return multiple PREFIX64 options in the same >>>> message to the PCP client. The PCP server includes in the first >>>> PREFIX64 option, which appears in the PCP message it sends to the PC= P >>>> client, the prefix to perform local IPv6 address synthesis [RFC6052]= . >>>> Remaining PREFIX64 options convey any other Pref64::/n values >>>> configured . Returning these prefixes allows an end host to identify >>>> them as translated addresses, and instead prefer IPv4 or an >>>> alternative network interface in order to avoid any NAT64 deployed i= n >>>> the network. >>>> >>>>Doesn't this text solves your concern? Or you think more elaboration is >>>>needed? >>> >>>I have two questions/comments about this text. >>>1. How should the server order these prefixes? >>>2.How does the server know which prefix should be the first prefix hande= d >>>to the requesting client? >>> >>>Thanks >>>Senthil >>>> >>>>Cheers, >>>>Med >>>> >>>> >>>>>-----Message d'origine----- >>>>>De : pcp issue tracker [mailto:trac@tools.ietf.org] >>>>>Envoy=E9 : samedi 1 juin 2013 00:54 >>>>>=C0 : draft-ietf-pcp-nat64-prefix64@tools.ietf.org; ssenthil@cisco.com >>>>>Cc : pcp@ietf.org >>>>>Objet : [pcp] #63: Handling multiple prefixes >>>>> >>>>>#63: Handling multiple prefixes >>>>> >>>>> The only comment I have is this document doesn't address the multiple >>>>> prefixes that could be present on a NAT64 device. >>>>> Any guidelines on which prefix should be reported would be useful. >>>>> >>>>>-- >>>>>-------------------------------------+--------------------------------= - >>>>>-- >>>>>-- >>>>> Reporter: Senthil Sivakumar | Owner: draft-ietf-pcp- >>>>> (ssenthil) | nat64-prefix64@tools.ietf.org >>>>> Type: defect | Status: new >>>>> Priority: major | Milestone: >>>>>Component: nat64-prefix64 | Version: >>>>> Severity: - | Keywords: >>>>>-------------------------------------+--------------------------------= - >>>>>-- >>>>>-- >>>>> >>>>>Ticket URL: >>>>>pcp >>>> >> From trac@tools.ietf.org Thu Jun 6 06:43:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0F21F9298 for ; Thu, 6 Jun 2013 06:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KgdmhAolFzw for ; Thu, 6 Jun 2013 06:43:09 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 875C821F9246 for ; Thu, 6 Jun 2013 06:43:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:39730 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UkaT6-0003RN-Gq; Thu, 06 Jun 2013 15:43:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: pcp Date: Thu, 06 Jun 2013 13:43:08 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/63#comment:1 Message-ID: <102.67561f4053723ee4c3e09b77e83c8dee@tools.ietf.org> References: <087.ac7253502d63a2734c727a805a0fb5f7@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <087.ac7253502d63a2734c727a805a0fb5f7@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, mohamed.boucadair@orange.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mohamed.boucadair@orange.com Resent-Message-Id: <20130606134309.875C821F9246@ietfa.amsl.com> Resent-Date: Thu, 6 Jun 2013 06:43:09 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #63: Handling multiple prefixes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:43:10 -0000 #63: Handling multiple prefixes Changes (by mohamed.boucadair@orange.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: Senthil Sivakumar | Owner: draft-ietf-pcp- (ssenthil) | nat64-prefix64@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nat64-prefix64 | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: pcp From cheshire@apple.com Thu Jun 6 16:37:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1321F9951 for ; Thu, 6 Jun 2013 16:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuO6EvogJ6qn for ; Thu, 6 Jun 2013 16:37:51 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 973D321F9944 for ; Thu, 6 Jun 2013 16:37:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNZ00CZSWAXLYK2@mail-out.apple.com> for pcp@ietf.org; Thu, 06 Jun 2013 16:37:46 -0700 (PDT) X-AuditID: 11807143-b7f856d000000818-27-51b11d4a83de Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 1F.2F.02072.A4D11B15; Thu, 06 Jun 2013 16:37:46 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNZ006DRWAX1S00@spicerack.apple.com> for pcp@ietf.org; Thu, 06 Jun 2013 16:37:46 -0700 (PDT) From: Stuart Cheshire In-reply-to: <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 06 Jun 2013 16:37:45 -0700 Message-id: <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FCsoesluzHQoL2b32Lysd+sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmPd4D3tBI3/F7b8/2RoYf3B3MXJySAiYSBzff5ARwhaTuHBv PVsXIxeHkMBkJokfVyYxQTgrmCSmXz7OClLFLKAj0fv9GzOIzSugJ7Ft7jY2EFtYQFvi7e1b 7CA2m4CWxIvPV8DinAJxEi//bAOrZxFQlZj3rY0NYo62xJN3F1gh5thIHPu9mBFi2UFGiY9/ NrCAJEQEFCUObLvBDnGerMTr529YJjDyz0Jyxywkd8xCMncBI/MqRoGi1JzESiO9xIKCnFS9 5PzcTYzgICt03sF4bJnVIUYBDkYlHt4FKzYECrEmlhVX5h5ilOBgVhLh5XsBFOJNSaysSi3K jy8qzUktPsQozcGiJM7rULA+UEggPbEkNTs1tSC1CCbLxMEp1cBY6LzPpX6viOIH49PJP0+m 3Ft85fXe4GjvTX9utnfZPTkvkZI6jTErsFM4+4ewst7qgqUXwx0fTpvya57E6wPd0y7MtRCd E3J4+uO6Se2pO27vO9G549lMexW23f0xRdJP0t8JH4j+evG198peI0/9D+/FXyvsr0ufGFdm IvLR7O6kyENLmr63KrEUZyQaajEXFScCAHRVeH4uAgAA Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 23:37:58 -0000 On 5 Jun, 2013, at 02:17, mohamed.boucadair@orange.com wrote: > Stuart, > > I'm objecting your proposal because I don't want to add a new failure case to the list we already have. > > There is a risk that some PCP clients won't try all AFs for the same PCP server and therefore the host won't be able to receive incoming packets via that PCP-controlled device. Consider an IPv6-only client behind a NAT64. If the pcp client asks for IPv6 external address, the server will reject it with the error you are proposing. If the pcp client does not try another AF, the IPv6-only host cannot receive incoming sessions from an IPv4-only host. If the client writer had thought about IPv6, then the client would ask for an IPv6 external address. If the client does not, chances are the client writer never thought about that, and the code will likely fail (or even crash) when given an IPv6 external address. If we allow what you want, the PCP adoption road map goes like this: Early PCP servers only support IPv4. Early PCP clients only support IPv4. In fact, some early PCP clients mistakenly pass the IPv6 all zeroes address, and the early PCP servers give them back an IPv4 external address anyway, which the client then puts in a DNS IPv4 address record. So it all works, but largely though good luck. Now, with this ecosystem in place, a vendor wants to introduce a gateway that supports IPv6. Hooray! We all want that. But this gateway returns an IPv6 external address, and a whole bunch of existing clients crash or otherwise fail in response to that. Management says the company can't ship a gateway that breaks existing clients. So the path you propose leads to a dead end where PCP can never add support for IPv6, because of buggy clients that were allowed to exist by overly-lenient early implementations. Stuart Cheshire From cheshire@apple.com Thu Jun 6 16:54:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9DE21F9950 for ; Thu, 6 Jun 2013 16:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVO+8TJ44bTV for ; Thu, 6 Jun 2013 16:54:04 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 547CF21F9954 for ; Thu, 6 Jun 2013 16:54:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNZ00K21X1JN8L1@mail-out.apple.com> for pcp@ietf.org; Thu, 06 Jun 2013 16:53:47 -0700 (PDT) X-AuditID: 11807165-b7f496d000000613-49-51b1210bbd38 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id F8.F9.01555.B0121B15; Thu, 06 Jun 2013 16:53:47 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNZ00616X1N1S10@spicerack.apple.com> for pcp@ietf.org; Thu, 06 Jun 2013 16:53:47 -0700 (PDT) From: Stuart Cheshire In-reply-to: <05D1C90B-5B1B-40D3-8EE3-FEC22D48FC4C@cisco.com> Date: Thu, 06 Jun 2013 16:53:47 -0700 Message-id: References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <05D1C90B-5B1B-40D3-8EE3-FEC22D48FC4C@cisco.com> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FCsocutuDHQYMY2aYvJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoEro3lqScFMvoqJN1axNjBO4+5i5OSQEDCReL32FxuELSZx4d56 IJuLQ0hgMpPExRNbmCGcFUwSt1smgFUxC2hJrN95nAnE5hXQk9g2dxtQnINDGMheejQHJMwG VPLi8xWwck4BW4npE3+xgNgsAqoSF2acZIIYoy3x5N0FVogxNhL3p85kBLGFBPIlLm1/CWaL CChKHNh2gx3iOFmJ18/fsExg5J+F5IpZSK6YhWTsAkbmVYwCRak5iZXmeokFBTmpesn5uZsY weFVmLqDsXG51SFGAQ5GJR7eH6s2BAqxJpYVV+YeYpTgYFYS4eV7ARTiTUmsrEotyo8vKs1J LT7EKM3BoiTO61SwPlBIID2xJDU7NbUgtQgmy8TBKdXAaNk0/Z3xDufniRuf64WFMV38xbNA eWvS7zbzzcskxMzqORucw34s+qzmO2vaLZW+5xPz2NYxPVKeqp2QrdTdmrYhf4P8/ALRSZcv /Wo8d7hltVyQT5CC28HDbw+HvTnMYr+855lPp9QjtRumq/KuqsZkf5UXu/Ls7ONLZ2XuS0aX 3ZGo6Ulbo8RSnJFoqMVcVJwIAESlltgrAgAA Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 23:54:11 -0000 On 4 Jun, 2013, at 19:26, Dan Wing wrote: > On Jun 4, 2013, at 4:39 PM, Stuart Cheshire wrote: > >> It looks like we're starting to accumulate a growing list of issues to document in an addendum to RFC 6887. >> >> If operating in the Simple Threat Model (Section 18.1), and the >> internal port, protocol, and internal address match an existing >> explicit dynamic mapping, but the mapping nonce does not match, the >> request MUST be rejected with a NOT_AUTHORIZED error with the >> lifetime of the error indicating duration of that existing mapping. >> The PCP server only needs to remember one Mapping Nonce value for >> each explicit dynamic mapping. >> >> Here's the problem: >> >> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins. >> 2. Client reboots, or similar, and picks new nonce. > > Can the client remember its nonce across reboots, or similar? RFC 6887 says: The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. How does the PCP client know for sure when it's talking to a new PCP server? Practically speaking, it has to err on the side of caution and pick a new nonce if it *might* be talking to a new PCP server. My broader point is this: If the NAT gateway is actually forwarding inbound traffic to 10.0.0.2:22, how is it useful for it to lie to the client and claim that it is not? i.e.: 1. Client says, "Please forward inbound SYNs to me at 10.0.0.2:22." 2. Server says, "No! NOT_AUTHORIZED!" but then proceeds to forward inbound SYNs to the client at 10.0.0.2:22 anyway. Stuart Cheshire From mohamed.boucadair@orange.com Thu Jun 6 23:48:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790D321F9248 for ; Thu, 6 Jun 2013 23:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BzLPFNOrx7Y for ; Thu, 6 Jun 2013 23:48:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 280AB21F93BA for ; Thu, 6 Jun 2013 23:47:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E397622D859; Fri, 7 Jun 2013 08:47:58 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C7140238055; Fri, 7 Jun 2013 08:47:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 7 Jun 2013 08:47:58 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Fri, 7 Jun 2013 08:47:55 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5jDuOPbvCmhaJPRY2CFJvfiAkj5QAOQgnQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> In-Reply-To: <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 06:48:04 -0000 Stuart, I'm re-iterating below what I'm suggesting: * The PCP client can indicate a *** preferred *** AF in the Suggested Exter= nal IP Address. * The PCP client MUST be prepared to receive an address of a distinct AF th= an the one indicated in the request. * The PCP server will try to honor the suggested AF, but it will always ret= urn an address belonging to the AF it supports (modulo port quota checks).= =20 * It is up to the PCP client to make use of the address returned by the PCP= server or not. * If the PCP client has no indication about the capabilities of the server,= the PCP client may try two requests each one with a # suggested AF. Instead of returning an error, an offer is made to the client. This behavior maximizes the chance to get an address and make use of it. I fail to see how this mode will induce failures. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: vendredi 7 juin 2013 01:38 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On 5 Jun, 2013, at 02:17, mohamed.boucadair@orange.com wrote: > >> Stuart, >> >> I'm objecting your proposal because I don't want to add a new failure >case to the list we already have. >> >> There is a risk that some PCP clients won't try all AFs for the same PCP >server and therefore the host won't be able to receive incoming packets vi= a >that PCP-controlled device. Consider an IPv6-only client behind a NAT64. I= f >the pcp client asks for IPv6 external address, the server will reject it >with the error you are proposing. If the pcp client does not try another >AF, the IPv6-only host cannot receive incoming sessions from an IPv4-only >host. > >If the client writer had thought about IPv6, then the client would ask for >an IPv6 external address. If the client does not, chances are the client >writer never thought about that, and the code will likely fail (or even >crash) when given an IPv6 external address. > >If we allow what you want, the PCP adoption road map goes like this: > >Early PCP servers only support IPv4. > >Early PCP clients only support IPv4. > >In fact, some early PCP clients mistakenly pass the IPv6 all zeroes >address, and the early PCP servers give them back an IPv4 external address >anyway, which the client then puts in a DNS IPv4 address record. So it all >works, but largely though good luck. > >Now, with this ecosystem in place, a vendor wants to introduce a gateway >that supports IPv6. Hooray! We all want that. But this gateway returns an >IPv6 external address, and a whole bunch of existing clients crash or >otherwise fail in response to that. Management says the company can't ship >a gateway that breaks existing clients. > >So the path you propose leads to a dead end where PCP can never add suppor= t >for IPv6, because of buggy clients that were allowed to exist by overly- >lenient early implementations. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Fri Jun 7 05:39:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13E721F918C for ; Fri, 7 Jun 2013 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQio1SDPcDus for ; Fri, 7 Jun 2013 05:39:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 271AD21F9298 for ; Fri, 7 Jun 2013 05:39:48 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E4A05324838; Fri, 7 Jun 2013 14:39:47 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5CF504C0C4; Fri, 7 Jun 2013 14:39:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 7 Jun 2013 14:39:29 +0200 From: To: "bingxuere@gmail.com" , Simon Perreault Date: Fri, 7 Jun 2013 14:39:25 +0200 Thread-Topic: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt Thread-Index: Ac5iuZMr5Be4F53tQYa+CgdpslXs+QAwb4dg Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED01D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130604085406.11827.2429.idtracker@ietfa.amsl.com> <51ADD61C.1040106@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD03C1@PUEXCB1B.nanterre.francetelecom.fr> <51B041F6.6040800@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED4CD0401@PUEXCB1B.nanterre.francetelecom.fr> <51B05964.1080208@viagenie.ca> <4BCA290E-BBD9-4AF5-976A-24B9644A62C4@gmail.com> In-Reply-To: <4BCA290E-BBD9-4AF5-976A-24B9644A62C4@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] Fwd: New Version Notification for draft-perreault-softwire-lw4over6-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:39:58 -0000 Please see inline. >-----Message d'origine----- >De=A0: bingxuere@gmail.com [mailto:bingxuere@gmail.com] >Envoy=E9=A0: jeudi 6 juin 2013 15:27 >=C0=A0: Simon Perreault >Cc=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org >Objet=A0: Re: [pcp] Fwd: New Version Notification for draft-perreault- >softwire-lw4over6-pcp-00.txt > >Hi Simon, > >On 2013-6-6, at 17:41, Simon Perreault wrote= : > >> Le 2013-06-06 11:07, Qiong a =E9crit : >>> The hash computation can be updated to rely on IP-based information, >>> no port numbers would be needed. >>> >>> [Qiong] That will cost a lot, especially when lwAFTR is deployed in mor= e >>> a centralized way that a lot of routers along the path all need to be >>> updated. [Med] .. but isn't L3-based ECMP LB needed for lw4over6 to work in your cas= e? >> >> I think this is a core issue that needs discussion. >> >> Qiong, are you referring to ECMP? >[Qiong] Right, exactly. Currently, our routers from different vendors even >with different versions may implement ECMP differently. [Med] Can you please point out an industrial product which supports L4-base= d ECMP LB and not L3-based one? > >Best wishes > >Qiong >> >> Simon From sardella@comcast.net Fri Jun 7 11:42:36 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C421F8EC6 for ; Fri, 7 Jun 2013 11:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haHRBcC3weYD for ; Fri, 7 Jun 2013 11:42:32 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E669F21F8D27 for ; Fri, 7 Jun 2013 11:42:31 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id lPGQ1l0051c6gX851WiXbM; Fri, 07 Jun 2013 18:42:31 +0000 Received: from sardella.org ([66.31.217.148]) by omta23.westchester.pa.mail.comcast.net with comcast id lWiW1l00F3ChNai3jWiXPy; Fri, 07 Jun 2013 18:42:31 +0000 Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by sardella.org (8.13.1/8.13.1) with ESMTP id r57IgTqM019491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 14:42:29 -0400 Message-ID: <51B22995.6000609@comcast.net> Date: Fri, 07 Jun 2013 14:42:29 -0400 From: Norman Sardella User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20130530092631.2199.13076.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36ED3A08301@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A08301@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370630551; bh=7SVQrZovk4gqzeNtvNamitCaJNWOFPzHOiffh5yldhc=; h=Received:Received:Received:Message-ID:Date:From:MIME-Version:To: Subject:Content-Type; b=hLDp8mMlkVWUtyI2/gchD0/O/H0cciGu1bO4aE6pChxCOLO8X2wmSBXxnLZZoCLr4 FjG7fGAUTGsMeVNaSd4MStPxV+pJOs+Ca+vw0Iibx0PESJlTqPJWUocgzBrv4byZM7 o4gkHp7a1kgfVYmQugskwahe0iNbBhryq5FSym+ZB9zfhceJG4EgmKL/WEuLVHy5E4 Xrot22u7t3/sEyOAVMmmEuvCBerOOtbmbUrEVGjodNPFO+4xmW53RofDxVHDvm85mj ZtdDTmHtdN7E8u9F06wtXuZ0EDc6qs//UU2QyPbVoFQOwqcm37ePFgi/3gHQV+odk+ EXWguKCw3Ru+A== Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:42:37 -0000 Mohamed I have a question in your examples in section 2.12, about returning remaining idle-timeout on MAP delete response > |--------------------------------->| > | PCP MAP Response (Lifetime= | > | remaining idle-timeout) | Some LSN implementations are incapable of returning the remaining lifetime because each flow creates a separate NAT translation based of the PCP master created NAT entry. In this case, which of the other NAT entries would we pick to return an idle-timeout? How are PCP clients expected to use the lifetime in delete mappings responses? Should a PCP server return 0, return idle-timeout value, or the age remaining when the PCP master NAT entry was created? Thanks Norman Sardella On 05/30/2013 05:36 AM, mohamed.boucadair@orange.com wrote: > Dear all, > > This updated version includes two additional use case suggested by Dan. > > Don't hesitate to share any use case you think it is worth to be documented this I-D. > > Cheers, > Med > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] De la part de internet-drafts@ietf.org > Envoyé : jeudi 30 mai 2013 11:27 > À : i-d-announce@ietf.org > Objet : I-D Action: draft-boucadair-pcp-flow-examples-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : PCP Flow Examples > Author(s) : Mohamed Boucadair > Filename : draft-boucadair-pcp-flow-examples-01.txt > Pages : 32 > Date : 2013-05-30 > > Abstract: > This document provides a set of examples to illustrate PCP > operations. It is a companion document to the base PCP > specification. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-flow-examples-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From bn.mccann@gmail.com Fri Jun 7 11:52:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92A21F8540 for ; Fri, 7 Jun 2013 11:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24U34hx++vhI for ; Fri, 7 Jun 2013 11:51:54 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6720A21F9950 for ; Fri, 7 Jun 2013 11:51:54 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q11so5147064pdj.10 for ; Fri, 07 Jun 2013 11:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=TOPnAqEy+G8drliwpqeoQ0bHaO9fjxJ+dIgY8xdLAfs=; b=C92MFuyjMdy9zSnFjPiQHQ7HTCbE58cEjfjNQWj7EI6G5oHKznkSVmeaXgGk4MlBJp hEdLfdC2QJ2i8mqbg7cjoIlfI677IcdWu8lf8bnfynIVAcj0BxteLr5E9oZKEXRZyKF7 uK/sOffnmtwx8eosW6pX51m4yypfg3maEwWyCAQN2qxOuQertVX1NS5w4B8pTYa+Ldez P2Txz0CcOry9wiA3LHyUVKZ5eY9ps7RN8pmAPgA3OAsV3mVtLIpOft9X67/9itZEMBYg Ozf0915w2rONIOsOB8Hd6s+W4/Z9bv0e6nb72aQXehSmGu1Qf14bzeVSXIgIYcV9Zbfs 3+4A== X-Received: by 10.68.90.131 with SMTP id bw3mr56219pbb.59.1370631113355; Fri, 07 Jun 2013 11:51:53 -0700 (PDT) Received: from [172.19.131.157] ([12.130.126.121]) by mx.google.com with ESMTPSA id uv1sm50996pbc.16.2013.06.07.11.51.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 11:51:52 -0700 (PDT) Message-ID: <51B22BA4.1050007@gmail.com> Date: Fri, 07 Jun 2013 14:51:16 -0400 From: Ben McCann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: pcp@ietf.org Content-Type: multipart/alternative; boundary="------------070705090002030302090104" Subject: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 18:52:00 -0000 This is a multi-part message in MIME format. --------------070705090002030302090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrates how a client can learn the external IP address of and port of an *existing implicit mapping *by using the *MAP *opcode. I can't find any reference to that capability in RFC 6887 but I do see a reference in Section 12.2 (Generating a Peer Request) that discusses how a client can use the *PEER *opcode to learn the external address and port of an existing implicit mapping. Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate use of the *PEER *opcode? Thanks, Ben McCann --------------070705090002030302090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrates how a client can learn the external IP address of and port of an existing implicit mapping by using the MAP opcode.

I can't find any reference to that capability in RFC 6887 but I do see a reference in Section 12.2 (Generating a Peer Request) that discusses how a client can use the PEER opcode to learn the external address and port of an existing implicit mapping.

Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate use of the PEER opcode?

Thanks,
Ben McCann

--------------070705090002030302090104-- From dwing@cisco.com Fri Jun 7 14:03:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6512421F89A5 for ; Fri, 7 Jun 2013 14:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zp72qUsnORF for ; Fri, 7 Jun 2013 14:03:23 -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 F3EFA21F9302 for ; Fri, 7 Jun 2013 14:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2249; q=dns/txt; s=iport; t=1370639003; x=1371848603; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ExZpDICIneqbTVPxOPBq17YHGN1ZSkCnQodKrpkq3/M=; b=ZpIcA6QL+fnmOYlR58dJ9mHMwqPDK9Szhi7aMbmQvaLfH65zBXHb2zMw 07WfEUmHhocr0MIchx3gtgF+Dbx+KjNrkE71dmT1UMT1gKl1S+sKcHjbT FaPXXovrAkhWBuh6Zhu1TgeD18QbaaxwENPpqDAHB5VBjwv8MrJ9ouKK1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAC5KslGrRDoG/2dsb2JhbABZgwm/IIEBFnSCIwEBAQMBOj8FCwsYLlcGE4gHBbxtjwUzB4J7YQOJII4ghh+LI4MvHA X-IronPort-AV: E=Sophos;i="4.87,824,1363132800"; d="scan'208";a="80483853" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Jun 2013 21:03:20 +0000 Received: from [10.156.16.238] ([10.156.16.238]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r57L3Km6007809; Fri, 7 Jun 2013 21:03:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Fri, 7 Jun 2013 14:03:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <625EB543-060C-44B6-A025-CA1B5BFDAF75@cisco.com> References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <05D1C90B-5B1B-40D3-8EE3-FEC22D48FC4C@cisco.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1503) Cc: "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 07 Jun 2013 21:03:32 -0000 On Jun 6, 2013, at 4:53 PM, Stuart Cheshire wrote: > On 4 Jun, 2013, at 19:26, Dan Wing wrote: >=20 >> On Jun 4, 2013, at 4:39 PM, Stuart Cheshire = wrote: >>=20 >>> It looks like we're starting to accumulate a growing list of issues = to document in an addendum to RFC 6887. >>>=20 >>> If operating in the Simple Threat Model (Section 18.1), and the >>> internal port, protocol, and internal address match an existing >>> explicit dynamic mapping, but the mapping nonce does not match, the >>> request MUST be rejected with a NOT_AUTHORIZED error with the >>> lifetime of the error indicating duration of that existing mapping. >>> The PCP server only needs to remember one Mapping Nonce value for >>> each explicit dynamic mapping. >>>=20 >>> Here's the problem: >>>=20 >>> 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive = ssh logins. >>> 2. Client reboots, or similar, and picks new nonce. >>=20 >> Can the client remember its nonce across reboots, or similar? >=20 > RFC 6887 says: >=20 > The client MUST use a different mapping > nonce for each PCP server it communicates with, and it is = RECOMMENDED > to choose a new random mapping nonce whenever the PCP client is > initialized. >=20 > How does the PCP client know for sure when it's talking to a new PCP = server? Practically speaking, it has to err on the side of caution and = pick a new nonce if it *might* be talking to a new PCP server. >=20 > My broader point is this: If the NAT gateway is actually forwarding = inbound traffic to 10.0.0.2:22, how is it useful for it to lie to the = client and claim that it is not? >=20 > i.e.: >=20 > 1. Client says, "Please forward inbound SYNs to me at 10.0.0.2:22." > 2. Server says, "No! NOT_AUTHORIZED!" but then proceeds to forward = inbound SYNs to the client at 10.0.0.2:22 anyway. It could then do (3), which would be retrieving its previous Nonce from = disk, and tries that Nonce value. Yes, that step (3) is worse than the = suggestion in this thread to just allow the server to communicate the = existing mapping lifetime. I support that suggestion; let's aim for = doing that. -d From dwing@cisco.com Fri Jun 7 14:06:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8546D21F99A7 for ; Fri, 7 Jun 2013 14:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL2avqMhmKmI for ; Fri, 7 Jun 2013 14:06:10 -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 08C2A21F999F for ; Fri, 7 Jun 2013 14:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4123; q=dns/txt; s=iport; t=1370639169; x=1371848769; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=K/lVjcf52aSzhPfTq4zSb/RCfNN9YsEyK8IRJ/2fq3Q=; b=IEW2fzuZc+JeRiTzImqo0AlPmz/WneJSPO0KPTkIIrcc5a+0zTgUN/a2 n2pVGBKhu2JYh3jrRp9SZQqL40gBCBEjKH9NMxNDBXy0i0XuNfmllGbIl HmIoZiM/z8xeOPNsDr/ZTHCnn0pbJFTt5QWnEQdSvefs/oE4P7iXKv7TQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAJdKslGrRDoI/2dsb2JhbABZgwkwvnCBARZ0giMBAQEDAQEBAWsLBQsLGCcHJx8RGYgHBQ28VQSOCH0zB4J7YQOJII4ghh+DfYcmgy8cgSwBBBs X-IronPort-AV: E=Sophos;i="4.87,824,1363132800"; d="scan'208";a="79969944" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 07 Jun 2013 21:06:07 +0000 Received: from [10.156.16.238] ([10.156.16.238]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r57L66Fi001456; Fri, 7 Jun 2013 21:06:06 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 7 Jun 2013 14:06:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1503) Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 21:06:17 -0000 On Jun 6, 2013, at 11:47 PM, mohamed.boucadair@orange.com wrote: > Stuart, >=20 > I'm re-iterating below what I'm suggesting: >=20 > * The PCP client can indicate a *** preferred *** AF in the Suggested = External IP Address. > * The PCP client MUST be prepared to receive an address of a distinct = AF than the one indicated in the request. > * The PCP server will try to honor the suggested AF, but it will = always return an address belonging to the AF it supports (modulo port = quota checks).=20 > * It is up to the PCP client to make use of the address returned by = the PCP server or not. > * If the PCP client has no indication about the capabilities of the = server, the PCP client may try two requests each one with a # suggested = AF. >=20 > Instead of returning an error, an offer is made to the client. > This behavior maximizes the chance to get an address and make use of = it. >=20 > I fail to see how this mode will induce failures. Because the PCP client library, or the application calling the PCP = library, will have never exercised its code to handle receiving a = different address family, because it was developed and deployed for = years on an IPv4-only network at the developer's house or developer's = company. As an example, imagine in a decade we introduce a new address = family called IPv8, and imagine failures would occur with a PCP client = library or an application that only understood IPv4 and understood IPv6. -d >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >> Stuart Cheshire >> Envoy=E9 : vendredi 7 juin 2013 01:38 >> =C0 : pcp@ietf.org >> Objet : Re: [pcp] UNSUPP_FAMILY error code >>=20 >> On 5 Jun, 2013, at 02:17, mohamed.boucadair@orange.com wrote: >>=20 >>> Stuart, >>>=20 >>> I'm objecting your proposal because I don't want to add a new = failure >> case to the list we already have. >>>=20 >>> There is a risk that some PCP clients won't try all AFs for the same = PCP >> server and therefore the host won't be able to receive incoming = packets via >> that PCP-controlled device. Consider an IPv6-only client behind a = NAT64. If >> the pcp client asks for IPv6 external address, the server will reject = it >> with the error you are proposing. If the pcp client does not try = another >> AF, the IPv6-only host cannot receive incoming sessions from an = IPv4-only >> host. >>=20 >> If the client writer had thought about IPv6, then the client would = ask for >> an IPv6 external address. If the client does not, chances are the = client >> writer never thought about that, and the code will likely fail (or = even >> crash) when given an IPv6 external address. >>=20 >> If we allow what you want, the PCP adoption road map goes like this: >>=20 >> Early PCP servers only support IPv4. >>=20 >> Early PCP clients only support IPv4. >>=20 >> In fact, some early PCP clients mistakenly pass the IPv6 all zeroes >> address, and the early PCP servers give them back an IPv4 external = address >> anyway, which the client then puts in a DNS IPv4 address record. So = it all >> works, but largely though good luck. >>=20 >> Now, with this ecosystem in place, a vendor wants to introduce a = gateway >> that supports IPv6. Hooray! We all want that. But this gateway = returns an >> IPv6 external address, and a whole bunch of existing clients crash or >> otherwise fail in response to that. Management says the company can't = ship >> a gateway that breaks existing clients. >>=20 >> So the path you propose leads to a dead end where PCP can never add = support >> for IPv6, because of buggy clients that were allowed to exist by = overly- >> lenient early implementations. >>=20 >> Stuart Cheshire >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From cheshire@apple.com Fri Jun 7 15:25:36 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E198621F99A9 for ; Fri, 7 Jun 2013 15:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3KWn2+HIlby for ; Fri, 7 Jun 2013 15:25:30 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7034121F99A6 for ; Fri, 7 Jun 2013 15:25:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO100FP3NLAQFO0@mail-out.apple.com> for pcp@ietf.org; Fri, 07 Jun 2013 15:25:30 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-ea-51b25ddab953 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 48.A3.01734.ADD52B15; Fri, 07 Jun 2013 15:25:30 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MO100IZSNMHUQ50@spicerack.apple.com> for pcp@ietf.org; Fri, 07 Jun 2013 15:25:30 -0700 (PDT) From: Stuart Cheshire In-reply-to: <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 07 Jun 2013 15:25:29 -0700 Message-id: <803BCA1C-FC13-4F5C-873F-E88BB88B6B6F@apple.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FCsoXsrdlOgQc9GbovJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49m9CWwFt7kqfu6YwNLAuJ+ji5GTQ0LAROLLpYdMELaYxIV7 69m6GLk4hAQmM0l8njyPHcJZwSTxY1IzG0gVs4CORO/3b8wgNq+AnsS2udvA4sIC2hJvb99i B7HZBLQkXny+AhbnFIiTWP8SooZFQFWiuXsF1BxtiSfvLrBCzLGR+Lv7C9SyY0wSy+YeYgRJ iAgoShzYdoMd4jxZidfP37BMYOSfheSOWUjumIVk7gJG5lWMAkWpOYmVJnqJBQU5qXrJ+bmb GMFBVhi+g/HfMqtDjAIcjEo8vDtMNgUKsSaWFVfmHmKU4GBWEuFt3LQxUIg3JbGyKrUoP76o NCe1+BCjNAeLkjivxWyglEB6YklqdmpqQWoRTJaJg1OqgXGuR9IU5somnQVbNE/MMTmoIMWq k7K6V0k+U+sx82o9Wf7z9loeNcsi/0asXyCtqOQatJMrvjtvzvnanT7/BZR/TfPwc9NLC5hi 9fSQYF22gVjO1TpXzbbM1YuUDzZ+ObRFK/TCrPmP179xkJF+8+yizM70S6duGnLflCzkm3P9 +hUhfX/W+0osxRmJhlrMRcWJAMsBc1IuAgAA Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 22:25:37 -0000 On 6 Jun, 2013, at 23:47, mohamed.boucadair@orange.com wrote: > Stuart, > > I'm re-iterating below what I'm suggesting: > > * The PCP client can indicate a *** preferred *** AF in the Suggested External IP Address. > * The PCP client MUST be prepared to receive an address of a distinct AF than the one indicated in the request. You can say MUST MUST MUST as much as you like, but that doesn't change reality. There will be buggy clients that don't handle this right, unless we prevent that by making the bug so obvious that they realise they can't ship before fixing it. I have seen PCP clients that pass all-zeroes IPv6 as the suggested external address, but only handle IPv4 replies. They do this because the PCP server they tested with ignores the suggested external address completely, and always returns an IPv4 external address. Suppose that PCP client goes into a very widely deployed game console. Now, as a gateway vendor, you can *never* return an IPv6 external address, because if you do, the game console breaks, and customers will return your product for a refund and you go out of business. To stop this outcome we need to make the buggy PCP client not work *now*, before it gets widely shipped. Protocols ossify fast unless good design decisions are made early on. Stuart Cheshire From repenno@cisco.com Sat Jun 8 08:09:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BC521F94BA for ; Sat, 8 Jun 2013 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loxFDJx6Pahh for ; Sat, 8 Jun 2013 08:09:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A002A21F93BA for ; Sat, 8 Jun 2013 08:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3341; q=dns/txt; s=iport; t=1370704176; x=1371913776; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iPtz8dMuaPpIDGXon4LDyR0me82rgj/5gguzI2UBz90=; b=jgMm7zPCmSIG+ZAc6K+VC8Vu0N5B7KD5lBR1dtQ5PkbMr5zF86BJEkJS vOWeMKthy70EV7aLxNFhR9jR7AQVLFfnkOtpsE87pulf3EoO7x1hoJCDl 7yW98Fct1CLvMWynGiLwaEH356BV+dDKyJK8w9l0JH86inpGKIV/DvSPi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAK5Is1GtJV2Y/2dsb2JhbABagwkwQwa+PXkWdIIjAQEBBAEBASRHCxIBCBgKHS4LFBECBAENBQgBh3IDDwcFsyMIiFePBzECBYJ/YQOIaJABiniFIYMPgic X-IronPort-AV: E=Sophos;i="4.87,827,1363132800"; d="scan'208";a="220431833" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jun 2013 15:09:36 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r58F9amt022015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Jun 2013 15:09:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sat, 8 Jun 2013 10:09:35 -0500 From: "Reinaldo Penno (repenno)" To: Norman Sardella , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt Thread-Index: AQHOY67NkA/yR9t130u/0DZr0tFYL5ksDoaA Date: Sat, 8 Jun 2013 15:09:34 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A2DC3@xmb-rcd-x04.cisco.com> In-Reply-To: <51B22995.6000609@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.211] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:09:44 -0000 On 6/7/13 3:42 PM, "Norman Sardella" wrote: >Mohamed > >I have a question in your examples in section 2.12, >about returning remaining idle-timeout on MAP delete response > > |--------------------------------->| > > | PCP MAP Response (Lifetime=3D | > > | remaining idle-timeout) | > >Some LSN implementations are incapable of returning the remaining >lifetime because each flow creates a separate NAT translation >based of the PCP master created NAT entry. >In this case, which of the other NAT entries would we pick to return an >idle-timeout? How does your implementation work? Does the mater entry have a timer of its own or packets hitting the derived sessions refresh the main entry? Does each derived entry have a timer of its own? > >How are PCP clients expected to use the lifetime in delete mappings >responses? >Should a PCP server return 0, return idle-timeout value, or the age >remaining when the PCP master NAT entry was created? See above. This is implementation specific and to help answer this questions we need to understand how your implementation work. > >Thanks >Norman Sardella > > >On 05/30/2013 05:36 AM, mohamed.boucadair@orange.com wrote: >> Dear all, >> >> This updated version includes two additional use case suggested by Dan. >> >> Don't hesitate to share any use case you think it is worth to be >>documented this I-D. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] De la part de >>internet-drafts@ietf.org >> Envoy=E9 : jeudi 30 mai 2013 11:27 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-boucadair-pcp-flow-examples-01.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : PCP Flow Examples >> Author(s) : Mohamed Boucadair >> Filename : draft-boucadair-pcp-flow-examples-01.txt >> Pages : 32 >> Date : 2013-05-30 >> >> Abstract: >> This document provides a set of examples to illustrate PCP >> operations. It is a companion document to the base PCP >> specification. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-flow-examples-01 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Sat Jun 8 08:18:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF821F9643 for ; Sat, 8 Jun 2013 08:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdMqhpcvac7e for ; Sat, 8 Jun 2013 08:18:40 -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 086AE21F9638 for ; Sat, 8 Jun 2013 08:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10125; q=dns/txt; s=iport; t=1370704720; x=1371914320; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Wxu1e3Wr6dkbYUa3rVoSJbr5kGm3Vp7WMbhpnYUTSc4=; b=OQX0RF5lnf2zFbYdeV/njLCvvb7n+VeQDiD8pUkBUqMWKmykL5iWX91C tCS9xVmpFlv9iLcGkXvsJ5o+wDJA2yj4tnpqdEsv2hLEpscKd6omAaVpw yMk/23yJzFxifBMxkAlhLk/yHVuE9bGCKvWVgwSj7QpYjgvX+jDiwtCsy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFANtJs1GtJXG8/2dsb2JhbABagkVEMEm+PXkWdIIjAQEBBAEBAWsdAQgRAwECCx0oBgsUCQgCBAESCIdzAw8MsyANiE4EjFuCLCANCgGCf2EDlVmOBYUkgViBN4In X-IronPort-AV: E=Sophos;i="4.87,827,1363132800"; d="scan'208,217";a="220419374" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jun 2013 15:18:39 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r58FIdIj026508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Jun 2013 15:18:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sat, 8 Jun 2013 10:18:38 -0500 From: "Reinaldo Penno (repenno)" To: Ben McCann , "pcp@ietf.org" Thread-Topic: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt Thread-Index: AQHOZFtzc4EWKm8q7Ueks511ALciTA== Date: Sat, 8 Jun 2013 15:18:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A2DDB@xmb-rcd-x04.cisco.com> In-Reply-To: <51B22BA4.1050007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.211] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090A2DDBxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 15:18:53 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A2DDBxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, I believe this is covered in section 11.3 (Processing a MAP Request) It is possible that a mapping might already exist for a requested internal address, protocol, and port. If so, the PCP server takes the following actions: ... 4. If the existing mapping is dynamic outbound (created by outgoing traffic or a previous PEER request), the PCP server SHOULD create a new explicit inbound mapping, replicating the ports and addresses from the outbound mapping (but the outbound mapping continues to exist, and remains in effect if the explicit inbound mapping is later deleted). And if this mapping was created due to a port forwarding rule (static mappi= ng) then 2. If the existing mapping is static (created outside of PCP), the PCP server MUST return the external address and port of the existing mapping in its response and SHOULD indicate a lifetime of 2^32-1 seconds, regardless of the suggested external address and port in the request. From: Ben McCann > Date: Fri, 7 Jun 2013 14:51:16 -0400 To: > Subject: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-ex= amples-01.txt Section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrates how a clie= nt can learn the external IP address of and port of an existing implicit ma= pping by using the MAP opcode. I can't find any reference to that capability in RFC 6887 but I do see a re= ference in Section 12.2 (Generating a Peer Request) that discusses how a cl= ient can use the PEER opcode to learn the external address and port of an e= xisting implicit mapping. Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate u= se of the PEER opcode? Thanks, Ben McCann _______________________________________________ pcp mailing list pcp@ietf.o= rg https://www.ietf.org/mailman/listinfo/pcp --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A2DDBxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3973059C4DB31844826318E4D1820BC6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Ben,

I believe this is covered in section 11.3 (Processing a MAP Request) 

   It is possible that a mapping mi=
ght already exist for a requested
   internal address, protocol, and port.  If so, the PCP server takes
   the following actions:

...

   4.  If the existing mapping is dynamic outbound (created by outgoin=
g
       traffic or a previous PEER request), the PCP server SHOULD create
       a new explicit inbound mapping, replicating the ports and
       addresses from the outbound mapping (but the outbound mapping
       continues to exist, and remains in effect if the explicit inbound
       mapping is later deleted).

And if this mapping w=
as created due to a port forwarding rule (static mapping) then

   2.  If the existing mapp=
ing is static (created outside of PCP), the
       PCP server MUST return the external address and port of the
       existing mapping in its response and SHOULD indicate a lifetime
       of 2^32-1 seconds, regardless of the suggested external address
       and port in the request.

From: Ben McCann <bn.mccann@gmail.com>
Date: Fri, 7 Jun 2013 14:51:16 -040= 0
To: <pcp@ietf.org>
Subject: [pcp] Clarification of Sec= tion 2.11 of draft-boucadair-pcp-flow-examples-01.txt

Section 2.11 of draft-boucadair-p= cp-flow-examples-01 illustrates how a client can learn the external IP addr= ess of and port of an existing implicit mapping by using the MAP opcode.

I can't find any reference to that capability in RFC 6887 but I do see a re= ference in Section 12.2 (Generating a Peer Request) that discusses how a cl= ient can use the PEER opcode to learn the external address and port of an existing im= plicit mapping.

Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate u= se of the PEER opcode?

Thanks,
Ben McCann

_______________________________________________ pcp mailing list pcp@ietf.org http= s://www.ietf.org/mailman/listinfo/pcp --_000_45A697A8FFD7CF48BCF2BE7E106F0604090A2DDBxmbrcdx04ciscoc_-- From sardella@comcast.net Sat Jun 8 17:07:41 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09821F8756 for ; Sat, 8 Jun 2013 17:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inw-4cZIWxLj for ; Sat, 8 Jun 2013 17:07:36 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9821F87E1 for ; Sat, 8 Jun 2013 17:07:36 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id lyd41l0031HzFnQ5407bPP; Sun, 09 Jun 2013 00:07:35 +0000 Received: from sardella.org ([66.31.217.148]) by omta14.westchester.pa.mail.comcast.net with comcast id m07a1l00L3ChNai3a07b2W; Sun, 09 Jun 2013 00:07:35 +0000 Received: from [172.17.150.5] ([172.17.150.5]) (authenticated bits=0) by sardella.org (8.13.1/8.13.1) with ESMTP id r5907XIx005671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jun 2013 20:07:33 -0400 Message-ID: <51B3C743.9070401@comcast.net> Date: Sat, 08 Jun 2013 20:07:31 -0400 From: Norman Sardella User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F0604090A2DC3@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A2DC3@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370736455; bh=mXE2SR8VzUdZXRoOgCrkPOREFgIhFlmMVwWHk4QjdZA=; h=Received:Received:Received:Message-ID:Date:From:MIME-Version:To: Subject:Content-Type; b=SNo+XjEbAigdlJfieGAoRQJDbe0UNUVnrQGA0mj1+K7EU1n70YHwJZkjsa4xXsvUQ o6euLoe9EWKYxcEOleS+h7quY7OtPEY4w1p8zjV0SZOaF6m+lKcC9/vqi69K6WSuj/ wRuJibjuchfgpkfJLZ9140UW9NBUMtRaKN7LKKyrWOaAm9bNKwBvz4mX1IWRaQ+gFO zuCfEvGuZ9ykafC+63l+IMl37Wvh2TWkbgIyhit4UgS2YLLILqWgl5uRWTz25sMoJr PmeLqNuT3saZuvkEgjS+rgMYezUQFckVnE6W8z7ipbY6S+UP2weXZ9QYKEdMOGON0v ilnp5EsT/RWpA== Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 00:07:41 -0000 Hi Reinaldo , see comments below On 6/8/2013 11:09 AM, Reinaldo Penno (repenno) wrote: > > > On 6/7/13 3:42 PM, "Norman Sardella" wrote: > >> Mohamed >> >> I have a question in your examples in section 2.12, >> about returning remaining idle-timeout on MAP delete response >>> |--------------------------------->| >>> | PCP MAP Response (Lifetime= | >>> | remaining idle-timeout) | >> >> Some LSN implementations are incapable of returning the remaining >> lifetime because each flow creates a separate NAT translation >> based of the PCP master created NAT entry. >> In this case, which of the other NAT entries would we pick to return an >> idle-timeout? > > > How does your implementation work? Does the mater entry have a timer of > its own or packets hitting the derived sessions refresh the main entry? Each flow(connection) to external address/port has its own NAT entry with its own timer. The master from the PCP map openrs anan external address/port to an internal host and has its own timer. > > Does each derived entry have a timer of its own? Each derived entry has its own timer. > > >> >> How are PCP clients expected to use the lifetime in delete mappings >> responses? >> Should a PCP server return 0, return idle-timeout value, or the age >> remaining when the PCP master NAT entry was created? > > See above. This is implementation specific and to help answer this > questions we need to understand how your implementation work. > >> >> Thanks >> Norman Sardella >> >> >> On 05/30/2013 05:36 AM, mohamed.boucadair@orange.com wrote: >>> Dear all, >>> >>> This updated version includes two additional use case suggested by Dan. >>> >>> Don't hesitate to share any use case you think it is worth to be >>> documented this I-D. >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] De la part de >>> internet-drafts@ietf.org >>> Envoyé : jeudi 30 mai 2013 11:27 >>> À : i-d-announce@ietf.org >>> Objet : I-D Action: draft-boucadair-pcp-flow-examples-01.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : PCP Flow Examples >>> Author(s) : Mohamed Boucadair >>> Filename : draft-boucadair-pcp-flow-examples-01.txt >>> Pages : 32 >>> Date : 2013-05-30 >>> >>> Abstract: >>> This document provides a set of examples to illustrate PCP >>> operations. It is a companion document to the base PCP >>> specification. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-flow-examples-01 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > From mohamed.boucadair@orange.com Sun Jun 9 23:32:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6221F8F61 for ; Sun, 9 Jun 2013 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abBke83zQYeE for ; Sun, 9 Jun 2013 23:31:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CAD0C21F8E79 for ; Sun, 9 Jun 2013 23:31:58 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 61C953B454B; Mon, 10 Jun 2013 08:31:57 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4114735C089; Mon, 10 Jun 2013 08:31:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 10 Jun 2013 08:31:57 +0200 From: To: Dan Wing Date: Mon, 10 Jun 2013 08:31:54 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5jwte3ZRTadhKjR5mUly6/ehLHfAB4EOmQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> In-Reply-To: <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.9.140333 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 06:32:03 -0000 Hi Dan, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Dan Wing [mailto:dwing@cisco.com] >Envoy=E9=A0: vendredi 7 juin 2013 23:06 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Stuart Cheshire; pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > > >On Jun 6, 2013, at 11:47 PM, mohamed.boucadair@orange.com wrote: > >> Stuart, >> >> I'm re-iterating below what I'm suggesting: >> >> * The PCP client can indicate a *** preferred *** AF in the Suggested >External IP Address. >> * The PCP client MUST be prepared to receive an address of a distinct AF >than the one indicated in the request. >> * The PCP server will try to honor the suggested AF, but it will always >return an address belonging to the AF it supports (modulo port quota >checks). >> * It is up to the PCP client to make use of the address returned by the >PCP server or not. >> * If the PCP client has no indication about the capabilities of the >server, the PCP client may try two requests each one with a # suggested AF= . >> >> Instead of returning an error, an offer is made to the client. >> This behavior maximizes the chance to get an address and make use of it. >> >> I fail to see how this mode will induce failures. > >Because the PCP client library, or the application calling the PCP library= , >will have never exercised its code to handle receiving a different address >family, because it was developed and deployed for years on an IPv4-only >network at the developer's house or developer's company. [Med] If an implementation does not follow the spec, then yes failures can = be experienced. With the error code, things may be worse: a client may ask = for a AF but the server returns an error. If the client doesn't ask for ano= ther AF, it will never get an external IP address. Not servicing the reques= t and returning an error opens a new communication failure window. We alrea= dy have many in PCP, IMO we should not add a new one. We should encourage i= mplementations to be prepared to receive any AF from the server, not the on= e indicated in the Suggested External IP Address.=20 As an example, >imagine in a decade we introduce a new address family called IPv8,=20 [Med] IPv8 is already assigned since 1994. No need to wait for another daca= de ;-) and >imagine failures would occur with a PCP client library or an application >that only understood IPv4 and understood IPv6. > >-d > > >> >> Cheers, >> Med >> >> >>> -----Message d'origine----- >>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >>> Stuart Cheshire >>> Envoy=E9 : vendredi 7 juin 2013 01:38 >>> =C0 : pcp@ietf.org >>> Objet : Re: [pcp] UNSUPP_FAMILY error code >>> >>> On 5 Jun, 2013, at 02:17, mohamed.boucadair@orange.com wrote: >>> >>>> Stuart, >>>> >>>> I'm objecting your proposal because I don't want to add a new failure >>> case to the list we already have. >>>> >>>> There is a risk that some PCP clients won't try all AFs for the same >PCP >>> server and therefore the host won't be able to receive incoming packets >via >>> that PCP-controlled device. Consider an IPv6-only client behind a NAT64= . >If >>> the pcp client asks for IPv6 external address, the server will reject i= t >>> with the error you are proposing. If the pcp client does not try anothe= r >>> AF, the IPv6-only host cannot receive incoming sessions from an IPv4- >only >>> host. >>> >>> If the client writer had thought about IPv6, then the client would ask >for >>> an IPv6 external address. If the client does not, chances are the clien= t >>> writer never thought about that, and the code will likely fail (or even >>> crash) when given an IPv6 external address. >>> >>> If we allow what you want, the PCP adoption road map goes like this: >>> >>> Early PCP servers only support IPv4. >>> >>> Early PCP clients only support IPv4. >>> >>> In fact, some early PCP clients mistakenly pass the IPv6 all zeroes >>> address, and the early PCP servers give them back an IPv4 external >address >>> anyway, which the client then puts in a DNS IPv4 address record. So it >all >>> works, but largely though good luck. >>> >>> Now, with this ecosystem in place, a vendor wants to introduce a gatewa= y >>> that supports IPv6. Hooray! We all want that. But this gateway returns >an >>> IPv6 external address, and a whole bunch of existing clients crash or >>> otherwise fail in response to that. Management says the company can't >ship >>> a gateway that breaks existing clients. >>> >>> So the path you propose leads to a dead end where PCP can never add >support >>> for IPv6, because of buggy clients that were allowed to exist by overly= - >>> lenient early implementations. >>> >>> Stuart Cheshire >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Sun Jun 9 23:41:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE8D21F901F for ; Sun, 9 Jun 2013 23:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4siveGK16pmi for ; Sun, 9 Jun 2013 23:41:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 56B1C21F90EF for ; Sun, 9 Jun 2013 23:41:06 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 63ADF22CB66; Mon, 10 Jun 2013 08:41:00 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 44AD54C076; Mon, 10 Jun 2013 08:41:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 10 Jun 2013 08:41:00 +0200 From: To: "Reinaldo Penno (repenno)" , Ben McCann , "pcp@ietf.org" Date: Mon, 10 Jun 2013 08:40:57 +0200 Thread-Topic: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt Thread-Index: AQHOZFtzc4EWKm8q7Ueks511ALciTJkugSvQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED22C@PUEXCB1B.nanterre.francetelecom.fr> References: <51B22BA4.1050007@gmail.com> <45A697A8FFD7CF48BCF2BE7E106F0604090A2DDB@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090A2DDB@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ED58ED22CPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.10.55423 Subject: Re: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 06:41:11 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ED58ED22CPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, Reinaldo, I added an explicit pointer to the section quoted by Reinaldo in Section 2.= 11 of draft-boucadair-pcp-flow-examples. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Reina= ldo Penno (repenno) Envoy=E9 : samedi 8 juin 2013 17:19 =C0 : Ben McCann; pcp@ietf.org Objet : Re: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow= -examples-01.txt Hi Ben, I believe this is covered in section 11.3 (Processing a MAP Request) It is possible that a mapping might already exist for a requested internal address, protocol, and port. If so, the PCP server takes the following actions: ... 4. If the existing mapping is dynamic outbound (created by outgoing traffic or a previous PEER request), the PCP server SHOULD create a new explicit inbound mapping, replicating the ports and addresses from the outbound mapping (but the outbound mapping continues to exist, and remains in effect if the explicit inbound mapping is later deleted). And if this mapping was created due to a port forwarding rule (static mappi= ng) then 2. If the existing mapping is static (created outside of PCP), the PCP server MUST return the external address and port of the existing mapping in its response and SHOULD indicate a lifetime of 2^32-1 seconds, regardless of the suggested external address and port in the request. From: Ben McCann > Date: Fri, 7 Jun 2013 14:51:16 -0400 To: > Subject: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-ex= amples-01.txt Section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrates how a clie= nt can learn the external IP address of and port of an existing implicit ma= pping by using the MAP opcode. I can't find any reference to that capability in RFC 6887 but I do see a re= ference in Section 12.2 (Generating a Peer Request) that discusses how a cl= ient can use the PEER opcode to learn the external address and port of an e= xisting implicit mapping. Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate u= se of the PEER opcode? Thanks, Ben McCann _______________________________________________ pcp mailing list pcp@ietf.o= rg https://www.ietf.org/mailman/listinfo/pcp --_000_94C682931C08B048B7A8645303FDC9F36ED58ED22CPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ben,= Reinaldo,

 =

I added an explicit pointe= r to the section quoted by Reinaldo in Section 2.11 of draft-boucadair-pcp-= flow-examples.

&n= bsp;

Cheers,

Med

 

 

De&n= bsp;: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part d= e Reinaldo Penno (repenno)
Envoy=E9 : samedi 8 juin 2013= 17:19
=C0 : Ben McCann; pcp@ietf.org
Objet := Re: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-exampl= es-01.txt

 =

Hi Ben,

 

I believe this is covered in section 11.3 (Processing= a MAP Request)

<= o:p> 

=A0=A0 It is possible that a mapping might already ex=
ist for a requested
=A0=A0 internal addres=
s, protocol, and port.=A0 If so, the PCP server takes
=A0=A0 the following actions:

...

 

= 
=A0=A0 4.=
=A0 If the existing mapping is dynamic outbound (created by outgoing
=A0=A0=A0=A0=A0=A0 traffic or a previous PEER re=
quest), the PCP server SHOULD create
=A0=
=A0=A0=A0=A0=A0 a new explicit inbound mapping, replicating the ports and
=A0=A0=A0=A0=A0=A0 addresses from the out=
bound mapping (but the outbound mapping
=
=A0=A0=A0=A0=A0=A0 continues to exist, and remains in effect if the explici=
t inbound
=A0=A0=A0=A0=A0=A0 mapping is la=
ter deleted).

And if this mapping was created due to a port forwa=
rding rule (static mapping) then

=A0=A0 2.=A0 If the existing map=
ping is static (created outside of PCP), the
=A0=A0=A0=A0=A0=A0 PCP server MUST return the external address and port =
of the
=A0=A0=A0=A0=A0=A0 existing mapping=
 in its response and SHOULD indicate a lifetime
=A0=A0=A0=A0=A0=A0 of 2^32-1 seconds, regardless of the suggested ext= ernal address
=A0=A0=A0=A0=A0=A0 and port =
in the request.

 

Fr= om: Ben McCann <b= n.mccann@gmail.com>
Date: Fri, 7 Jun 2013 14:51:16 -0400To: <pcp@ietf.org>
Subject: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-fl= ow-examples-01.txt

 

Section 2.11 of draft-boucadair-pcp-flow-exampl= es-01 illustrates how a client can learn the external IP address of and por= t of an existing implicit mapping by using the MAP opcode.
I can't find any reference to that capability in RFC 6887 but I do see= a reference in Section 12.2 (Generating a Peer Request) that discusses how= a client can use the PEER opcode to learn the external address and = port of an existing implicit mapping.

Shouldn't section 2.11 of draf= t-boucadair-pcp-flow-examples-01 illustrate use of the PEER opcode?<= br>
Thanks,
Ben McCann

_______________________________________________ pcp mailing li= st pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp

= --_000_94C682931C08B048B7A8645303FDC9F36ED58ED22CPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Sun Jun 9 23:52:28 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7121F84E7 for ; Sun, 9 Jun 2013 23:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BRszysAadmb for ; Sun, 9 Jun 2013 23:52:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4385521F905F for ; Sun, 9 Jun 2013 23:52:16 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 52BD52DC37A; Mon, 10 Jun 2013 08:52:15 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3696735C088; Mon, 10 Jun 2013 08:52:15 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 10 Jun 2013 08:52:15 +0200 From: To: Ben McCann , "pcp@ietf.org" Date: Mon, 10 Jun 2013 08:52:13 +0200 Thread-Topic: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt Thread-Index: Ac5jsBp6v9KzbF6GR4S0clddsmydwwB9paXw Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED23A@PUEXCB1B.nanterre.francetelecom.fr> References: <51B22BA4.1050007@gmail.com> In-Reply-To: <51B22BA4.1050007@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ED58ED23APUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 06:52:28 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ED58ED23APUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, In addition to the answer provided by Reinaldo, you may have noticed the PE= ER use case you are referring to is described in http://tools.ietf.org/html= /draft-boucadair-pcp-flow-examples-01#section-8.4 Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Ben M= cCann Envoy=E9 : vendredi 7 juin 2013 20:51 =C0 : pcp@ietf.org Objet : [pcp] Clarification of Section 2.11 of draft-boucadair-pcp-flow-exa= mples-01.txt Section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrates how a clie= nt can learn the external IP address of and port of an existing implicit ma= pping by using the MAP opcode. I can't find any reference to that capability in RFC 6887 but I do see a re= ference in Section 12.2 (Generating a Peer Request) that discusses how a cl= ient can use the PEER opcode to learn the external address and port of an e= xisting implicit mapping. Shouldn't section 2.11 of draft-boucadair-pcp-flow-examples-01 illustrate u= se of the PEER opcode? Thanks, Ben McCann --_000_94C682931C08B048B7A8645303FDC9F36ED58ED23APUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Be= n,

 

In addition to the answer provided by Reinaldo,= you may have noticed the PEER use case you are referring to is described i= n http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples= -01#section-8.4

 

Cheers,<= /o:p>

Med

 

De : pcp-boun= ces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Ben McCann<= br>Envoy=E9 : vendredi 7 juin 2013 20:51
=C0 : p= cp@ietf.org
Objet : [pcp] Clarification of Section 2.11 of d= raft-boucadair-pcp-flow-examples-01.txt

 

Section 2.11 of draft-boucadair-pcp-flow-examples-01 illus= trates how a client can learn the external IP address of and port of an = existing implicit mapping by using the MAP opcode.

I can'= t find any reference to that capability in RFC 6887 but I do see a referenc= e in Section 12.2 (Generating a Peer Request) that discusses how a client c= an use the PEER opcode to learn the external address and port of an = existing implicit mapping.

Shouldn't section 2.11 of draft-boucadair= -pcp-flow-examples-01 illustrate use of the PEER opcode?

Than= ks,
Ben McCann

= --_000_94C682931C08B048B7A8645303FDC9F36ED58ED23APUEXCB1Bnante_-- From tireddy@cisco.com Mon Jun 10 08:38:12 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9921F962A for ; Mon, 10 Jun 2013 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kF5MSlYjrWR for ; Mon, 10 Jun 2013 08:38:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1A821F960D for ; Mon, 10 Jun 2013 08:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105094; q=dns/txt; s=iport; t=1370878684; x=1372088284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fwy17A3MReh/IaJ+dqw5blQiedJ1hVR39KLY1nx3mX8=; b=iC/pxbN96lMNjg+4x6LFIkP1vSZsBurtz/J6D7ewmGEGmFJ9Au4e9b+G RwMNwwI4QQRK5hLlYnCIXD2DOG26NBMg02MlOr9K6B/SXSpL4YMAiCCQd U1dwxaFCpugGO8xmQeVfIj3hGN4w+g6V/b5I8SY9kcu3Kz6dZ4AMaNZtF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFADjytVGtJV2d/2dsb2JhbABXA4JFRDBJtXmISoEFFnSCIwEBAQQtPwoDEAIBCBEEAQELDggBBgcyFAkIAgQOBQgTh3IMuUuPBzEGAQYLBgGCZ2EDhT6TK5AZgw+BaiQZ X-IronPort-AV: E=Sophos;i="4.87,837,1363132800"; d="scan'208,217";a="220958869" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2013 15:37:47 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5AFbliX021506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 15:37:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 10:37:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORaVDKQ3d6G8P5kumseyWFL/c3ZkK012AgATaxwCAAZScgIAADysAgADZvgCAABdfgIAAiEiAgAKXlICABd80AIAAfEGAgADlvyCAARz4gIAJgniw Date: Mon, 10 Jun 2013 15:37:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B80D06@xmb-rcd-x10.cisco.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75E78@xmb-rcd-x10.cisco.com> <9E1F86C3-0925-4617-8998-E74A5A470B00@yegin.org> In-Reply-To: <9E1F86C3-0925-4617-8998-E74A5A470B00@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.155] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B80D06xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 15:38:12 -0000 --_000_913383AAA69FF945B8F946018B75898A14B80D06xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The other requirement that was updated as part of the discussion during the= PCP interim meeting is REQ-14, would like to know if there any comments fo= r this req. 5. Other= recommendations REQ-14: There SHOULD be support for a means to provide integrity protection without user authentication, i.e., integrity protection for PCP messages exchanged between a PCP server and anonymous PCP clients. For example, a client visiting foreign networks such as a hotel, hot spot etc where the client may gain access to the network but does not know the credentials to authenticate with the PCP server. a. An SA MUST be made available to the client and server, which will be used for integrity protection of PCP messages. The negotiation of SA should be secure such that the SA is only known to the anonymous client and PCP server. b. A PCP client MUST be able to validate that it is communicating with the designated PCP server and not an attacker posing as a PCP server. --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 30, 2013 11:40 AM To: Tirumaleswar Reddy (tireddy) Cc: yoshihiro.ohba@toshiba.co.jp; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements This text makes sense. On May 29, 2013, at 4:09 PM, Tirumaleswar Reddy (tireddy) wrote: Thanks Yoshi for the text : OLD : REQ-4- d. If the server wants to send an unsolicited message, but the previous security association for the mapping identified in the original PCP request has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server MUST be able to optionally trigger re- authentication with the client. NEW : REQ-4- d. The server MUST be able to trigger authentication with the client.= The unsolicited message for authentication trigger MUST be integrity prote= cted if there is valid unexpired SA. --Tiru. From: yoshihiro.ohba@toshiba.co.jp [ma= ilto:yoshihiro.ohba@toshiba.co.jp] Sent: Wednesday, May 29, 2013 4:57 AM To: alper.yegin@yegin.org; Tirumaleswar Reddy= (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements OK. Then I suggest forming a requirement without using the term "re-authen= tication", something like: The server MUST be able to send authentication trigger to the client when t= here is a mapping. The authentication trigger MUST be integrity protected = if there is a SA. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 29, 2013 1:03 AM To: Tirumaleswar Reddy Cc: ohba yoshihiro; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Tiru, I agree. Alper On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Alper, [1] when the PCP server triggers re-authentication and SA is valid, if the = PCP client does not respond then possibly after N number of re-tries PCP se= rver may want to give up and close the explicit mappings associated with th= e user. This would handle the scenario where PCP client would have crashed = or terminated or connection lost for some reason or the user has logged off= and some other user got the same IP address as the previous user. [2] Even in case 3, we may want similar behavior as [1]. For Case 3, there = could be a scenarios - where PCP server would want to inform the PCP client= that external IP address/port has changed, but the SA is expired. In this = case PCP server would have to trigger re-auth. If re-auth is successful the= n send the mapping update or if there is no response from the client then p= roceed with deleting the explicit mappings after N number of tries. Case 3 could be an optimization to trigger re-authentication only when ther= e is interesting update to be sent from the client or server and not to tri= gger re-authentication before SA expires . --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 12:17 PM To: yoshihiro.ohba@toshiba.co.jp Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Yoshi, You are right. In terms of EAP and RFC 5247, only the second case qualifies= for "EAP re-authentication". On the other hand, first and third case are not the same. And I'd conceptually think of the third case as a some sort of "re-authenti= cation" (apparently not an "EAP re-authentication" per RFC 5247). Anyways, at least I'd like people to be aware of these three different case= s -- even if we cannot find a proper name to all of them. Alper On May 23, 2013, at 1:39 AM, > wrote: Hi Alper, When we talk about re-authentication, we should not care about whether ther= e is a PCP session or not. Please see the following definition in RFC 5247: " EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material. " According to the above definition, if authentication is conducted over a li= ve SA, it is re-authentication, otherwise it is not re-authentication. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 6:16 AM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Yoshi, Here are the three states: 0. Before PCP client and PCP server has initiated PCP session. 1. There is a PCP session and a live SA. 2. There is a PCP session, but no live SA (i.e., the last used SA is alread= y expired). If we execute auth in state 0, we call it "(initial) authentication". Auth executed in state 1 is called "re-authenticaiton". I'd call auth executed in state 2 a "re-authentication" as well, unless we = want to give it a more specific name. Alper On May 22, 2013, at 11:16 AM, > wrote: Hi Alper, I agree that we should allow unprotected authentication trigger from the se= rver, but we should distinguish authentication after expiration of SA from = "re-authentication". Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 22, 2013 4:22 PM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements On May 21, 2013, at 10:14 AM, > > wrote: Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: "The server MUST be able to send an integrity protected re-authenticati= on trigger to the client." If there is no SA available, then the server can send an un-protected re-au= th trigger. We should allow that. This is equivalent to what happens at the very beginning before the very fi= rst authentication between the client and the server. Alper Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_913383AAA69FF945B8F946018B75898A14B80D06xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The other requirement that was updated as part of the discus= sion during the PCP interim meeting is REQ-14, would like to know if there = any comments for this req.

5.&n= bsp; Other recommendations

  =     REQ-14: There SHOULD be support for a means to provide i= ntegrity

  =     protection without user authentication, i.e., integrity = protection

  =     for PCP messages exchanged between a PCP server and anon= ymous PCP

  =     clients.  For example, a client visiting foreign ne= tworks such as

  =     a hotel, hot spot etc where the client may gain access t= o the

  =     network but does not know the credentials to authenticat= e with the

  =     PCP server.

 <= /o:p>

  =     a.  An SA MUST be made available to the client and = server, which

  =         will be used for integrity prote= ction of PCP messages.  The

  =         negotiation of SA should be secu= re such that the SA is only

  =         known to the anonymous client an= d PCP server.

 <= /o:p>

  =     b.  A PCP client MUST be able to validate that it i= s communicating

  =         with the designated PCP server a= nd not an attacker posing as a

  =         PCP server.

 <= /o:p>

--Tiru.

 

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

 

This text makes sense.

 

 

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



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

 

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

 

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

 

Yoshihiro Ohba

 

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

 

Tiru,

 

I agree.

 

Alper

 

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

 

Hi Alper,

 

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

 

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

 

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

 

--Tiru.

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Thursday, Ma= y 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar R= eddy (tireddy); pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Yoshi,

 

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

 

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

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

 

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

 

Alper

 

 

 

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

<= br>

<= o:p>

Hi Alper,

 

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

 

Please see the following definition in RFC 5247:

“

   EAP Re-Authentication

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

      EAP peer shares valid unexpir= ed EAP keying material.

“

 

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

 

Yoshihiro Ohba

 

 

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

 

Hi Yoshi,

 

Here are the three states:

 

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

 

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

 

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

 

 

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

Auth executed in state 1 is called "re-authentic= aiton".

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

 

Alper

 

 

 

 

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

<= br>


<= o:p>

Hi Alper,

 

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

 

Yoshihiro Ohba

 

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

 

 

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

<= br>



<= o:p>

Tiru,

 

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

 

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

 

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

 

 

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

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

 

Alper

 

 

 

<= br>



<= o:p>

Regards,

Yoshihiro Ohba

 

 

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

 

Hi Alper,

 

Please see inline [TR]

 

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

 



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

          =
previous security association has expired
 
   &nbs=
p;      1.  The server can continue to use th=
e same SA to protect
         &=
nbsp;    messages pertaining to that mapping, even if the SA=
 is<=
/span>
         &=
nbsp;    technically expired.

 
"Expire=
d" means "do not use (even if its still hanging around)".&nb=
sp;<=
/span>
We not only =
do not need to use expired SAs, but also using something expired in any sen=
se is plain wrong -- unless someone wants to redefine what "expired&qu=
ot; means.=

 
[TR]
For example if we consider MSCHAPv2, there is configura=
tion option where server accepts the challenge-response from the client eve=
n if the password is expired and allows it be changed. 
 
Please clarify if you =
have some attack in mind that would cause problems using expired SA.=


 


[/TR]


 


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



         &=
nbsp;       PCP client.


 


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


         &=
nbsp;       re-authenticate.  





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





And as for s=
uch a solution:=






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


 


[TR] 


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


[/TR]


 


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







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


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


         &=
nbsp;       client can then re-authenticate w=
ith the server to


         &=
nbsp;       confirm if the external IP addres=
s/port for the mapping


         &=
nbsp;       has indeed changed.


 


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


         &=
nbsp;    the client.














 


























 


























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






















 












[TR]


&nbs=
p;


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



 


Best Regards,


--Tiru.


 


[/TR]












 


























 


























Alper


























 


























 


























 

 

--_000_913383AAA69FF945B8F946018B75898A14B80D06xmbrcdx10ciscoc_-- From yoshihiro.ohba@toshiba.co.jp Mon Jun 10 16:06:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB921F99DC for ; Mon, 10 Jun 2013 16:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=-2.185, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcmaS+glXwm7 for ; Mon, 10 Jun 2013 16:06:45 -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 D972A21F9631 for ; Mon, 10 Jun 2013 16:06:44 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r5AN6dcf017816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jun 2013 08:06:39 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5AN6dCC002150; Tue, 11 Jun 2013 08:06:39 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 994; Tue, 11 Jun 2013 08:06:38 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5AN6cpv002144; Tue, 11 Jun 2013 08:06:38 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r5AN6cKY007153; Tue, 11 Jun 2013 08:06:38 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA07152; Tue, 11 Jun 2013 08:06:38 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r5AN6cjf009004; Tue, 11 Jun 2013 08:06:38 +0900 (JST) Received: from TGXML330.toshiba.local by toshiba.co.jp id r5AN6bEC022430; Tue, 11 Jun 2013 08:06:37 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 08:06:37 +0900 From: To: , Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOMRcSeZEmOnUO6Nprz3E76X5kKtxIAgASSsTCAAQ6vgIAAo9BwgABFGQCAAKzlsP//8sKAgAgiqgCAAFQeAIABCw9wgABW9ICAARz0gIAR6GAAgAETJcA= Date: Mon, 10 Jun 2013 23:06:35 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D177C9@tgxml338.toshiba.local> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75E78@xmb-rcd-x10.cisco.com> <9E1F86C3-0925-4617-8998-E74A5A470B00@yegin.org> <913383AAA69FF945B8F946018B75898A14B80D06@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B80D06@xmb-rcd-x10.cisco.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.115] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D177C9tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:06:52 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D177C9tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Tiru, I don=1B$B!G=1B(Bt understand REQ-14. How an SA can be securely negotiate= d without authentication? Yoshihiro Ohba From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Sent: Tuesday, June 11, 2013 12:38 AM To: Alper Yegin Cc: ohba yoshihiro(=1B$BBg>l=1B(B =1B$B5AMN=1B(B =1B$B!{#R#D#C""#N#S#L=1B(B= ); pcp@ietf.org Subject: RE: [pcp] pcp auth requirements The other requirement that was updated as part of the discussion during the= PCP interim meeting is REQ-14, would like to know if there any comments fo= r this req. 5. Other= recommendations REQ-14: There SHOULD be support for a means to provide integrity protection without user authentication, i.e., integrity protection for PCP messages exchanged between a PCP server and anonymous PCP clients. For example, a client visiting foreign networks such as a hotel, hot spot etc where the client may gain access to the network but does not know the credentials to authenticate with the PCP server. a. An SA MUST be made available to the client and server, which will be used for integrity protection of PCP messages. The negotiation of SA should be secure such that the SA is only known to the anonymous client and PCP server. b. A PCP client MUST be able to validate that it is communicating with the designated PCP server and not an attacker posing as a PCP server. --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 30, 2013 11:40 AM To: Tirumaleswar Reddy (tireddy) Cc: yoshihiro.ohba@toshiba.co.jp; pcp@= ietf.org Subject: Re: [pcp] pcp auth requirements This text makes sense. On May 29, 2013, at 4:09 PM, Tirumaleswar Reddy (tireddy) wrote: Thanks Yoshi for the text : OLD : REQ-4- d. If the server wants to send an unsolicited message, but the previous security association for the mapping identified in the original PCP request has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server MUST be able to optionally trigger re- authentication with the client. NEW : REQ-4- d. The server MUST be able to trigger authentication with the client.= The unsolicited message for authentication trigger MUST be integrity prote= cted if there is valid unexpired SA. --Tiru. From: yoshihiro.ohba@toshiba.co.jp [ma= ilto:yoshihiro.ohba@toshiba.co.jp] Sent: Wednesday, May 29, 2013 4:57 AM To: alper.yegin@yegin.org; Tirumaleswar Reddy= (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements OK. Then I suggest forming a requirement without using the term =1B$B!H=1B= (Bre-authentication=1B$B!I=1B(B, something like: The server MUST be able to send authentication trigger to the client when t= here is a mapping. The authentication trigger MUST be integrity protected = if there is a SA. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 29, 2013 1:03 AM To: Tirumaleswar Reddy Cc: ohba yoshihiro; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Tiru, I agree. Alper On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Alper, [1] when the PCP server triggers re-authentication and SA is valid, if the = PCP client does not respond then possibly after N number of re-tries PCP se= rver may want to give up and close the explicit mappings associated with th= e user. This would handle the scenario where PCP client would have crashed = or terminated or connection lost for some reason or the user has logged off= and some other user got the same IP address as the previous user. [2] Even in case 3, we may want similar behavior as [1]. For Case 3, there = could be a scenarios - where PCP server would want to inform the PCP client= that external IP address/port has changed, but the SA is expired. In this = case PCP server would have to trigger re-auth. If re-auth is successful the= n send the mapping update or if there is no response from the client then p= roceed with deleting the explicit mappings after N number of tries. Case 3 could be an optimization to trigger re-authentication only when ther= e is interesting update to be sent from the client or server and not to tri= gger re-authentication before SA expires . --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 12:17 PM To: yoshihiro.ohba@toshiba.co.jp Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Yoshi, You are right. In terms of EAP and RFC 5247, only the second case qualifies= for "EAP re-authentication". On the other hand, first and third case are not the same. And I'd conceptually think of the third case as a some sort of "re-authenti= cation" (apparently not an "EAP re-authentication" per RFC 5247). Anyways, at least I'd like people to be aware of these three different case= s -- even if we cannot find a proper name to all of them. Alper On May 23, 2013, at 1:39 AM, > wrote: Hi Alper, When we talk about re-authentication, we should not care about whether ther= e is a PCP session or not. Please see the following definition in RFC 5247: =1B$B!H=1B(B EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material. =1B$B!H=1B(B According to the above definition, if authentication is conducted over a li= ve SA, it is re-authentication, otherwise it is not re-authentication. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 6:16 AM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Yoshi, Here are the three states: 0. Before PCP client and PCP server has initiated PCP session. 1. There is a PCP session and a live SA. 2. There is a PCP session, but no live SA (i.e., the last used SA is alread= y expired). If we execute auth in state 0, we call it "(initial) authentication". Auth executed in state 1 is called "re-authenticaiton". I'd call auth executed in state 2 a "re-authentication" as well, unless we = want to give it a more specific name. Alper On May 22, 2013, at 11:16 AM, > wrote: Hi Alper, I agree that we should allow unprotected authentication trigger from the se= rver, but we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 22, 2013 4:22 PM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements On May 21, 2013, at 10:14 AM, > > wrote: Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-a= uthentication trigger to the client.=1B$B!I=1B(B If there is no SA available, then the server can send an un-protected re-au= th trigger. We should allow that. This is equivalent to what happens at the very beginning before the very fi= rst authentication between the client and the server. Alper Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_674F70E5F2BE564CB06B6901FD3DD78B12D177C9tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I don=1B$B!G=1B(Bt understand REQ-14.   How an SA can= be securely negotiated without authentication?

 

Yoshihiro Ohba

 <= /o:p>

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif";mso-fareast-language:JA"> Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Tuesday, June 11, 2013 12:38 AM
To: Alper Yegin
Cc: ohba yoshihiro(=1B$BBg>l= =1B(B =1B$B5AMN=1B(B =1B$B!{=1B(B=1B$B#R#D#C=1B(B=1B$B""=1B(B=1B$B#N#S#L=1B(B); pcp@ietf.org
Subject: RE: [pcp] pcp auth requirements

 

The other requirement that wa= s updated as part of the discussion during the PCP interim meeting is REQ-14, would like to know if there any comments for this req.

5.  Other recommendations

      REQ-14: There SHOULD be support for a m= eans to provide integrity

      protection without user authentication,= i.e., integrity protection

      for PCP messages exchanged between a PC= P server and anonymous PCP

      clients.  For example, a client vi= siting foreign networks such as

      a hotel, hot spot etc where the client = may gain access to the

      network but does not know the credentia= ls to authenticate with the

      PCP server.

 

      a.  An SA MUST be made available t= o the client and server, which

          will be used fo= r integrity protection of PCP messages.  The

          negotiation of = SA should be secure such that the SA is only

          known to the an= onymous client and PCP server.

 

      b.  A PCP client MUST be able to v= alidate that it is communicating

          with the design= ated PCP server and not an attacker posing as a

          PCP server.

 

--Tiru.

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg]
Sent: Thursday, May 30, 2013 11:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: yoshihiro.ohba@t= oshiba.co.jp; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

 

This text makes sense.

 

 

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

 

Thanks Yoshi for the text :

 

OLD :

 

REQ-4-

 

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

     &nb= sp;    previous security association for the mapping<= span lang=3D"EN-US" style=3D"font-family:"PMingLiU","serif&q= uot;">

     &nb= sp;    identified in the original PCP request has expired

 

     &nb= sp;    1.  The server can continue to use the same SA t= o protect

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

     &nb= sp;        technically expired.

 

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

     &nb= sp;           PCP client.=

 

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

     &nb= sp;           re-authenti= cate.  For example, if the server indicates

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

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

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

     &nb= sp;           has indeed = changed.

 

     &nb= sp;    2.  The server MUST be able to optionally trigge= r re-

     &nb= sp;        authentication with the clien= t.

 

NEW :

 

REQ-4-

 

      d.= The server MUST be able to trigger authentication with the client. The uns= olicited message for authentication trigger MUST be integrity protected if = there is valid unexpired SA. 

 

--Tiru.<= /span>

From: yoshihiro.ohba@= toshiba.co.jp [mailto:yoshihiro.ohba@tos= hiba.co.jp] 
Sent: Wednesday, M= ay 29, 2013 4:57 AM
To: alper.yegin@yegin.org; Tirumaleswar Reddy (t= ireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

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

 =

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

 =

Yoshihiro Ohba

 =

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, M= ay 29, 2013 1:03 AM
To: Tirumaleswar R= eddy
Cc: ohba yoshihiro= ; pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Tiru,

 

I agree.

 

Alper

 

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

 

Hi Alper,<= /o:p>

 

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

 

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

 

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

 

--Tiru.

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Thursday, Ma= y 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar R= eddy (tireddy); pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Yoshi,

 

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

 

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

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

 

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

 

Alper=

 

 

 

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



Hi Alper,

 =

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

 =

Please see the following defini= tion in RFC 5247:

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

   EAP Re-Authenticat= ion

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

      = EAP peer shares valid unexpired EAP keying material.

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

 =

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

 =

Yoshihiro Ohba

 =

 =

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

 

Hi Yoshi,

 

Here are the three states:

 

0. Before PCP client and PCP server h= as initiated PCP session.

 

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

 

2. There is a PCP session, but no liv= e SA (i.e., the last used SA is already expired).<= /span>

 

 

If we execute auth in state 0, we cal= l it "(initial) authentication".<= /p>

Auth executed in state 1 is called &q= uot;re-authenticaiton".

I'd call auth executed in state 2 a &= quot;re-authentication" as well, unless we want to give it a more spec= ific name.

 

Alper=

 

 

 

 

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




Hi Alper,

 =

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

 =

Yoshihiro Ohba

 =

 

 

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





Tiru,<= /span>

 =

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

 =

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

 =

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

 =

 

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

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

 

Alper=

 

 

 





Regards,

Yoshihiro Ohba

 =

 =

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

 

Hi Alper,<= /o:p>

 

Please see inline [TR]=

 

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

 



 
    &nbs=
p; c.  If a server wants to send an unsolicited message, but the<=
/o:p>
&n=
bsp;         previous security asso=
ciation has expired
&n=
bsp;
&n=
bsp;         1.  The server ca=
n continue to use the same SA to protect
&n=
bsp;            =
; messages pertaining to that mapping, even if the SA is
&n=
bsp;            =
; technically expired.

 
"Expired" means &q=
uot;do not use (even if its still hanging around)". 
We not only do not need to u=
se expired SAs, but also using something expired in any sense is plain wron=
g -- unless someone wants to redefine what "expired" means.<=
/o:p>
&n=
bsp;
[T=
R]
Fo=
r example if we consider MSCHAPv2, there is configuration option where serv=
er accepts the challenge-response from the client even if the password is e=
xpired and allows it be changed. 
&n=
bsp;
Pl=
ease clarify if you have some attack in mind that would cause problems usin=
g expired SA.
&n=
bsp;
[/=
TR]
&n=
bsp;
    &nbs=
p;         -  Such server noti=
fications will not change state in the
&n=
bsp;            =
;    PCP client.
&n=
bsp;
&n=
bsp;            =
; -  The notification could be a trigger for the client to<=
/span>
&n=
bsp;            =
;    re-authenticate.  

 
Here the document is getting=
 into some solution description.

 
And as for such a solution:<=
/span><=
o:p>

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






    &nbs=
p;            For ex=
ample, if the server indicates


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



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



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



&n=
bsp;            =
;    has indeed changed.


&n=
bsp;


&n=
bsp;         2.  The server ca=
n optionally trigger re-authentication with


&n=
bsp;            =
; the client.














 


























 


























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






















 












[T=
R]


&n=
bsp;


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



&n=
bsp;


Be=
st Regards,


--=
Tiru.


&n=
bsp;


[/=
TR]












 


























 


























Alper


























 


























 


























 

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D177C9tgxml338toshiba_-- From hartmans@painless-security.com Mon Jun 10 17:44:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33B511E80C5 for ; Mon, 10 Jun 2013 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7N6ZEn2dUmk for ; Mon, 10 Jun 2013 17:44:39 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0278711E80A6 for ; Mon, 10 Jun 2013 17:44:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1D52520179; Mon, 10 Jun 2013 20:41:02 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpLfqAEp8ZV3; Mon, 10 Jun 2013 20:41:01 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 10 Jun 2013 20:41:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3564780A1B; Mon, 10 Jun 2013 20:44:28 -0400 (EDT) From: Sam Hartman To: Dan Wing References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> <05D1C90B-5B1B-40D3-8EE3-FEC22D48FC4C@cisco.com> <625EB543-060C-44B6-A025-CA1B5BFDAF75@cisco.com> Date: Mon, 10 Jun 2013 20:44:28 -0400 In-Reply-To: <625EB543-060C-44B6-A025-CA1B5BFDAF75@cisco.com> (Dan Wing's message of "Fri, 7 Jun 2013 14:03:20 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:44:45 -0000 I also think it might be possible to relax the restrictions on nonce re-use. In particular if we do the analysis and confirm that the client is the one harmed by enabling potential off-path attacks, then I think it's reasonable for the client to make that security tradeoff. I might for example implement re-using a nonce if the address I am sending to is the same and the IP address I have is the same. --Sam From cheshire@apple.com Mon Jun 10 19:12:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67BD21F9956 for ; Mon, 10 Jun 2013 19:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4F0abMcRjvT for ; Mon, 10 Jun 2013 19:12:04 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 263EE21F9954 for ; Mon, 10 Jun 2013 19:12:03 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO700LF6I1T4L12@mail-out.apple.com> for pcp@ietf.org; Mon, 10 Jun 2013 19:12:03 -0700 (PDT) X-AuditID: 11807143-b7f856d000000818-7c-51b687730105 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 5E.C3.02072.37786B15; Mon, 10 Jun 2013 19:12:03 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MO700FUXI43DK50@spicerack.apple.com> for pcp@ietf.org; Mon, 10 Jun 2013 19:12:03 -0700 (PDT) From: Stuart Cheshire In-reply-to: <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 10 Jun 2013 19:12:03 -0700 Message-id: <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FCsoVvcvi3QoG+XusXkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b2hk7Ggkbni4ZIJTA2MG5m6GDk5JARMJBpafjJD2GISF+6t Z+ti5OIQEpjMJLH29m8oZwWTxIqDl8A6mAV0JHq/fwPr4BXQk9g2dxsbiC0soC3x9vYtdhCb TUBL4sXnK2BxToE4iWPTjzKC2CwCqhJfXz9nh5ijLfHk3QVWiDk2Es+PLmGFWHaaWeLcrg1g zSICihIHtt1ghzhPVuL18zcsExj5ZyG5YxaSO2YhmbuAkXkVo0BRak5ipZFeYkFBTqpecn7u JkZwkBU672A8tszqEKMAB6MSD28C47ZAIdbEsuLK3EOMEhzMSiK8M02BQrwpiZVVqUX58UWl OanFhxilOViUxHmDqoFSAumJJanZqakFqUUwWSYOTqkGxmlHFAvnpMc+u/s93r8+lNU5lMdv 5qTrsl5bpqo//+r++bM1R0z8Hm8t74mz307a+lOpTlPIyOmAyqr/Bo/r286sqZP5bsV7gu1u 6R7J7Bk3Apq6rr9lM7o80WDKxOX+e7Z8MLx87LKt3w9Vz+hjvpoRLxqNWpe3G5w6/V7KmH/V La3+CWskI5VYijMSDbWYi4oTAaQ2I7suAgAA Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:12:10 -0000 On 9 Jun, 2013, at 23:31, mohamed.boucadair@orange.com wrote: > [Med] If an implementation does not follow the spec, then yes failures can be experienced. With the error code, things may be worse: a client may ask for a AF but the server returns an error. Yes. And the developer notices this failure, and fixes the bug before shipping the product. Stuart Cheshire From Ted.Lemon@nominum.com Mon Jun 10 19:30:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0A021E80A1 for ; Mon, 10 Jun 2013 19:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.636 X-Spam-Level: X-Spam-Status: No, score=-106.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NevCexx98S3M for ; Mon, 10 Jun 2013 19:30:19 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 10F9021E80A0 for ; Mon, 10 Jun 2013 19:30:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUbaLuvhLyN+LptZ/qjGEGxnQMehNAYNH@postini.com; Mon, 10 Jun 2013 19:30:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7409D1B81D0 for ; Mon, 10 Jun 2013 19:30:18 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5829519005D; Mon, 10 Jun 2013 19:30:18 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 19:30:12 -0700 From: Ted Lemon To: Stuart Cheshire Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgAAFEYA= Date: Tue, 11 Jun 2013 02:30:11 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751CFA21@mbx-01.win.nominum.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> In-Reply-To: <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:30:26 -0000 On Jun 10, 2013, at 10:12 PM, Stuart Cheshire wrote: > Yes. And the developer notices this failure, and fixes the bug before shi= pping the product. +1 From mohamed.boucadair@orange.com Tue Jun 11 00:02:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA921F9A7C for ; Tue, 11 Jun 2013 00:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_NAIL=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtBzIktrEOGM for ; Tue, 11 Jun 2013 00:01:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 986DC21F9A7A for ; Tue, 11 Jun 2013 00:01:42 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2E1F13B47FC; Tue, 11 Jun 2013 09:01:40 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 144F94C017; Tue, 11 Jun 2013 09:01:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 11 Jun 2013 09:01:39 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Tue, 11 Jun 2013 09:01:37 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5mSRbSCUtc7NwcSIuVcwmW1a2AKAAHXQmw Message-ID: <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> In-Reply-To: <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 07:02:01 -0000 Hi Stuart, all, The failure I'm talking about is the client failure to get an external IP a= ddress/port of any address family.=20 By fixing the bug, do you mean the client (1) will be designed to always as= k for another AF if UNSUP_AF error is received from the server or (2) by ad= justing the zeroed Suggested External IP Address? (1) is much more reliable since a mapping will be created if port quota is = not reached. (2) may solve the problem for a specific testing case but it does not ensur= e no failure will be experienced if you change the setup. How the pcp clien= t knows the capabilities of the server to set the suggested AF accordingly?= =20 I tried to summarize this discussion in the following table: +----------------------+-----------------------+--------------------+ | No Capability Discovery is supported | +----------------------+-----------------------+--------------------+ | Client's Behavior | UNSUPP_AF | Suggested AF is | | | | only a hint | +----------------------+-----------------------+--------------------+ | The client sends one | Failure may be | A mapping can be | | request only | experienced (i.e., no | created | | | mapping won't be | | | | created if the AF is | | | | not adjusted) | | +----------------------+-----------------------+--------------------+ | The client tries | A mapping can be | N/A | | another AF only if | created | | | an error is received | | | +----------------------+-----------------------+--------------------+ | The client issues | One mapping and an | The same mapping | | systematically two | error code will be | will be returned | | requests with | returned if the | if the server | | distinct AFs | server supports one | supports one AF. | | | AF. Two mappings will | Two mappings will | | | be created if the | be created if the | | | server supports two | server supports | | | AFs. | two AFs. | +----------------------+-----------------------+--------------------+ +----------------------+-----------------------+--------------------+ | Capability Discovery is supported | +----------------------+-----------------------+--------------------+ | Client's Behavior | UNSUPP_AF | Suggested AF is | | | | only a hint | +----------------------+-----------------------+--------------------+ | The client may issue | One or two mappings | One or two | | 0, 1 or 2 requests | will be created if | mappings will be | | to the server | the server supports | created if the | | (according to the | two AFs. If the | server supports | | capabilities of the | capability discovery | two AFs. | | PCP server) | is reliable, | | | | UNSUPP_AF won't be | | | | used by the server | | +----------------------+-----------------------+--------------------+ We should focus more on the behavior of the PCP Client.=20 Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: mardi 11 juin 2013 04:12 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On 9 Jun, 2013, at 23:31, mohamed.boucadair@orange.com wrote: > >> [Med] If an implementation does not follow the spec, then yes failures >can be experienced. With the error code, things may be worse: a client may >ask for a AF but the server returns an error. > >Yes. And the developer notices this failure, and fixes the bug before >shipping the product. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohta@necom830.hpcl.titech.ac.jp Tue Jun 11 05:41:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB221F96E1 for ; Tue, 11 Jun 2013 05:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ba5A3DpvMPa for ; Tue, 11 Jun 2013 05:41:06 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 4F5DE21F9983 for ; Tue, 11 Jun 2013 05:41:05 -0700 (PDT) Received: (qmail 15553 invoked from network); 11 Jun 2013 12:37:54 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 11 Jun 2013 12:37:54 -0000 Message-ID: <51B71A8B.2030308@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Jun 2013 21:39:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> In-Reply-To: <99357621-5988-432E-BC8F-9C1C22BA30F1@apple.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Problem with nonce checking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:41:11 -0000 Stuart Cheshire wrote: > Here's the problem: > > 1. Client makes 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins. > 2. Client reboots, or similar, and picks new nonce. > 3. Client requests 24-hour MAP mapping to 10.0.0.2:22 so it can receive ssh logins. > 4. NOT_AUTHORIZED! It merely means that what is necessary is not any nonce but a transaction ID. > I think we need to remove the server nonce check. Right. As the nonce, as an transaction ID, is specified by a client. servers MUST accept any transaction IDs offered by their clients, which initiate the transaction. Using transaction ID straightly makes security implications a lot clearer than insisting on a nonce as a poor alternative as the required-by-IESG transaction ID. Masataka Ohta From repenno@cisco.com Tue Jun 11 06:04:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1307C21F901F for ; Tue, 11 Jun 2013 06:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmHEhy8XNlIZ for ; Tue, 11 Jun 2013 06:04:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 54BB021F9433 for ; Tue, 11 Jun 2013 06:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4100; q=dns/txt; s=iport; t=1370955874; x=1372165474; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=orTuunNa87MZCwnjDHSZZ6jrsl1d3Ws6T813/AM/gJk=; b=I7E4ER0KBgAFFEb2PoyNue4JMOf9PEJJazCiErBsaxIbfYPVbjyeHZ0y KdgpUlbhniFp4Wq3x0zPC78GEVSxk2TUPI+ZCNl0dR5JA16wjHFVoR9jB 486ODbBYS65Eg048gl50gobf6XkRZQB74IKT5HzeBOPVpZiLvCUhxeNjN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK0ft1GtJV2a/2dsb2JhbABZgwkwSb5LfRZ0giMBAQEEAQEBJEcLEgEIGApLCyUCBAENBQiIBQy6PY8BMQeCf2EDiGiQAYhzhyaDD4In X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="221382193" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jun 2013 13:04:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5BD4Xbr022347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 13:04:33 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 08:04:33 -0500 From: "Reinaldo Penno (repenno)" To: Simon Perreault , Stuart Cheshire Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFLhzk+wmJ2FkiifnZjmrMpJJkeQoaAgAAI4QCAAAE5AIAACd0AgBJmUYA= Date: Tue, 11 Jun 2013 13:04:32 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> In-Reply-To: <51A786E0.2060003@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.72.200] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8BA95A13724B21449AACDBBEC6306A2E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:04:39 -0000 Hi Stuart, Are you planning on updating the draft with this discussion of EI - FAMILY- Mappings and internal port considerations? Thanks, Reinaldo On 5/30/13 2:05 PM, "Simon Perreault" wrote: >Le 2013-05-30 18:30, Stuart Cheshire a =E9crit : >> On 30 May 2013, at 9:25, Simon Perreault wrote: >> >>> - What would happen if a network-specific NAT64 prefix is used? How >>>can the PCP client know what will happen (NAT64 or NAT66) to packets it >>>sends if it doesn't know about that prefix? >>> >>> - What would happen in the NAT44 + NAT46 example we've been >>>discussing? There is no well-known prefix to help disambiguate. >>> >>> Note that I'm not considering only replies to connections initiated >>>from the outside. I'm also interested in connections initiated from the >>>inside, which MAP also covers. >> >> I agree that outbound connections (and packets) need to work. >> >> I don't think the client needs to know what will happen. But the >>gateway does know. If the destination is a "real" address then the >>packet is sent to that address. If the destination address belongs to >>the address-family-translating gateway's address pool, then the gateway >>MUST translate it to the other address family, because the destination >>is not a "real" address and will go nowhere useful if sent as-is. > >Hmmm... I started replying to this with a counter-example where the >client *needs* to know what will happen, but I could not make it work. >What you're saying seems correct. I need to sleep on this. > >Now, the second and somewhat less important reason that mappings cannot >share the same internal port is that, as the RFC is currently written, >two matchings do not involve the external address. > >a) Servers match requests against existing mappings on the internal >address + port. This happens before the suggested external address field >is inspected. Section "11.3. Processing a MAP Request": > > If the internal port, protocol, and internal address match an > existing static mapping (which will have no nonce), then a PCP reply > is sent giving the external address and port of that static mapping, > using the nonce from the PCP request. The server does not record the > nonce. > > [...] > > It is possible that a mapping might already exist for a requested > internal address, protocol, and port. If so, the PCP server takes > the following actions: > > [...] > > If no mapping exists for the internal address, protocol, and port, > and the PCP server is able to create a mapping using the suggested > external address and port, it SHOULD do so. > >b) Clients match responses with requests on the internal address + port. >Section "11.4. Processing a MAP Response": > > After performing common PCP response processing, the response is > further matched with a previously sent MAP request by comparing the > internal IP address (the destination IP address of the PCP response, > or other IP address specified via the THIRD_PARTY option), the > protocol, the internal port, and the mapping nonce. Other fields are > not compared, because the PCP server sets those fields. > >Could these two things be updated in your draft? We would need to say >basically that the suggested external address family is also part of the >match tuple in both cases. There would be two consequences to that: > >- The client would now be expected to set the suggested external address >family correctly in refresh requests. > >- The server could not reply with an external address family different >from the one contained in the request. > > >Thanks all for the frenetic exchange! > >Simon >--=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 Jun 11 08:27:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B838B21F99FE for ; Tue, 11 Jun 2013 08:27:19 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAX6xsgnEFTJ for ; Tue, 11 Jun 2013 08:27:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 501AC21F9648 for ; Tue, 11 Jun 2013 08:27:19 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:b1c1:9153:f2b7:b787]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A0847403DD for ; Tue, 11 Jun 2013 11:27:18 -0400 (EDT) Message-ID: <51B741D6.6010606@viagenie.ca> Date: Tue, 11 Jun 2013 17:27:18 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:27:19 -0000 Mohamed, I think Stuart is right on this issue. I'll try replying from my point of view: The point is that all clients will know how to handle errors. It is required for basic funtionality. Not all clients will know how to handle external addresses of a different AF than they asked for. It is highly unusual and will likely not be tested. So if you have an ecosystem of clients that will crash when the PCP server returns an external addresses of a different AF than they asked for, why would you want the server to do that? Remember that not everyone is in the situation of having control over the PCP server *and* the client. Server admins will be faced with an heterogeneous set of clients. Simon From repenno@cisco.com Tue Jun 11 10:42:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51F21F8FEC for ; Tue, 11 Jun 2013 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b9XnJ7Ci49t for ; Tue, 11 Jun 2013 10:42:51 -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 14A8B21F8EBE for ; Tue, 11 Jun 2013 10:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5248; q=dns/txt; s=iport; t=1370972571; x=1372182171; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nso9vUrFhAyMb1KZR4GfBWQ4RNbUr2y9kauHXdABFuY=; b=eKYvNBaiPvWb97P4qv8nyShPVz85u+0wJFn0swc+gQC7AwsUQzEui4Iz /Rts2Bs/Peytj555yqHT7tsb6Vx6XKLXYx2nMqVU0r41+0vsfpj+oGCCN xb5GV6T3e54ZmYRQOOlYCfCiYbEycSefQEcYDsbBYXxUWkthC/Dp8haJU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJNgt1GtJXG9/2dsb2JhbABZgwkwQwa+ToEAFnSCIwEBAQQBAQEkRwsSAQgYCh0uCxQRAgQOBQgBh3IDDwcFsXUIiFeOfwIxAgWCf2EDiGiQAYp4hSGDD4In X-IronPort-AV: E=Sophos;i="4.87,846,1363132800"; d="scan'208";a="221504705" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jun 2013 17:42:50 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5BHgoE9004089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 17:42:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 12:42:49 -0500 From: "Reinaldo Penno (repenno)" To: Norman Sardella Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt Thread-Index: AQHOY67NkA/yR9t130u/0DZr0tFYL5ksDoaAgADImYCABBkwAA== Date: Tue, 11 Jun 2013 17:42:49 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A61F8@xmb-rcd-x04.cisco.com> In-Reply-To: <51B3C743.9070401@comcast.net> 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.95.213] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <37FFABEC2515E14FA69E09CAD599FD9E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:42:56 -0000 Hi Norman, this point is very interesting. Although I've seen similar implementations before, i.e., PCP was built on top of existing Load-Balancing/FW code - actually PCP was used for load-balancing, nothing related to NAT (but that is for another time), I believe first you will need to decide on a few design things. Q: If the master entry times out, will you forcefully nuke all derived entries? A: If yes, then all your timer replies should probably be based on the master entry timer. Q: Does the master entry only times out after the last derived session entry times=20 out? In other words, indirectly (or directly) packets matching derived session refresh master entry. A: Then all your timer replies should probably be based on 2hrs and 4 minutes, which would be the idle-timeout of a derived TCP session if packets stopped flowing 'now'. Or the equivalent for UDP/ICMP, etc. Another important aspect is whether you would "freeze" the master entry after a delete message is received. I've seen implementations where after the PCP MAP delete message is received, no more derived sessions are created since mapping is in "deleting" state. But this is implementation specific. Thanks, Reinaldo On 6/8/13 9:07 PM, "Norman Sardella" wrote: >Hi Reinaldo , see comments below >On 6/8/2013 11:09 AM, Reinaldo Penno (repenno) wrote: >> >> >> On 6/7/13 3:42 PM, "Norman Sardella" wrote: >> >>> Mohamed >>> >>> I have a question in your examples in section 2.12, >>> about returning remaining idle-timeout on MAP delete response >>>> |--------------------------------->| >>>> | PCP MAP Response (Lifetime=3D | >>>> | remaining idle-timeout) | >>> >>> Some LSN implementations are incapable of returning the remaining >>> lifetime because each flow creates a separate NAT translation >>> based of the PCP master created NAT entry. >>> In this case, which of the other NAT entries would we pick to return an >>> idle-timeout? >> >> >> How does your implementation work? Does the mater entry have a timer of >> its own or packets hitting the derived sessions refresh the main entry? >Each flow(connection) to external address/port has its own NAT entry >with its own timer. The master from the PCP map openrs anan external >address/port to an internal host and has its own timer. > > >> >> Does each derived entry have a timer of its own? >Each derived entry has its own timer. > >> >> >>> >>> How are PCP clients expected to use the lifetime in delete mappings >>> responses? >>> Should a PCP server return 0, return idle-timeout value, or the age >>> remaining when the PCP master NAT entry was created? >> >> See above. This is implementation specific and to help answer this >> questions we need to understand how your implementation work. >> >>> >>> Thanks >>> Norman Sardella >>> >>> >>> On 05/30/2013 05:36 AM, mohamed.boucadair@orange.com wrote: >>>> Dear all, >>>> >>>> This updated version includes two additional use case suggested by >>>>Dan. >>>> >>>> Don't hesitate to share any use case you think it is worth to be >>>> documented this I-D. >>>> >>>> Cheers, >>>> Med >>>> >>>> -----Message d'origine----- >>>> De : i-d-announce-bounces@ietf.org >>>> [mailto:i-d-announce-bounces@ietf.org] De la part de >>>> internet-drafts@ietf.org >>>> Envoy=E9 : jeudi 30 mai 2013 11:27 >>>> =C0 : i-d-announce@ietf.org >>>> Objet : I-D Action: draft-boucadair-pcp-flow-examples-01.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : PCP Flow Examples >>>> Author(s) : Mohamed Boucadair >>>> Filename : draft-boucadair-pcp-flow-examples-01.txt >>>> Pages : 32 >>>> Date : 2013-05-30 >>>> >>>> Abstract: >>>> This document provides a set of examples to illustrate PCP >>>> operations. It is a companion document to the base PCP >>>> specification. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-flow-examples-0= 1 >>>> >>>> >>>> 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 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>> >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >> From bn.mccann@gmail.com Tue Jun 11 14:55:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931321F8FB6 for ; Tue, 11 Jun 2013 14:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uDzZ3xeWWIv for ; Tue, 11 Jun 2013 14:55:02 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F1B3721F994C for ; Tue, 11 Jun 2013 14:54:57 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so5935447pad.32 for ; Tue, 11 Jun 2013 14:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; bh=JSTBAz/CsEcS74mflQmLLwpDyh8LGkmtDTIDSEDuVNY=; b=lBW+RWSJ8QhjgzfcNt12mzuRLbdoj+Zpd32YRBiK3WxLBi3WyaqSEL10BVEwieKngZ qVpwADjTxiilE+YqLwYUjpCn8tlPo+M5HeZ5Wp6njA69FiZFYPT/o0y/djZ4q0IKbMTU pvoHACIW3AhTxA91n2OjACBeFN3Y0gB7cbk+QZXfCDCySOXZDKyNc71JSKfjw6F/Gkh/ jHumy6UG5/iPfvZSRDUeNpLFIhB5kehTBsq110+CQh6C+94rrVwChR6p5YHF4u0VY3HZ f9lnqdpJGDWDhcyE3tem4I7KsPo/r0oajffC5/LQHa0HlgN0rVfcCDPMqpEaVfaLu5bn ixTw== X-Received: by 10.66.83.7 with SMTP id m7mr7412375pay.150.1370987697732; Tue, 11 Jun 2013 14:54:57 -0700 (PDT) Received: from [10.10.20.203] (70-88-209-30-ubr905-ne-ma.hfc.comcastbusiness.net. [70.88.209.30]) by mx.google.com with ESMTPSA id bs2sm21692543pad.17.2013.06.11.14.54.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 14:54:56 -0700 (PDT) Message-ID: <51B79CB0.3050303@gmail.com> Date: Tue, 11 Jun 2013 17:54:56 -0400 From: Ben McCann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tireddy@cisco.com Content-Type: multipart/alternative; boundary="------------060305060700070308020201" Cc: pcp@ietf.org Subject: [pcp] PCP Proxy Authentication Requirements? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 21:55:03 -0000 This is a multi-part message in MIME format. --------------060305060700070308020201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate message integrity and that it must be able to ensure message integrity if it modifies any fields in the message. Doesn't this require authenticating the proxy to the PCP client and server because the proxy will need separate Security Associations to both the client and the server? I.e. without knowledge of the EAP Master Session Key, the proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it can form MSK's for both the client and the server. (I know, I'm assuming EAP is part of the authentication design). Does Req-9 need clarification to note the presence of a proxy**requires *two *separately authenticated security associations? And, should the requirements permit authentication only on one side of the proxy? For example, a customer premises host may not authenticate to the PCP proxy but the proxy may authenticate to the PCP server? On another topic... There was substantial discussion on the list about two major PCP authentication architectures, *direct* *EAP-over-PCP *and *PANA*. I'm still catching up on the history of PCP authentication so forgive me if this question has been asked before/. /Are either of these protocols currently favored or has that discussion been tabled until the requirements are finalized? I'm curious because PANA includes a secondary RFC (RFC 6345 ) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent. If a PANA relay is required for a PANA deployment, and PCP was authenticated by PANA, then how would the PANA payloads embedded in PCP packets traverse the PANA relay? This is another area where PANA requires tweaking to support PCP authentication. IMO, it is preferable to design an EAP transport within PCP because it can be purpose-built to address the specific requirements of PCP such as the PCP proxy. (Again, I assume EAP will be part of the PCP authentication protocol). -Ben McCann --------------060305060700070308020201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate message integrity and that it must be able to ensure message integrity if it modifies any fields in the message.

Doesn't this require authenticating the proxy to the PCP client and server because the proxy will need separate Security Associations to both the client and the server? I.e. without knowledge of the EAP Master Session Key, the proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it can form MSK's for both the client and the server. (I know, I'm assuming EAP is part of the authentication design).

Does Req-9 need clarification to note the presence of a proxy requires two separately authenticated security associations? And, should the requirements permit authentication only on one side of the proxy? For example, a customer premises host may not authenticate to the PCP proxy but the proxy may authenticate to the PCP server?


On another topic...

There was substantial discussion on the list about two major PCP authentication architectures, direct EAP-over-PCP and PANA. I'm still catching up on the history of PCP authentication so forgive me if this question has been asked before. Are either of these protocols currently favored or has that discussion been tabled until the requirements are finalized?

I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent.

If a PANA relay is required for a PANA deployment, and PCP was authenticated by PANA, then how would the PANA payloads embedded in PCP packets traverse the PANA relay? This is another area where PANA requires tweaking to support PCP authentication.

IMO, it is preferable to design an EAP transport within PCP because it can be purpose-built to address the specific requirements of PCP such as the PCP proxy. (Again, I assume EAP will be part of the PCP authentication protocol).

-Ben McCann

--------------060305060700070308020201-- From cheshire@apple.com Tue Jun 11 21:44:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697D021F99F4 for ; Tue, 11 Jun 2013 21:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pah2t6+PYMQv for ; Tue, 11 Jun 2013 21:44:54 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A521F9A22 for ; Tue, 11 Jun 2013 21:44:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO900I9DJUC1L72@mail-out.apple.com> for pcp@ietf.org; Tue, 11 Jun 2013 21:44:53 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-69-51b7fcc56ab7 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 42.A4.15051.5CCF7B15; Tue, 11 Jun 2013 21:44:53 -0700 (PDT) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MO9008PPJUS7G70@koseret.apple.com> for pcp@ietf.org; Tue, 11 Jun 2013 21:44:53 -0700 (PDT) From: Stuart Cheshire In-reply-to: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> Date: Tue, 11 Jun 2013 21:44:52 -0700 Message-id: References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUiON1OXffon+2BBiduCFhMPvab1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGT13jrMXnGSq2PjiAnsDYxtTFyMnh4SAicTBrRtYIGwxiQv3 1rN1MXJxCAm0MEnc2D6dBcI5wCRx7PZaNpAqZgEtifU7j4N18woYSiy5voUdxBYW0JZ4e/sW mM0GVPPi8xWwek4BX4kDLzYygtgsAqoSp2Z2MkPMkZfYvOYtM8QcG4lp9+4B9XIALfORmLja ECQsIiAg8Xv1ZahDZSV23jnNMoGRfxaSK2YhuWIWkqkLGJlXMQoUpeYkVlroJRYU5KTqJefn bmIEBVhDYdoOxqblVocYBTgYlXh4D5htDxRiTSwrrsw9xCjBwawkwqubCxTiTUmsrEotyo8v Ks1JLT7EKM3BoiTOG1q9LVBIID2xJDU7NbUgtQgmy8TBKdXAuE64Z839vP/HUou/f1yyauud mn+PVOavEeTa0sEgNbV2wmG7xsamUgch0cygGT/0bJhlV1n+WZtmW1G3Me2PWeCPybWtd64X 5fkbq847/W/16tAwq83/9wp4TOFcl5+bahW9v4el0Ljnnyhrn+GrmGtzT3Gv0bbZU2/z/8Zv McafK+f2vVt3SImlOCPRUIu5qDgRAPQtH8QsAgAA Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 04:44:59 -0000 On 11 Jun 2013, at 6:04, Reinaldo Penno (repenno) wrote: > Hi Stuart, > > Are you planning on updating the draft with this discussion of EI - > FAMILY- Mappings and internal port considerations? > > Thanks, > > Reinaldo Done: Stuart Cheshire From mohamed.boucadair@orange.com Tue Jun 11 23:28:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B264D21F9C12 for ; Tue, 11 Jun 2013 23:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JWRCK+sQRah for ; Tue, 11 Jun 2013 23:27:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A8C2021F9C14 for ; Tue, 11 Jun 2013 23:27:53 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5B4503B496E; Wed, 12 Jun 2013 08:27:52 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2B0E227C07F; Wed, 12 Jun 2013 08:27:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 12 Jun 2013 08:27:52 +0200 From: To: Simon Perreault , "pcp@ietf.org" Date: Wed, 12 Jun 2013 08:27:50 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5muCvnWe00d/0VSc+sUZSBQ64k8gAeyGIQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED963972A@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <51B741D6.6010606@viagenie.ca> In-Reply-To: <51B741D6.6010606@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 06:28:01 -0000 Simon, What I'm arguing for is exactly what Stuart said in Slide 7 of his presenta= tion available at: http://www.ietf.org/proceedings/80/slides/pcp-8.pdf! The question is not whether we agree or not with the new proposed error cod= e but how can we help a client to successfully create a mapping and what ar= e the triggers for a client to adjust the suggested external IP address in = the first request? Given: * the client is not aware of the AFs supported by a PCP server * the client want to maximize its chance to establish communications with r= emote peers of distinct/various AFs,=20 * the server uses the suggested external filed as a hint * the server cannot reject a well-formed request (according to Stuart's pri= nciple) Is it normal to return an error instead of serving the client? Cheers, Med=20 >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si= mon >Perreault >Envoy=E9=A0: mardi 11 juin 2013 17:27 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >Mohamed, > >I think Stuart is right on this issue. I'll try replying from my point >of view: > >The point is that all clients will know how to handle errors. It is >required for basic funtionality. > >Not all clients will know how to handle external addresses of a >different AF than they asked for. It is highly unusual and will likely >not be tested. > >So if you have an ecosystem of clients that will crash when the PCP >server returns an external addresses of a different AF than they asked >for, why would you want the server to do that? > >Remember that not everyone is in the situation of having control over >the PCP server *and* the client. Server admins will be faced with an >heterogeneous set of clients. > >Simon >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From cheshire@apple.com Tue Jun 11 23:59:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3221F9C16 for ; Tue, 11 Jun 2013 23:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMDRC0NAYIWG for ; Tue, 11 Jun 2013 23:59:42 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9367A21F9C15 for ; Tue, 11 Jun 2013 23:59:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO900A3EQ3AST72@mail-out.apple.com> for pcp@ietf.org; Tue, 11 Jun 2013 23:59:42 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-5e-51b81c5e1ba1 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id CA.3B.15051.E5C18B15; Tue, 11 Jun 2013 23:59:42 -0700 (PDT) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MO9002P9Q3H4V30@koseret.apple.com> for pcp@ietf.org; Tue, 11 Jun 2013 23:59:41 -0700 (PDT) From: Stuart Cheshire In-reply-to: <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 11 Jun 2013 23:59:41 -0700 Message-id: References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> To: pcp@ietf.org X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUiON1OXTdOZkegwb2zHBaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrSDgQVnuCueHnzH3MC4nrOLkZNDQsBE4vmvJawQtpjEhXvr 2boYuTiEBFqYJA6tWsEOkhASOMAksfJuKIjNLKAlsX7ncSYQm1fAUGLJ9S1gNcIC2hJvb98C s9mAal58vsIGYnMKxEk8a7/IDGKzCKhK3Hn2mBVijrbEk3cXgGwOoDk2En+PSEDsvcAi8WrJ IrAaEQEBid+rLzNBHCcrsfPOaZYJjPyzkJwxC8kZs5CMXcDIvIpRoCg1J7HSQi+xoCAnVS85 P3cTIyi8GgrTdjA2Lbc6xCjAwajEw3vAbHugEGtiWXFl7iFGCQ5mJRHeP8I7AoV4UxIrq1KL 8uOLSnNSiw8xSnOwKInzhlZvCxQSSE8sSc1OTS1ILYLJMnFwSjUwSnWdnlS9t6qKa1LirhVv tA2Uqz+ol/e1XW73jWlvu3PsyMlvXGozl6jLhoa8cntm91s+yLTY9Njp6lVvWEzW7ctPVQ28 0Lo6+M/0r4x2HTcXJKpsmPLpYAc3J+dUye4PQrFOR5Zzzb/2u/bK7F7tuvuX2pco7/5V1/Qu 7+ScuHBm7Rhm1/tWSizFGYmGWsxFxYkAYAn61SsCAAA= Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 06:59:49 -0000 On 11 Jun 2013, at 0:01, mohamed.boucadair@orange.com wrote: > Hi Stuart, all, > > The failure I'm talking about is the client failure to get an external IP address/port of any address family. Software cannot reason about an unexpected situation and decide on an appropriate course of action. Software can only execute behaviours that have been programmed by the software writer. And software writers don't program behaviours that they haven't thought of. If the software writer has never thought about the case of getting an IPv6 address back, then the software will not handle that. It can't work out for itself what to do when it happens. It's quite likely it will take the last four bytes of the IPv6 address and assume that's an IPv4 address, which will not work. So the challenge is to make software writers aware of this. If client software appears to "work", then it will get shipped. If client software doesn't work, and the users or testers report, "There's a message in syslog about error 14," then the issue enters the software writer's consciousness, and they investigate why it's happening, and fix their software. The longer we let client software writers remain blissfully unaware that they're inadvertently requesting an IPv6 address, the bigger problem we're creating for ourselves when gateways start honouring the client request and actually start returning IPv6 addresses. Stuart Cheshire From mohamed.boucadair@orange.com Wed Jun 12 01:31:47 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A692721F9BB9 for ; Wed, 12 Jun 2013 01:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT8JALTGb1tc for ; Wed, 12 Jun 2013 01:31:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 482D621F9BA7 for ; Wed, 12 Jun 2013 01:31:43 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BB321324F6F; Wed, 12 Jun 2013 10:31:41 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A0CCA27C054; Wed, 12 Jun 2013 10:31:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 12 Jun 2013 10:31:41 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Wed, 12 Jun 2013 10:31:38 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5nOnA+D/GrgnQzQyKj46rn0XcC6QABZnMA Message-ID: <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.12.51222 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 08:31:47 -0000 Stuart, We are approaching the problem with two different perspectives: * You are more concerned about "poor" PCP client implementations * I'm more concerned about how a client can get connectivity and how the se= rver can help in maximizing the chance to honor a request I understand your concern but defining a new error code will create a new c= onnectivity failure case if the client does not try another request with th= e adjusted Suggested External IP Address. But what are the guarantees a "po= or" implementation will try another adjusted request? When I say a PCP should be prepared to receive any address AF in a response= , this means a corresponding test case to assess the behavior of a PCP clie= nt should be envisaged.=20 IMHO, we should focus on the origin of the problem:=20 * How PCP can help a client to get connectivity? * What are the triggers for a PCP client to adjust the Suggested External I= P Address? Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: mercredi 12 juin 2013 09:00 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On 11 Jun 2013, at 0:01, mohamed.boucadair@orange.com wrote: > >> Hi Stuart, all, >> >> The failure I'm talking about is the client failure to get an external I= P >address/port of any address family. > >Software cannot reason about an unexpected situation and decide on an >appropriate course of action. Software can only execute behaviours that >have been programmed by the software writer. And software writers don't >program behaviours that they haven't thought of. If the software writer ha= s >never thought about the case of getting an IPv6 address back, then the >software will not handle that. It can't work out for itself what to do whe= n >it happens. It's quite likely it will take the last four bytes of the IPv6 >address and assume that's an IPv4 address, which will not work. > >So the challenge is to make software writers aware of this. > >If client software appears to "work", then it will get shipped. > >If client software doesn't work, and the users or testers report, "There's >a message in syslog about error 14," then the issue enters the software >writer's consciousness, and they investigate why it's happening, and fix >their software. > >The longer we let client software writers remain blissfully unaware that >they're inadvertently requesting an IPv6 address, the bigger problem we're >creating for ourselves when gateways start honouring the client request an= d >actually start returning IPv6 addresses. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Jun 12 03:31:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27FA21F9C2C for ; Wed, 12 Jun 2013 03:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgYwdqtyB5lO for ; Wed, 12 Jun 2013 03:31:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5977521F9C2A for ; Wed, 12 Jun 2013 03:31:33 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:b1c1:9153:f2b7:b787]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8BE6A46A16; Wed, 12 Jun 2013 06:31:32 -0400 (EDT) Message-ID: <51B84E03.5050001@viagenie.ca> Date: Wed, 12 Jun 2013 12:31:31 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stuart Cheshire References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 10:31:34 -0000 Le 2013-06-12 06:44, Stuart Cheshire a écrit : > Done: Good job! Still missing is the nonce check thing. Here's some text as a contribution: X. New Nonce Check Behavior A server verifies the nonce in a MAP or PEER request as described in Sections 11.3 and 12.3 of [RFC6887]. In a nutshell, the server returns NOT_AUTHORIZED when the nonce check fails for a refresh request. This behavior is problematic for two reasons: - It makes PCP less useful by preventing its use for explicitly conveying information about an existing mapping while this information can be discovered by implicit means. For example, traffic could be sent to a destination controlled by the client to discover the applicable mapping's external address. Furthermore, the mapping's lifetime could be discovered heuristically by sending such probe traffic at regular interval. - It makes PCP behave differently for explicit dynamic versus other kinds of mappings. Indeed, requests matching static mappings are not subjected to the nonce check and will result in a response containing the static mapping's current state. There is no reason that MAP requests matching a dynamic mapping should return less information. Therefore, the following new nonce check behaviour MUST be implemented instead: X.1. Nonce Check for MAP Requests If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and the internal port, protocol, internal address, and external address family match an existing explicit dynamic mapping, but the mapping nonce does not match, a PCP reply is sent giving the external address, external port, and remaining lifetime of the mapping, using the nonce from the PCP request. The existing mapping and its nonce MUST NOT be modified. This specification makes no statement about mapping nonce with the Advanced Threat Model. X.2. Nonce Check for PEER Requests If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and the internal port, protocol, internal address, and external address family match a mapping that already exists, but the mapping nonce does not match (that is, a previous PEER request was processed), a PCP reply is sent giving the external address, external port, and remaining lifetime of the mapping using the nonce from the PCP request. The existing mapping and its nonce MUST NOT be modified. This specification makes no statement about mapping nonce with the Advanced Threat Model. In summary, the only remaining circumstance where NOT_AUTHORIZED is to be returned, as described in Section 15.1 of [RFC6887], is when a PCP client attemps to delete a static mapping (i.e., a mapping created outside of PCP itself) or an outbound (implicit or PEER-created) mapping. Simon From mohamed.boucadair@orange.com Wed Jun 12 04:05:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7321F9C3F for ; Wed, 12 Jun 2013 04:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzZA+1VE+kZ4 for ; Wed, 12 Jun 2013 04:05:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB2021F9C31 for ; Wed, 12 Jun 2013 04:05:10 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 104CC18CE02; Wed, 12 Jun 2013 13:05:09 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DA92827C072; Wed, 12 Jun 2013 13:05:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 12 Jun 2013 13:05:08 +0200 From: To: Simon Perreault , Stuart Cheshire Date: Wed, 12 Jun 2013 13:05:00 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5nWD5pvbkpZodCQKGJFJkCz3bzZwAA9s2g Message-ID: <94C682931C08B048B7A8645303FDC9F36ED9639902@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> <51B84E03.5050001@viagenie.ca> In-Reply-To: <51B84E03.5050001@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 11:05:26 -0000 IMHO, the nonce text can be included in http://datatracker.ietf.org/doc/dra= ft-boucadair-pcp-failure/ which identified already this issue.=20 Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si= mon >Perreault >Envoy=E9=A0: mercredi 12 juin 2013 12:32 >=C0=A0: Stuart Cheshire >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >Le 2013-06-12 06:44, Stuart Cheshire a =E9crit : >> Done: > >Good job! > >Still missing is the nonce check thing. Here's some text as a contribution= : > > >X. New Nonce Check Behavior > >A server verifies the nonce in a MAP or PEER request as described in >Sections 11.3 and 12.3 of [RFC6887]. In a nutshell, the server returns >NOT_AUTHORIZED when the nonce check fails for a refresh request. > >This behavior is problematic for two reasons: > >- It makes PCP less useful by preventing its use for explicitly >conveying information about an existing mapping while this information >can be discovered by implicit means. For example, traffic could be sent >to a destination controlled by the client to discover the applicable >mapping's external address. Furthermore, the mapping's lifetime could be >discovered heuristically by sending such probe traffic at regular interval= . > >- It makes PCP behave differently for explicit dynamic versus other >kinds of mappings. Indeed, requests matching static mappings are not >subjected to the nonce check and will result in a response containing >the static mapping's current state. There is no reason that MAP requests >matching a dynamic mapping should return less information. > >Therefore, the following new nonce check behaviour MUST be implemented >instead: > >X.1. Nonce Check for MAP Requests > >If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and >the internal port, protocol, internal address, and external address >family match an existing explicit dynamic mapping, but the mapping nonce >does not match, a PCP reply is sent giving the external address, >external port, and remaining lifetime of the mapping, using the nonce >from the PCP request. The existing mapping and its nonce MUST NOT be >modified. This specification makes no statement about mapping nonce with >the Advanced Threat Model. > >X.2. Nonce Check for PEER Requests > >If operating in the Simple Threat Model (Section 18.1 of [RFC6887]), and >the internal port, protocol, internal address, and external address >family match a mapping that already exists, but the mapping nonce does >not match (that is, a previous PEER request was processed), a PCP reply >is sent giving the external address, external port, and remaining >lifetime of the mapping using the nonce from the PCP request. The >existing mapping and its nonce MUST NOT be modified. This specification >makes no statement about mapping nonce with the Advanced Threat Model. > >In summary, the only remaining circumstance where NOT_AUTHORIZED is to >be returned, as described in Section 15.1 of [RFC6887], is when a PCP >client attemps to delete a static mapping (i.e., a mapping created >outside of PCP itself) or an outbound (implicit or PEER-created) mapping. > > > >Simon >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Jun 12 04:10:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6F21F9C3F for ; Wed, 12 Jun 2013 04:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYANEkSGAcaS for ; Wed, 12 Jun 2013 04:10:50 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91E21F9C3E for ; Wed, 12 Jun 2013 04:10:50 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:b1c1:9153:f2b7:b787]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 79A1D403D6; Wed, 12 Jun 2013 07:10:49 -0400 (EDT) Message-ID: <51B85739.2010309@viagenie.ca> Date: Wed, 12 Jun 2013 13:10:49 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> <51B84E03.5050001@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED9639902@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED9639902@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 11:10:50 -0000 Le 2013-06-12 13:05, mohamed.boucadair@orange.com a écrit : > IMHO, the nonce text can be included in http://datatracker.ietf.org/doc/draft-boucadair-pcp-failure/ which identified already this issue. I'd prefer to keep pcp-failure informational and concentrate all updates to 6887 in a single small draft. Simon From repenno@cisco.com Wed Jun 12 05:07:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252AA21F9C2A for ; Wed, 12 Jun 2013 05:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMaA11JHGbw7 for ; Wed, 12 Jun 2013 05:07:32 -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 3C58921F9A8A for ; Wed, 12 Jun 2013 05:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=615; q=dns/txt; s=iport; t=1371038852; x=1372248452; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ONVl8zq3uPk2DfErhE8d1bG6oAnKg84OmcAgAbtXurI=; b=gjVlptzAvLB5uRnjtbJlV0ViQFNRBFohVKeUvngCrMSfSWT7SO5q18Yr d+7cEoVsLM7XwrTfrycPq39UPxgC1plslE3WZM1RMt16qaDDXX94GqWsS essbzMxHWEB85m6B7TbG79OdV4+15CQI7DrA1Gyif5aN6SO8+96Zob05d I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAAxkuFGtJV2a/2dsb2JhbABZgwkwSYItvCyBABZ0giUBBAEBAWsLEgEIIksLJQIEAQ0FCIgGDLoAjxIxB4J/YQOIaJABiHOHJoMPgic X-IronPort-AV: E=Sophos;i="4.87,851,1363132800"; d="scan'208";a="221936663" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 12 Jun 2013 12:07:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5CC7VPL006832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 12:07:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 07:07:31 -0500 From: "Reinaldo Penno (repenno)" To: Simon Perreault , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFLhzk+wmJ2FkiifnZjmrMpJJkeQoaAgAAI4QCAAAE5AIAACd0AgBJmUYCAATkIAIAAYNqAgAAJWwCAAAGggP//3YoA Date: Wed, 12 Jun 2013 12:07:30 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A65B8@xmb-rcd-x04.cisco.com> In-Reply-To: <51B85739.2010309@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.78.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 12:07:37 -0000 Right, this kind of update needs to be on a standards track document. On 6/12/13 8:10 AM, "Simon Perreault" wrote: >Le 2013-06-12 13:05, mohamed.boucadair@orange.com a =E9crit : >> IMHO, the nonce text can be included in >>http://datatracker.ietf.org/doc/draft-boucadair-pcp-failure/ which >>identified already this issue. > >I'd prefer to keep pcp-failure informational and concentrate all updates >to 6887 in a single small draft. > >Simon >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From praspati@cisco.com Wed Jun 12 07:47:27 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2721F9BC6 for ; Wed, 12 Jun 2013 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d77LektZ+pq for ; Wed, 12 Jun 2013 07:47:22 -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 179A321F9B8F for ; Wed, 12 Jun 2013 07:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8011; q=dns/txt; s=iport; t=1371048439; x=1372258039; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=PQ4orovs6lRAUO7lBpUMGddar6AftMmtfVQGrah7ACM=; b=FluFypyl4hW/pTjqk3MIxem/dawlFOoQskmjvmFsFnD+DgUsnQkimddX 16YmKVA/ot6+v+QlszsJ9g+lhTZc8/sJ3brJsPvpK2kGm2AwJzsyGNrVR HXRjgrvB0ESFH8nQxHDAJ5uNDSU04R3M3h3j5WtjpENAWFcaURskHnnlc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAIaIuFGtJXG//2dsb2JhbABagkVEMEm2CYhPgQEWdIIlAQR5EgEIIh0oERQRAgQBDQUIh3QDDwyxHw2IUoxigjAxBgGCf2EDlVmDEIp1hSSDD4FqJBk X-IronPort-AV: E=Sophos;i="4.87,852,1363132800"; d="scan'208,217";a="221928251" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 12 Jun 2013 14:47:17 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5CElHBO004755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 14:47:17 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 09:47:16 -0500 From: "Prashanth Patil (praspati)" To: Ben McCann , "Tirumaleswar Reddy (tireddy)" Thread-Topic: [pcp] PCP Proxy Authentication Requirements? Thread-Index: AQHOZ3u6OAc+kkd5lEaHUYuq0ZwZIQ== Date: Wed, 12 Jun 2013 14:47:15 +0000 Message-ID: In-Reply-To: <51B79CB0.3050303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.65.48.173] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE1F113xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Proxy Authentication Requirements? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:47:27 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE1F113xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, Inline.. On 12/06/13 3:24 AM, "Ben McCann" > wrote: Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate= message integrity and that it must be able to ensure message integrity if = it modifies any fields in the message. Doesn't this require authenticating the proxy to the PCP client and server = because the proxy will need separate Security Associations to both the clie= nt and the server? I.e. without knowledge of the EAP Master Session Key, th= e proxy can't modify PCP packets w/o detection so it has to participate in = the authentication process so it can form MSK's for both the client and the= server. (I know, I'm assuming EAP is part of the authentication design). Yes, the proxy has to authenticate with the PCP client and server wit= h separate SAs. Does Req-9 need clarification to note the presence of a proxy requires two = separately authenticated security associations? And, should the requirement= s permit authentication only on one side of the proxy? For example, a custo= mer premises host may not authenticate to the PCP proxy but the proxy may a= uthenticate to the PCP server? Yes, thats possible. We'll update the draft to spell this out more cl= early. -Prashanth On another topic... There was substantial discussion on the list about two major PCP authentica= tion architectures, direct EAP-over-PCP and PANA. I'm still catching up on = the history of PCP authentication so forgive me if this question has been a= sked before. Are either of these protocols currently favored or has that di= scussion been tabled until the requirements are finalized? I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent betwee= n the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't th= ink either of the PANA based approaches for PCP authentication (Side-by-Sid= e or Tunneled) would be interoperable with a PANA relay agent. If a PANA relay is required for a PANA deployment, and PCP was authenticate= d by PANA, then how would the PANA payloads embedded in PCP packets travers= e the PANA relay? This is another area where PANA requires tweaking to supp= ort PCP authentication. IMO, it is preferable to design an EAP transport within PCP because it can = be purpose-built to address the specific requirements of PCP such as the PC= P proxy. (Again, I assume EAP will be part of the PCP authentication protoc= ol). -Ben McCann --_000_B235506D63D65E43B2E40FD27715372E1CE1F113xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Ben,
Inline.. 

On 12/06/13 3:24 AM, "Ben McCann" <bn.mccann@gmail.com> wrote:

Req-9 in draft-reddy-pcp-auth-03 = notes a PCP proxy must be able to validate message integrity and that it mu= st be able to ensure message integrity if it modifies any fields in the mes= sage.

Doesn't this require authenticating the proxy to the PCP client and server = because the proxy will need separate Security Associations to both the clie= nt and the server? I.e. without knowledge of the EAP Master Session Key, th= e proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it= can form MSK's for both the client and the server. (I know, I'm assuming E= AP is part of the authentication design).

<pra> Yes, the proxy has to authenticate with the PCP clien= t and server with separate SAs. 

Does Req-9 need clarification to note the presence of a proxy requires two separately authenti= cated security associations? And, should the requirements permit authentica= tion only on one side of the proxy? For example, a customer premises host m= ay not authenticate to the PCP proxy but the proxy may authenticate to the PCP server?

<p= ra> Yes, thats possible. We'll update the draft to spell this out more c= learly.

=  

-Pras= hanth

On another topic...

There was substantial discussion on the list about two major PCP authentica= tion architectures, direct EAP-over-PCP and PANA. I'm still catching up on= the history of PCP authentication so forgive me if this question has been = asked before. Are either of these protocols currently favored or has that discussion = been tabled until the requirements are finalized?

I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a rel= ay agent between the PANA Client (PaC) and the PANA Authentication Agent (P= AA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would b= e interoperable with a PANA relay agent.

If a PANA relay is required for a PANA deployment, and PCP was authenticate= d by PANA, then how would the PANA payloads embedded in PCP packets travers= e the PANA relay? This is another area where PANA requires tweaking to supp= ort PCP authentication.

IMO, it is preferable to design an EAP transport within PCP because it can = be purpose-built to address the specific requirements of PCP such as the PC= P proxy. (Again, I assume EAP will be part of the PCP authentication protoc= ol).

-Ben McCann

 --_000_B235506D63D65E43B2E40FD27715372E1CE1F113xmbrcdx07ciscoc_-- From praspati@cisco.com Wed Jun 12 08:26:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BED21E8053 for ; Wed, 12 Jun 2013 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.148 X-Spam-Level: X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gh8RvEt042h for ; Wed, 12 Jun 2013 08:26:06 -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 B710F21E804C for ; Wed, 12 Jun 2013 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=132465; q=dns/txt; s=iport; t=1371050764; x=1372260364; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tbpYMom9m2b6FueTBhpBiGBMPjdGXf4IOhTx0Qxh5uI=; b=F8HLUUu/3+o/tvU1smEnxAD8SlBiRD/TP4d9sq4j6zNo8XQSzd6gB64W gLT2qA8kgAyQ5zLsECXNXxPBhbE4yCWcvoSxxKu3ljWPm68AXPLxOJ0cC Z8dVRq09JLMFfPPF1fJ054R8Mx1cqAnVXcoY5WFX80HznpiV2PG3uAQZH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAM+RuFGtJXHA/2dsb2JhbABXA4JFRDBJgnSzA4hPDXUWdIIjAQEBBAwOEz8KAxIBBgIRBAEBCw4IAQYFBDAUCQgCBAENBQgTh3MMjQ2bMQ6RMo8SFhsGAQYLBgGCKzxhA4U+kyuQGYMPgWokGQ X-IronPort-AV: E=Sophos;i="4.87,853,1363132800"; d="scan'208,217";a="221947152" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 12 Jun 2013 15:26:03 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5CFQ3gY017461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 15:26:03 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 10:26:03 -0500 From: "Prashanth Patil (praspati)" To: "yoshihiro.ohba@toshiba.co.jp" , "Tirumaleswar Reddy (tireddy)" , "alper.yegin@yegin.org" Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHOZ4ElH5CsDT4ihUGA5aZ16KNZNA== Date: Wed, 12 Jun 2013 15:26:02 +0000 Message-ID: In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D177C9@tgxml338.toshiba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.65.48.173] Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE1F19Cxmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:26:11 -0000 --_000_B235506D63D65E43B2E40FD27715372E1CE1F19Cxmbrcdx07ciscoc_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 SGkgWW9zaGloaXJvLA0KVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBQQ1AgaW50ZXJpbSBtZWV0 aW5nLiBUaGUgcmVxdWlyZW1lbnQgd2FzIHRoYXQgYW4gYW5vbnltb3VzIGNsaWVudCBpbiBhIG5l dHdvcmsgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBQQ1Agc2VydmVyIGZvciBzZXJ2 aWNlcyB3aXRob3V0IG5lZWRpbmcgdG8gYXV0aGVudGljYXRlLCBidXQgd2l0aCBtZXNzYWdlIGlu dGVncml0eS4NCkZvciBtdXR1YWwgdHJ1c3QgYi93IHRoZSBjbGllbnQgYW5kIHNlcnZlciwgc29t ZSBvZiB0aGUgdGhpbmdzIGRpc2N1c3NlZCB3ZXJlIG9uIHRoZSBsaW5lcyBvZiBkb2luZyBEVExT IHdpdGggd2VsbCBrbm93biBjZXJ0aWZpY2F0ZXMgYW5kIGRlcml2aW5nIGEga2V5IGFzIGEgY29u c2VxdWVuY2UgZm9yIG1lc3NhZ2UgaW50ZWdyaXR5LCBjbGllbnQgb2J0YWlucyBhIGtleSBvdmVy IHNlY3VyZSBESENQIG9yIHN1Y2hsaWtlLg0KDQotUHJhc2hhbnRoDQoNCk9uIDExLzA2LzEzIDQ6 MzYgQU0sICJ5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPG1haWx0bzp5b3NoaWhpcm8ub2hi YUB0b3NoaWJhLmNvLmpwPiIgPHlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8bWFpbHRvOnlv c2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA+PiB3cm90ZToNCg0KSGkgVGlydSwNCg0KSSBkb26h pnQgdW5kZXJzdGFuZCBSRVEtMTQuICAgSG93IGFuIFNBIGNhbiBiZSBzZWN1cmVseSBuZWdvdGlh dGVkIHdpdGhvdXQgYXV0aGVudGljYXRpb24/DQoNCllvc2hpaGlybyBPaGJhDQoNCkZyb206IFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2NvLmNvbV0NClNl bnQ6IFR1ZXNkYXksIEp1bmUgMTEsIDIwMTMgMTI6MzggQU0NClRvOiBBbHBlciBZZWdpbg0KQ2M6 IG9oYmEgeW9zaGloaXJvKKRqs/W4cax2obOi4KLSotGhvKLcouGi2ik7IHBjcEBpZXRmLm9yZzxt YWlsdG86cGNwQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtwY3BdIHBjcCBhdXRoIHJlcXVpcmVt ZW50cw0KDQpUaGUgb3RoZXIgcmVxdWlyZW1lbnQgdGhhdCB3YXMgdXBkYXRlZCBhcyBwYXJ0IG9m IHRoZSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgUENQIGludGVyaW0gbWVldGluZyBpcyBSRVEtMTQs IHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGVyZSBhbnkgY29tbWVudHMgZm9yIHRoaXMgcmVxLg0K NTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1wY3AtYXV0aC1yZXEtMDMj c2VjdGlvbi01Pi4gIE90aGVyIHJlY29tbWVuZGF0aW9ucw0KICAgICAgUkVRLTE0OiBUaGVyZSBT SE9VTEQgYmUgc3VwcG9ydCBmb3IgYSBtZWFucyB0byBwcm92aWRlIGludGVncml0eQ0KICAgICAg cHJvdGVjdGlvbiB3aXRob3V0IHVzZXIgYXV0aGVudGljYXRpb24sIGkuZS4sIGludGVncml0eSBw cm90ZWN0aW9uDQogICAgICBmb3IgUENQIG1lc3NhZ2VzIGV4Y2hhbmdlZCBiZXR3ZWVuIGEgUENQ IHNlcnZlciBhbmQgYW5vbnltb3VzIFBDUA0KICAgICAgY2xpZW50cy4gIEZvciBleGFtcGxlLCBh IGNsaWVudCB2aXNpdGluZyBmb3JlaWduIG5ldHdvcmtzIHN1Y2ggYXMNCiAgICAgIGEgaG90ZWws IGhvdCBzcG90IGV0YyB3aGVyZSB0aGUgY2xpZW50IG1heSBnYWluIGFjY2VzcyB0byB0aGUNCiAg ICAgIG5ldHdvcmsgYnV0IGRvZXMgbm90IGtub3cgdGhlIGNyZWRlbnRpYWxzIHRvIGF1dGhlbnRp Y2F0ZSB3aXRoIHRoZQ0KICAgICAgUENQIHNlcnZlci4NCg0KICAgICAgYS4gIEFuIFNBIE1VU1Qg YmUgbWFkZSBhdmFpbGFibGUgdG8gdGhlIGNsaWVudCBhbmQgc2VydmVyLCB3aGljaA0KICAgICAg ICAgIHdpbGwgYmUgdXNlZCBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgUENQIG1lc3NhZ2Vz LiAgVGhlDQogICAgICAgICAgbmVnb3RpYXRpb24gb2YgU0Egc2hvdWxkIGJlIHNlY3VyZSBzdWNo IHRoYXQgdGhlIFNBIGlzIG9ubHkNCiAgICAgICAgICBrbm93biB0byB0aGUgYW5vbnltb3VzIGNs aWVudCBhbmQgUENQIHNlcnZlci4NCg0KICAgICAgYi4gIEEgUENQIGNsaWVudCBNVVNUIGJlIGFi bGUgdG8gdmFsaWRhdGUgdGhhdCBpdCBpcyBjb21tdW5pY2F0aW5nDQogICAgICAgICAgd2l0aCB0 aGUgZGVzaWduYXRlZCBQQ1Agc2VydmVyIGFuZCBub3QgYW4gYXR0YWNrZXIgcG9zaW5nIGFzIGEN CiAgICAgICAgICBQQ1Agc2VydmVyLg0KDQotLVRpcnUuDQoNCkZyb206IEFscGVyIFllZ2luIFtt YWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnXQ0KU2VudDogVGh1cnNkYXksIE1heSAzMCwgMjAx MyAxMTo0MCBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB5b3NoaWhp cm8ub2hiYUB0b3NoaWJhLmNvLmpwPG1haWx0bzp5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpw PjsgcGNwQGlldGYub3JnPG1haWx0bzpwY3BAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3BjcF0g cGNwIGF1dGggcmVxdWlyZW1lbnRzDQoNClRoaXMgdGV4dCBtYWtlcyBzZW5zZS4NCg0KDQpPbiBN YXkgMjksIDIwMTMsIGF0IDQ6MDkgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3Jv dGU6DQoNClRoYW5rcyBZb3NoaSBmb3IgdGhlIHRleHQgOg0KDQpPTEQgOg0KDQpSRVEtNC0NCg0K ICAgICAgZC4gIElmIHRoZSBzZXJ2ZXIgd2FudHMgdG8gc2VuZCBhbiB1bnNvbGljaXRlZCBtZXNz YWdlLCBidXQgdGhlDQogICAgICAgICAgcHJldmlvdXMgc2VjdXJpdHkgYXNzb2NpYXRpb24gZm9y IHRoZSBtYXBwaW5nDQogICAgICAgICAgaWRlbnRpZmllZCBpbiB0aGUgb3JpZ2luYWwgUENQIHJl cXVlc3QgaGFzIGV4cGlyZWQNCg0KICAgICAgICAgIDEuICBUaGUgc2VydmVyIGNhbiBjb250aW51 ZSB0byB1c2UgdGhlIHNhbWUgU0EgdG8gcHJvdGVjdA0KICAgICAgICAgICAgICBtZXNzYWdlcyBw ZXJ0YWluaW5nIHRvIHRoYXQgbWFwcGluZywgZXZlbiBpZiB0aGUgU0EgaXMNCiAgICAgICAgICAg ICAgdGVjaG5pY2FsbHkgZXhwaXJlZC4NCg0KICAgICAgICAgICAgICAtICBTdWNoIHNlcnZlciBu b3RpZmljYXRpb25zIHdpbGwgbm90IGNoYW5nZSBzdGF0ZSBpbiB0aGUNCiAgICAgICAgICAgICAg ICAgUENQIGNsaWVudC4NCg0KICAgICAgICAgICAgICAtICBUaGUgbm90aWZpY2F0aW9uIGNvdWxk IGJlIGEgdHJpZ2dlciBmb3IgdGhlIGNsaWVudCB0bw0KICAgICAgICAgICAgICAgICByZS1hdXRo ZW50aWNhdGUuICBGb3IgZXhhbXBsZSwgaWYgdGhlIHNlcnZlciBpbmRpY2F0ZXMNCiAgICAgICAg ICAgICAgICAgdGhhdCBleHRlcm5hbCBJUCBhZGRyZXNzL3BvcnQgaGFzIGNoYW5nZWQsIHRoZSBQ Q1ANCiAgICAgICAgICAgICAgICAgY2xpZW50IGNhbiB0aGVuIHJlLWF1dGhlbnRpY2F0ZSB3aXRo IHRoZSBzZXJ2ZXIgdG8NCiAgICAgICAgICAgICAgICAgY29uZmlybSBpZiB0aGUgZXh0ZXJuYWwg SVAgYWRkcmVzcy9wb3J0IGZvciB0aGUgbWFwcGluZw0KICAgICAgICAgICAgICAgICBoYXMgaW5k ZWVkIGNoYW5nZWQuDQoNCiAgICAgICAgICAyLiAgVGhlIHNlcnZlciBNVVNUIGJlIGFibGUgdG8g b3B0aW9uYWxseSB0cmlnZ2VyIHJlLQ0KICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbiB3aXRo IHRoZSBjbGllbnQuDQoNCk5FVyA6DQoNClJFUS00LQ0KDQogICAgICBkLiBUaGUgc2VydmVyIE1V U1QgYmUgYWJsZSB0byB0cmlnZ2VyIGF1dGhlbnRpY2F0aW9uIHdpdGggdGhlIGNsaWVudC4gVGhl IHVuc29saWNpdGVkIG1lc3NhZ2UgZm9yIGF1dGhlbnRpY2F0aW9uIHRyaWdnZXIgTVVTVCBiZSBp bnRlZ3JpdHkgcHJvdGVjdGVkIGlmIHRoZXJlIGlzIHZhbGlkIHVuZXhwaXJlZCBTQS4NCg0KLS1U aXJ1Lg0KRnJvbTogeW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcDxtYWlsdG86eW9zaGloaXJv Lm9oYmFAdG9zaGliYS5jby5qcD4gW21haWx0bzp5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpw XQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjksIDIwMTMgNDo1NyBBTQ0KVG86IGFscGVyLnllZ2lu QHllZ2luLm9yZzxtYWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnPjsgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KQ0KQ2M6IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtwY3BdIHBjcCBhdXRoIHJlcXVpcmVtZW50cw0KDQpPSy4gIFRoZW4gSSBzdWdn ZXN0IGZvcm1pbmcgYSByZXF1aXJlbWVudCB3aXRob3V0IHVzaW5nIHRoZSB0ZXJtIKGncmUtYXV0 aGVudGljYXRpb26hqCwgc29tZXRoaW5nIGxpa2U6DQoNClRoZSBzZXJ2ZXIgTVVTVCBiZSBhYmxl IHRvIHNlbmQgYXV0aGVudGljYXRpb24gdHJpZ2dlciB0byB0aGUgY2xpZW50IHdoZW4gdGhlcmUg aXMgYSBtYXBwaW5nLiAgVGhlIGF1dGhlbnRpY2F0aW9uIHRyaWdnZXIgTVVTVCBiZSBpbnRlZ3Jp dHkgcHJvdGVjdGVkIGlmIHRoZXJlIGlzIGEgU0EuDQoNCllvc2hpaGlybyBPaGJhDQoNCkZyb206 IEFscGVyIFllZ2luIFttYWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnXQ0KU2VudDogV2VkbmVz ZGF5LCBNYXkgMjksIDIwMTMgMTowMyBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeQ0KQ2M6IG9o YmEgeW9zaGloaXJvOyBwY3BAaWV0Zi5vcmc8bWFpbHRvOnBjcEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbcGNwXSBwY3AgYXV0aCByZXF1aXJlbWVudHMNCg0KVGlydSwNCg0KSSBhZ3JlZS4NCg0K QWxwZXINCg0KT24gTWF5IDI4LCAyMDEzLCBhdCAyOjAxIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpIHdyb3RlOg0KDQpIaSBBbHBlciwNCg0KWzFdIHdoZW4gdGhlIFBDUCBzZXJ2ZXIg dHJpZ2dlcnMgcmUtYXV0aGVudGljYXRpb24gYW5kIFNBIGlzIHZhbGlkLCBpZiB0aGUgUENQIGNs aWVudCBkb2VzIG5vdCByZXNwb25kIHRoZW4gcG9zc2libHkgYWZ0ZXIgTiBudW1iZXIgb2YgcmUt dHJpZXMgUENQIHNlcnZlciBtYXkgd2FudCB0byBnaXZlIHVwIGFuZCBjbG9zZSB0aGUgZXhwbGlj aXQgbWFwcGluZ3MgYXNzb2NpYXRlZCB3aXRoIHRoZSB1c2VyLiBUaGlzIHdvdWxkIGhhbmRsZSB0 aGUgc2NlbmFyaW8gd2hlcmUgUENQIGNsaWVudCB3b3VsZCBoYXZlIGNyYXNoZWQgb3IgdGVybWlu YXRlZCBvciBjb25uZWN0aW9uIGxvc3QgZm9yIHNvbWUgcmVhc29uIG9yIHRoZSB1c2VyIGhhcyBs b2dnZWQgb2ZmIGFuZCBzb21lIG90aGVyIHVzZXIgZ290IHRoZSBzYW1lIElQIGFkZHJlc3MgYXMg dGhlIHByZXZpb3VzIHVzZXIuDQoNClsyXSBFdmVuIGluIGNhc2UgMywgd2UgbWF5IHdhbnQgc2lt aWxhciBiZWhhdmlvciBhcyBbMV0uIEZvciBDYXNlIDMsIHRoZXJlIGNvdWxkIGJlIGEgc2NlbmFy aW9zIKFWIHdoZXJlIFBDUCBzZXJ2ZXIgd291bGQgd2FudCB0byBpbmZvcm0gdGhlIFBDUCBjbGll bnQgdGhhdCBleHRlcm5hbCBJUCBhZGRyZXNzL3BvcnQgaGFzIGNoYW5nZWQsIGJ1dCB0aGUgU0Eg aXMgZXhwaXJlZC4gSW4gdGhpcyBjYXNlIFBDUCBzZXJ2ZXIgd291bGQgaGF2ZSB0byB0cmlnZ2Vy IHJlLWF1dGguIElmIHJlLWF1dGggaXMgc3VjY2Vzc2Z1bCB0aGVuIHNlbmQgdGhlIG1hcHBpbmcg dXBkYXRlIG9yIGlmIHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZyb20gdGhlIGNsaWVudCB0aGVuIHBy b2NlZWQgd2l0aCBkZWxldGluZyB0aGUgZXhwbGljaXQgbWFwcGluZ3MgYWZ0ZXIgTiBudW1iZXIg b2YgdHJpZXMuDQoNCkNhc2UgMyBjb3VsZCBiZSBhbiBvcHRpbWl6YXRpb24gdG8gdHJpZ2dlciBy ZS1hdXRoZW50aWNhdGlvbiBvbmx5IHdoZW4gdGhlcmUgaXMgaW50ZXJlc3RpbmcgdXBkYXRlIHRv IGJlIHNlbnQgZnJvbSB0aGUgY2xpZW50IG9yIHNlcnZlciBhbmQgbm90IHRvIHRyaWdnZXIgcmUt YXV0aGVudGljYXRpb24gYmVmb3JlIFNBIGV4cGlyZXMgLg0KDQotLVRpcnUuDQpGcm9tOiBBbHBl ciBZZWdpbiBbbWFpbHRvOmFscGVyLnllZ2luQHllZ2luLm9yZ10NClNlbnQ6IFRodXJzZGF5LCBN YXkgMjMsIDIwMTMgMTI6MTcgUE0NClRvOiB5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPG1h aWx0bzp5b3NoaWhpcm8ub2hiYUB0b3NoaWJhLmNvLmpwPg0KQ2M6IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSk7IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtwY3BdIHBjcCBhdXRoIHJlcXVpcmVtZW50cw0KDQpZb3NoaSwNCg0KWW91IGFyZSByaWdo dC4gSW4gdGVybXMgb2YgRUFQIGFuZCBSRkMgNTI0Nywgb25seSB0aGUgc2Vjb25kIGNhc2UgcXVh bGlmaWVzIGZvciAiRUFQIHJlLWF1dGhlbnRpY2F0aW9uIi4NCg0KT24gdGhlIG90aGVyIGhhbmQs IGZpcnN0IGFuZCB0aGlyZCBjYXNlIGFyZSBub3QgdGhlIHNhbWUuDQpBbmQgSSdkIGNvbmNlcHR1 YWxseSB0aGluayBvZiB0aGUgdGhpcmQgY2FzZSBhcyBhIHNvbWUgc29ydCBvZiAicmUtYXV0aGVu dGljYXRpb24iIChhcHBhcmVudGx5IG5vdCBhbiAiRUFQIHJlLWF1dGhlbnRpY2F0aW9uIiBwZXIg UkZDIDUyNDcpLg0KDQpBbnl3YXlzLCBhdCBsZWFzdCBJJ2QgbGlrZSBwZW9wbGUgdG8gYmUgYXdh cmUgb2YgdGhlc2UgdGhyZWUgZGlmZmVyZW50IGNhc2VzIC0tIGV2ZW4gaWYgd2UgY2Fubm90IGZp bmQgYSBwcm9wZXIgbmFtZSB0byBhbGwgb2YgdGhlbS4NCg0KQWxwZXINCg0KDQoNCk9uIE1heSAy MywgMjAxMywgYXQgMTozOSBBTSwgPHlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8bWFpbHRv Onlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA+PiB3cm90ZToNCg0KDQpIaSBBbHBlciwNCg0K V2hlbiB3ZSB0YWxrIGFib3V0IHJlLWF1dGhlbnRpY2F0aW9uLCB3ZSBzaG91bGQgbm90IGNhcmUg YWJvdXQgd2hldGhlciB0aGVyZSBpcyBhIFBDUCBzZXNzaW9uIG9yIG5vdC4NCg0KUGxlYXNlIHNl ZSB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gaW4gUkZDIDUyNDc6DQqhpw0KICAgRUFQIFJlLUF1 dGhlbnRpY2F0aW9uDQogICAgICBFQVAgYXV0aGVudGljYXRpb24gYmV0d2VlbiBhbiBFQVAgcGVl ciBhbmQgYSBzZXJ2ZXIgd2l0aCB3aG9tIHRoZQ0KICAgICAgRUFQIHBlZXIgc2hhcmVzIHZhbGlk IHVuZXhwaXJlZCBFQVAga2V5aW5nIG1hdGVyaWFsLg0KoacNCg0KQWNjb3JkaW5nIHRvIHRoZSBh Ym92ZSBkZWZpbml0aW9uLCBpZiBhdXRoZW50aWNhdGlvbiBpcyBjb25kdWN0ZWQgb3ZlciBhIGxp dmUgU0EsIGl0IGlzIHJlLWF1dGhlbnRpY2F0aW9uLCBvdGhlcndpc2UgaXQgaXMgbm90IHJlLWF1 dGhlbnRpY2F0aW9uLg0KDQpZb3NoaWhpcm8gT2hiYQ0KDQoNCkZyb206IEFscGVyIFllZ2luIFtt YWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnXQ0KU2VudDogVGh1cnNkYXksIE1heSAyMywgMjAx MyA2OjE2IEFNDQpUbzogb2hiYSB5b3NoaWhpcm8NCkNjOiB0aXJlZGR5QGNpc2NvLmNvbTxtYWls dG86dGlyZWRkeUBjaXNjby5jb20+OyBwY3BAaWV0Zi5vcmc8bWFpbHRvOnBjcEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbcGNwXSBwY3AgYXV0aCByZXF1aXJlbWVudHMNCg0KSGkgWW9zaGksDQoN CkhlcmUgYXJlIHRoZSB0aHJlZSBzdGF0ZXM6DQoNCjAuIEJlZm9yZSBQQ1AgY2xpZW50IGFuZCBQ Q1Agc2VydmVyIGhhcyBpbml0aWF0ZWQgUENQIHNlc3Npb24uDQoNCjEuIFRoZXJlIGlzIGEgUENQ IHNlc3Npb24gYW5kIGEgbGl2ZSBTQS4NCg0KMi4gVGhlcmUgaXMgYSBQQ1Agc2Vzc2lvbiwgYnV0 IG5vIGxpdmUgU0EgKGkuZS4sIHRoZSBsYXN0IHVzZWQgU0EgaXMgYWxyZWFkeSBleHBpcmVkKS4N Cg0KDQpJZiB3ZSBleGVjdXRlIGF1dGggaW4gc3RhdGUgMCwgd2UgY2FsbCBpdCAiKGluaXRpYWwp IGF1dGhlbnRpY2F0aW9uIi4NCkF1dGggZXhlY3V0ZWQgaW4gc3RhdGUgMSBpcyBjYWxsZWQgInJl LWF1dGhlbnRpY2FpdG9uIi4NCkknZCBjYWxsIGF1dGggZXhlY3V0ZWQgaW4gc3RhdGUgMiBhICJy ZS1hdXRoZW50aWNhdGlvbiIgYXMgd2VsbCwgdW5sZXNzIHdlIHdhbnQgdG8gZ2l2ZSBpdCBhIG1v cmUgc3BlY2lmaWMgbmFtZS4NCg0KQWxwZXINCg0KDQoNCg0KT24gTWF5IDIyLCAyMDEzLCBhdCAx MToxNiBBTSwgPHlvc2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8bWFpbHRvOnlvc2hpaGlyby5v aGJhQHRvc2hpYmEuY28uanA+PiB3cm90ZToNCg0KDQoNCkhpIEFscGVyLA0KDQpJIGFncmVlIHRo YXQgd2Ugc2hvdWxkIGFsbG93IHVucHJvdGVjdGVkIGF1dGhlbnRpY2F0aW9uIHRyaWdnZXIgZnJv bSB0aGUgc2VydmVyLCBidXQgd2Ugc2hvdWxkIGRpc3Rpbmd1aXNoIGF1dGhlbnRpY2F0aW9uIGFm dGVyIGV4cGlyYXRpb24gb2YgU0EgZnJvbSChp3JlLWF1dGhlbnRpY2F0aW9uoaguDQoNCllvc2hp aGlybyBPaGJhDQoNCkZyb206IEFscGVyIFllZ2luIFttYWlsdG86YWxwZXIueWVnaW5AeWVnaW4u b3JnXQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgNDoyMiBQTQ0KVG86IG9oYmEgeW9z aGloaXJvDQpDYzogdGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPjsg cGNwQGlldGYub3JnPG1haWx0bzpwY3BAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3BjcF0gcGNw IGF1dGggcmVxdWlyZW1lbnRzDQoNCg0KT24gTWF5IDIxLCAyMDEzLCBhdCAxMDoxNCBBTSwgPHlv c2hpaGlyby5vaGJhQHRvc2hpYmEuY28uanA8bWFpbHRvOnlvc2hpaGlyby5vaGJhQHRvc2hpYmEu Y28uanA+PiA8eW9zaGloaXJvLm9oYmFAdG9zaGliYS5jby5qcDxtYWlsdG86eW9zaGloaXJvLm9o YmFAdG9zaGliYS5jby5qcD4+IHdyb3RlOg0KDQoNCg0KDQpUaXJ1LA0KDQpJbiBteSBhbmFseXNp cywgUmVxLTQtZC0xIGlzIGJhc2ljYWxseSBpbnRyb2R1Y2luZyBhIHRocmVlLXN0YXRlIFNBIG1v ZGVsIGZvciBQQ1A6IFN0YXRlIDA6ICB1bmF2YWlsYWJsZSAob3Igbm9uLWV4aXN0ZW50KSwgU3Rh dGUgMTogcGFydGlhbGx5IGF2YWlsYWJsZSBvbmx5IGZvciB0cmlnZ2VyaW5nIHJlLWF1dGgsIGFu ZCBTdGF0ZSAyOiBmdWxseSBhdmFpbGFibGUuIE1TQ0hBUHYyIHBhc3N3b3JkIGNoYW5nZSBmdW5j dGlvbiBpcyBkZXNpZ25lZCBiYXNlZCBvbiB0aGlzIG1vZGVsLg0KDQpJIGFtIG5vdCBnb2luZyB0 byBnZXQgaW50byBkZXRhaWxzIGFib3V0IHRoZSB0aHJlZS1zdGF0ZSBTQSBtb2RlbCwgYnV0IGV2 ZW4gdGhlIHRocmVlLXN0YXRlIFNBIG1vZGVsIHdpbGwgcmVxdWlyZSByZS1hdXRoIHRyaWdnZXIg dG8gYmUgaW50ZWdyaXR5IHByb3RlY3RlZC4NCg0KSGF2aW5nIHNhaWQgdGhhdCwgSSB0aGluayB0 aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50IGlzIHN1ZmZpY2llbnQgZm9yIFJlcS00LWQ6IKGnVGhl IHNlcnZlciBNVVNUIGJlIGFibGUgdG8gc2VuZCBhbiBpbnRlZ3JpdHkgcHJvdGVjdGVkIHJlLWF1 dGhlbnRpY2F0aW9uIHRyaWdnZXIgdG8gdGhlIGNsaWVudC6hqA0KDQoNCklmIHRoZXJlIGlzIG5v IFNBIGF2YWlsYWJsZSwgdGhlbiB0aGUgc2VydmVyIGNhbiBzZW5kIGFuIHVuLXByb3RlY3RlZCBy ZS1hdXRoIHRyaWdnZXIuIFdlIHNob3VsZCBhbGxvdyB0aGF0Lg0KVGhpcyBpcyBlcXVpdmFsZW50 IHRvIHdoYXQgaGFwcGVucyBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgYmVmb3JlIHRoZSB2ZXJ5IGZp cnN0IGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NCg0K QWxwZXINCg0KDQoNCg0KDQoNCg0KUmVnYXJkcywNCllvc2hpaGlybyBPaGJhDQoNCg0KRnJvbTog cGNwLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv OnBjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KQ0KU2VudDogU3VuZGF5LCBNYXkgMTksIDIwMTMgMjoyNCBBTQ0KVG86IEFscGVyIFll Z2luOyBwY3BAaWV0Zi5vcmc8bWFpbHRvOnBjcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcGNw XSBwY3AgYXV0aCByZXF1aXJlbWVudHMNCg0KSGkgQWxwZXIsDQoNClBsZWFzZSBzZWUgaW5saW5l IFtUUl0NCg0KRnJvbTogQWxwZXIgWWVnaW4gW21haWx0bzphbHBlci55ZWdpbkB5ZWdpbi5vcmdd DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAzMCwgMjAxMyAxMjo1MyBQTQ0KVG86IHBjcEBpZXRmLm9y ZzxtYWlsdG86cGNwQGlldGYub3JnPg0KU3ViamVjdDogW3BjcF0gcGNwIGF1dGggcmVxdWlyZW1l bnRzDQoNCg0KDQoNCiAgICAgIGMuICBJZiBhIHNlcnZlciB3YW50cyB0byBzZW5kIGFuIHVuc29s aWNpdGVkIG1lc3NhZ2UsIGJ1dCB0aGUNCg0KICAgICAgICAgIHByZXZpb3VzIHNlY3VyaXR5IGFz c29jaWF0aW9uIGhhcyBleHBpcmVkDQoNCg0KDQogICAgICAgICAgMS4gIFRoZSBzZXJ2ZXIgY2Fu IGNvbnRpbnVlIHRvIHVzZSB0aGUgc2FtZSBTQSB0byBwcm90ZWN0DQoNCiAgICAgICAgICAgICAg bWVzc2FnZXMgcGVydGFpbmluZyB0byB0aGF0IG1hcHBpbmcsIGV2ZW4gaWYgdGhlIFNBIGlzDQoN CiAgICAgICAgICAgICAgdGVjaG5pY2FsbHkgZXhwaXJlZC4NCg0KDQoiRXhwaXJlZCIgbWVhbnMg ImRvIG5vdCB1c2UgKGV2ZW4gaWYgaXRzIHN0aWxsIGhhbmdpbmcgYXJvdW5kKSIuDQoNCldlIG5v dCBvbmx5IGRvIG5vdCBuZWVkIHRvIHVzZSBleHBpcmVkIFNBcywgYnV0IGFsc28gdXNpbmcgc29t ZXRoaW5nIGV4cGlyZWQgaW4gYW55IHNlbnNlIGlzIHBsYWluIHdyb25nIC0tIHVubGVzcyBzb21l b25lIHdhbnRzIHRvIHJlZGVmaW5lIHdoYXQgImV4cGlyZWQiIG1lYW5zLg0KDQoNCg0KW1RSXQ0K DQpGb3IgZXhhbXBsZSBpZiB3ZSBjb25zaWRlciBNU0NIQVB2MiwgdGhlcmUgaXMgY29uZmlndXJh dGlvbiBvcHRpb24gd2hlcmUgc2VydmVyIGFjY2VwdHMgdGhlIGNoYWxsZW5nZS1yZXNwb25zZSBm cm9tIHRoZSBjbGllbnQgZXZlbiBpZiB0aGUgcGFzc3dvcmQgaXMgZXhwaXJlZCBhbmQgYWxsb3dz IGl0IGJlIGNoYW5nZWQuDQoNCg0KDQpQbGVhc2UgY2xhcmlmeSBpZiB5b3UgaGF2ZSBzb21lIGF0 dGFjayBpbiBtaW5kIHRoYXQgd291bGQgY2F1c2UgcHJvYmxlbXMgdXNpbmcgZXhwaXJlZCBTQS4N Cg0KDQoNClsvVFJdDQoNCg0KDQogICAgICAgICAgICAgIC0gIFN1Y2ggc2VydmVyIG5vdGlmaWNh dGlvbnMgd2lsbCBub3QgY2hhbmdlIHN0YXRlIGluIHRoZQ0KDQogICAgICAgICAgICAgICAgIFBD UCBjbGllbnQuDQoNCg0KDQogICAgICAgICAgICAgIC0gIFRoZSBub3RpZmljYXRpb24gY291bGQg YmUgYSB0cmlnZ2VyIGZvciB0aGUgY2xpZW50IHRvDQoNCiAgICAgICAgICAgICAgICAgcmUtYXV0 aGVudGljYXRlLg0KDQoNCkhlcmUgdGhlIGRvY3VtZW50IGlzIGdldHRpbmcgaW50byBzb21lIHNv bHV0aW9uIGRlc2NyaXB0aW9uLg0KDQoNCkFuZCBhcyBmb3Igc3VjaCBhIHNvbHV0aW9uOg0KDQoN Ckluc3RlYWQgb2Ygc2VuZGluZyBhIG5vdGlmaWNhdGlvbiB0aGF0IGlzIHByb3RlY3RlZCB3aXRo IGFuIGV4cGlyZWQgU0EgdG8gbWVhbiAicmUtYXV0aGVudGljYXRlIiwgd2h5IG5vdCBzZW5kIGFu IGV4cGxpY2l0IG1lc3NhZ2UgdGhhdCBzYXlzICJyZS1hdXRoZW50aWNhdGUiPw0KDQoNCg0KW1RS XQ0KDQpUaGUgY2xpZW50IGhhcyB0cnVzdGVkIHRoZSBQQ1Agc2VydmVyIHNvbWV0aW1lIGJhY2sg dXNpbmcgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBzbyBpdCBjYW4gYXNzdW1lIHRoZSBpbnRlZ3Jp dHkgcHJvdGVjdGVkIFBDUCByZXNwb25zZSB1c2luZyBleHBpcmVkIFNBIGlzIGNvbWluZyBmcm9t IHRoZSBzYW1lIFBDUCBzZXJ2ZXIgYW5kIG5vdCBmcm9tIHNvbWUgYXR0YWNrZXIgcG9zaW5nIGFz IFBDUCBzZXJ2ZXIuDQoNClsvVFJdDQoNCg0KDQpXaGF0IGlzIGdhaW5lZCBieSBhcHBlYXJpbmcg dG8gdXNlIGFuIGV4cGlyZWQgU0EgKGJ1dCBpbiBmYWN0IG5vdCByZWFsbHkgdXNpbmcgaXQhIGJl Y2F1c2UgdGhlIHBheWxvYWQgb2YgdGhlIG5vdGlmaWNhdGlvbiBpcyBub3QgY29uc3VtZWQgYnkg dGhlIHJlY2VpdmVyKS4NCg0KDQoNCiAgICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIGlmIHRo ZSBzZXJ2ZXIgaW5kaWNhdGVzDQoNCiAgICAgICAgICAgICAgICAgdGhhdCBleHRlcm5hbCBJUCBh ZGRyZXNzL3BvcnQgaGFzIGNoYW5nZWQsIHRoZSBQQ1ANCg0KICAgICAgICAgICAgICAgICBjbGll bnQgY2FuIHRoZW4gcmUtYXV0aGVudGljYXRlIHdpdGggdGhlIHNlcnZlciB0bw0KDQogICAgICAg ICAgICAgICAgIGNvbmZpcm0gaWYgdGhlIGV4dGVybmFsIElQIGFkZHJlc3MvcG9ydCBmb3IgdGhl IG1hcHBpbmcNCg0KICAgICAgICAgICAgICAgICBoYXMgaW5kZWVkIGNoYW5nZWQuDQoNCg0KDQog ICAgICAgICAgMi4gIFRoZSBzZXJ2ZXIgY2FuIG9wdGlvbmFsbHkgdHJpZ2dlciByZS1hdXRoZW50 aWNhdGlvbiB3aXRoDQoNCiAgICAgICAgICAgICAgdGhlIGNsaWVudC4NCg0KDQpZZXMsIHRoYXQn cyB0aGUgc29sdXRpb24uIElmIHRoZSBzZXJ2ZXIgaGFzIHNvbWV0aGluZyB0byBzZW5kIHRvIHRo ZSBjbGllbnQsIGFuZCB0aGVyZSdzIG5vIGxpdmUgU0EsIHRoZW4gdGhlIHNlcnZlciBmaXJzdCBu ZWVkcyB0byB0cmlnZ2VyIHJlLWF1dGgsIHNldHVwIGEgZnJlc2ggU0EsIHRoZW4gc2VuZCB3aGF0 ZXZlciBpdCB3YW50cyB0byBzZW5kIHRvIHRoZSBjbGllbnQuDQoNCg0KW1RSXQ0KDQoNCg0KV2Ug aGF2ZSB1cGRhdGVkIHRoaXMgcmVxdWlyZW1lbnQgaW4gdGhlIG5ldyBkcmFmdCwgcGxlYXNlIGhh dmUgYSBsb29rLg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQotLVRpcnUuDQoNCg0KDQpbL1RSXQ0K DQoNCkFscGVyDQoNCg0KDQoNCg== --_000_B235506D63D65E43B2E40FD27715372E1CE1F19Cxmbrcdx07ciscoc_ Content-Type: text/html; charset="big5" Content-ID: <22566459A673DA4F8CAB69ACFCD65C7D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Yoshihiro,

This was discussed in the PCP interim meeting. The requirement was= that an anonymous client in a network be able to communicate with the PCP = server for services without needing to authenticate, but with message integrity.

For mutual trust b/w the client and server, some of the things dis= cussed were on the lines of doing DTLS with well known certificates and der= iving a key as a consequence for message integrity, client obtains a key over secure DHCP or suchlike.


-Prashanth



Hi Tiru,

 

I don=A1=A6t understa= nd REQ-14.   How an SA can be securely negotiated without authent= ication?

 

Yoshihiro Ohba

 

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco= .com]
Sent: Tuesday, June 11, 2013 12:38 AM
To: Alper Yegin
Cc: ohba yoshihiro(=A4j=B3=F5=B8q=ACv=A1=B3=A2=E0=A2=D2=A2=D1<= span lang=3D"EN-US" style=3D"font-size: 10pt; font-family: Tahoma, sans-ser= if; ">=A1=BC=A2=DC=A2=E1=A2=DA); pcp@ietf.org
Subject: RE: [pcp] pcp auth requirements

 

The other requirement that was updated= as part of the discussion during the PCP interim meeting is REQ-14, would like to know if there any comments for th= is req.

5.  Other recommendations

&n= bsp;     REQ-14: There SHOULD be support for a means to= provide integrity

&n= bsp;     protection without user authentication, i.e., = integrity protection

&n= bsp;     for PCP messages exchanged between a PCP serve= r and anonymous PCP

&n= bsp;     clients.  For example, a client visiting = foreign networks such as

&n= bsp;     a hotel, hot spot etc where the client may gai= n access to the

&n= bsp;     network but does not know the credentials to a= uthenticate with the

&n= bsp;     PCP server.

 

&n= bsp;     a.  An SA MUST be made available to the c= lient and server, which

&n= bsp;         will be used for integ= rity protection of PCP messages.  The

&n= bsp;         negotiation of SA shou= ld be secure such that the SA is only

&n= bsp;         known to the anonymous= client and PCP server.

 

&n= bsp;     b.  A PCP client MUST be able to validate= that it is communicating

&n= bsp;         with the designated PC= P server and not an attacker posing as a

&n= bsp;         PCP server.=

 

--Tiru.

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg]
Sent: Thursday, May 30, 2013 11:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: yoshihiro.ohba@t= oshiba.co.jp; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

 

This text makes sense.

 

 

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

 

Thanks Yoshi for the text :

 

OLD :

 

REQ-4-

 

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

       =    previous security association for the mapping

       =    identified in the original PCP request has expired=

 

       =    1.  The server can continue to use the same SA to protect= <= /o:p>

       =        messages pertaining to that mapping, e= ven if the SA is

       =        technically expired.

 

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

       =           PCP client.

 

       =        -  The notification could be a tr= igger for the client to

       =           re-authenticate.&nbs= p; For example, if the server indicates

       =           that external IP add= ress/port has changed, the PCP

       =           client can then re-a= uthenticate with the server to

       =           confirm if the exter= nal IP address/port for the mapping

       =           has indeed changed.<= /span>

 

       =    2.  The server MUST be able to optionally trigger re-

       =        authentication with the client.=

 

NEW :

 

REQ-4-

 

      d. The serv= er MUST be able to trigger authentication with the client. The unsolicited = message for authentication trigger MUST be integrity protected if there is valid unexpired SA. 

 

--Tiru.

From:=  = yoshihiro.ohba@toshiba.co.jp [mailto:yoshihiro.ohba@tos= hiba.co.jp] 
Sent: Wednesday, M= ay 29, 2013 4:57 AM
To: alper.yegin@yegin.org; Tirumaleswar Reddy (t= ireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

OK.  Then I suggest forming a requi= rement without using the term =A1=A7re-authentication=A1=A8, something like:

 

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

 

Yoshihiro Ohba

 

From:=  Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, M= ay 29, 2013 1:03 AM
To: Tirumaleswar R= eddy
Cc: ohba yoshihiro= ; pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Tiru,

 

I agree.<= o:p>

 

Alper

 

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

 

Hi Alper,

 

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

 

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

 

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

 

--Tiru.

From:=  Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Thursday, Ma= y 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar R= eddy (tireddy); pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Yoshi,

 

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

 

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

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

 

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

 

Alper

 

 

 

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



<= /o:p>

Hi Alper,

 

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

 

Please see the following definition in R= FC 5247:

=A1=A7

   EAP Re-Authentication<= /span>

      EAP authe= ntication between an EAP peer and a server with whom the

      EAP peer = shares valid unexpired EAP keying material.

=A1=A7

 

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

 

Yoshihiro Ohba

 

 

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

 

Hi Yoshi,

 

Here are the three states:

 

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

 

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

 

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

 

 

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

Auth executed in state 1 is called "re-authentic= aiton".

I'd call auth executed in state 2 a "re-authenti= cation" as well, unless we want to give it a more specific name.<= /span>

 

Alper

 

 

 

 

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




<= /o:p>

Hi Alper,

 

I agree that we should allow unprotected= authentication trigger from the server, but we should distinguish authentication after expiration of SA from =A1= =A7re-authentication=A1=A8.

 

Yoshihiro Ohba

 

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

 

 

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





<= /o:p>

Tiru,

 

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

 

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

 

Having said that, I think the following = requirement is sufficient for Req-4-d: =A1= =A7The server MUST be able to send an integrity protected re-authentication trigg= er to the client.=A1=A8

 

 

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

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

 

Alper

 

 

 





<= /o:p>

Regards,

Yoshihiro Ohba

 

 

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

 

Hi Alper,

 

Please see inline [TR]

 

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

 



 
    &nbs=
p; c.  If a server wants to send an unsolicited message, but the<=
/o:p>
&n=
bsp;         previous security asso=
ciation has expired
&n=
bsp;
&n=
bsp;         1.  The server ca=
n continue to use the same SA to protect
&n=
bsp;            =
; messages pertaining to that mapping, even if the SA is
&n=
bsp;            =
; technically expired.

 
"Expired" means &q=
uot;do not use (even if its still hanging around)". 
We not only do not need to u=
se expired SAs, but also using something expired in any sense is plain wron=
g -- unless someone wants to redefine what "expired" means.<=
/o:p>
&n=
bsp;
[T=
R]
Fo=
r example if we consider MSCHAPv2, there is configuration option where serv=
er accepts the challenge-response from the client even if the password is e=
xpired and allows it be changed. 
&n=
bsp;
Pl=
ease clarify if you have some attack in mind that would cause problems usin=
g expired SA.
&n=
bsp;
[/=
TR]
&n=
bsp;
    &nbs=
p;         -  Such server noti=
fications will not change state in the
&n=
bsp;            =
;    PCP client.
&n=
bsp;
&n=
bsp;            =
; -  The notification could be a trigger for the client to<=
/span>
&n=
bsp;            =
;    re-authenticate.  

 
Here the document is getting=
 into some solution description.

 
And as for such a solution:<=
/span><=
o:p>

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






    &nbs=
p;            For ex=
ample, if the server indicates


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



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



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



&n=
bsp;            =
;    has indeed changed.


&n=
bsp;


&n=
bsp;         2.  The server ca=
n optionally trigger re-authentication with


&n=
bsp;            =
; the client.














 


























 


























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






















 












[T=
R]


&n=
bsp;


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



&n=
bsp;


Be=
st Regards,


--=
Tiru.


&n=
bsp;


[/=
TR]












 


























 


























Alper


























 


























 


























 

 

--_000_B235506D63D65E43B2E40FD27715372E1CE1F19Cxmbrcdx07ciscoc_-- From Ted.Lemon@nominum.com Wed Jun 12 08:42:02 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065E521F99C9 for ; Wed, 12 Jun 2013 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbHnB6MYolun for ; Wed, 12 Jun 2013 08:41:55 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 14C1821E805E for ; Wed, 12 Jun 2013 08:41:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUbiWwaszlE6yWbNzv81dKdZg8k5hyHjD@postini.com; Wed, 12 Jun 2013 08:41:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8B1601B81D0 for ; Wed, 12 Jun 2013 08:41:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8286619005D; Wed, 12 Jun 2013 08:41:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 08:41:53 -0700 From: Ted Lemon To: "Prashanth Patil (praspati)" Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOJ+mcGknPzdUqous5Dz9jpmpkLw0oAgAQMxQCAAZSbgIAADysAgADZvgCAABdggIAAiEeAgAgiqwCAAFQeAIAAfECAgADlwoCAARz1gIAR6GAAgAB9ZoCAAqP8AIAABG6A Date: Wed, 12 Jun 2013 15:41:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D33B7@mbx-01.win.nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="big5" Content-ID: <01DBC46CD7DC1244B062EC331E305DDA@nominum.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" , "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:42:02 -0000 T24gSnVuIDEyLCAyMDEzLCBhdCAxMToyNiBBTSwgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkg PHByYXNwYXRpQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEZvciBtdXR1YWwgdHJ1c3QgYi93IHRoZSBj bGllbnQgYW5kIHNlcnZlciwgc29tZSBvZiB0aGUgdGhpbmdzIGRpc2N1c3NlZCB3ZXJlIG9uIHRo ZSBsaW5lcyBvZiBkb2luZyBEVExTIHdpdGggd2VsbCBrbm93biBjZXJ0aWZpY2F0ZXMgYW5kIGRl cml2aW5nIGEga2V5IGFzIGEgY29uc2VxdWVuY2UgZm9yIG1lc3NhZ2UgaW50ZWdyaXR5LCBjbGll bnQgb2J0YWlucyBhIGtleSBvdmVyIHNlY3VyZSBESENQIG9yIHN1Y2hsaWtlLg0KDQoic2VjdXJl IERIQ1AiPw0KDQpUaGVyZSBpcyBubyBjb25maWRlbnRpYWxpdHktcHJvdmlkaW5nIHNlY3VyaXR5 IG1lY2hhbmlzbSBmb3IgREhDUCwgc28gSSB0aGluayB5b3UgbmVlZCB0byBleHBsYWluIHdoYXQg Im9yIHN1Y2hsaWtlIiBpcy4gICA6KQ0KDQpJZiB5b3UganVzdCBtZWFuIHRvIHZhbGlkYXRlIHRo ZSBwdWJsaWMga2V5IHVzaW5nIHNlY3VyZSBESENQLCBiZWFyIGluIG1pbmQgdGhhdCB5b3UndmUg anVzdCBwdXNoZWQgdGhlIGtleSBwcm92aXNpb25pbmcgcHJvYmxlbSBmcm9tIFBDUCB0byBESENQ LCBhbmQgdGhhdCB0aGVyZSBpcyBubyB3aWRlbHktaW1wbGVtZW50ZWQga2V5IHByb3Zpc2lvbmlu ZyBzb2x1dGlvbiBmb3IgREhDUCBlaXRoZXIuDQoNCg== From cheshire@apple.com Wed Jun 12 11:32:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BA11E80CC for ; Wed, 12 Jun 2013 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyYUlpzl5zoS for ; Wed, 12 Jun 2013 11:32:48 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0211E80EE for ; Wed, 12 Jun 2013 11:32:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOA000DUM695Y80@mail-out.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 11:32:47 -0700 (PDT) X-AuditID: 11807153-b7f3c6d000007b32-2b-51b8becf5707 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 4B.DB.31538.FCEB8B15; Wed, 12 Jun 2013 11:32:47 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOA00KH9M6NSW40@spicerack.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 11:32:47 -0700 (PDT) From: Stuart Cheshire In-reply-to: <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 12 Jun 2013 11:32:47 -0700 Message-id: <66451318-8D44-4462-91A7-FD28461349E2@apple.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FCsoXt+345Ag93TlCwmH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLlXV7EWXOOo6Jn5gLGB8R9bFyMHh4SAicTB/uwuRk4gU0zi wr31QGEuDiGByUwSc6b+hHJWMEl8mnCUHaSKWUBHovf7N2YQm1dAT2Lb3G1sILawgLbE29u3 wGrYBLQkXny+AhbnFIiT6Jw2BayeRUBVoq/nETPEHG2JJ+8usELMsZGYvXIHI8Syq6wSzy/M BisSEVCUOLDtBjvEebISr5+/YZnAyD8LyR2zkNwxC8ncBYzMqxgFilJzEiuN9RILCnJS9ZLz czcxgkOsMHgH459lVocYBTgYlXh4JzTvCBRiTSwrrsw9xCjBwawkwuswASjEm5JYWZValB9f VJqTWnyIUZqDRUmcN7h6W6CQQHpiSWp2ampBahFMlomDU6qBsWqjpsdNgS+BGmaXbZO3BX7b 5KN2dJNu8rdGV/Z3wt/OvmXKWXu+9Yra1vmNOxanCXC9elP2cmrJ5jl/xXed9MvnCti048a/ hKfNTJEzTGawdkYz/r5wpcBrF2NdnynDrAaelPzqY6xn56v2iuTusbva3vBe5sSFIJ6tYo7q hzNX3Li8xz+xRYmlOCPRUIu5qDgRADxPhHMtAgAA Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:32:54 -0000 On 12 Jun, 2013, at 01:31, mohamed.boucadair@orange.com wrote: > Stuart, > > We are approaching the problem with two different perspectives: > * You are more concerned about "poor" PCP client implementations > * I'm more concerned about how a client can get connectivity and how the server can help in maximizing the chance to honor a request > > I understand your concern but defining a new error code will create a new connectivity failure case if the client does not try another request with the adjusted Suggested External IP Address. But what are the guarantees a "poor" implementation will try another adjusted request? Because the *human* writing the code cannot avoid noticing that their code doesn't work, so they will fix it. What makes you think that a "poor" implementation, that today only handles one address family, will somehow spontaneously grow a new piece of code, in the field, two years from now, which enables it to correctly handle replies containing the other address family that it currently knows nothing about? Stuart Cheshire From cheshire@apple.com Wed Jun 12 11:43:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E91711E80EF for ; Wed, 12 Jun 2013 11:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-VAUF4FNWyw for ; Wed, 12 Jun 2013 11:43:39 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id A7E7911E80E8 for ; Wed, 12 Jun 2013 11:43:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOA00935MNI3ZG0@mail-out.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 11:43:29 -0700 (PDT) X-AuditID: 11807158-b7f486d0000079b6-d3-51b8c1502338 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 11.50.31158.051C8B15; Wed, 12 Jun 2013 11:43:29 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOA00KPSMOGSW40@spicerack.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 11:43:28 -0700 (PDT) From: Stuart Cheshire Message-id: <0EB908DE-BB6E-4136-B6DD-BC1C137E87D3@apple.com> Date: Wed, 12 Jun 2013 11:43:28 -0700 To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42IRbCjW0A08uCPQYFKpxeRjv1kdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXx4VYTY8E/pooTb7cwNzBuZupi5OSQEDCRmNF7DMoWk7hwbz1b FyMXh5DAZCaJHcc2s0A4K5gklty8xAJSxSagJfHi8xU2EJsZyF6/8zgThK0t8eTdBVYQW1jA SmLxvqPMIDavgI3EvpVbgeo5OFgEVCX+7NIBCYsIKEoc2HaDHaJET2Lb3G1sEEfISrx+/oZl AiPvLCQbZiHZMAtJywJG5lWMAkWpOYmVpnqJBQU5qXrJ+bmbGMHhUhixg/H/MqtDjAIcjEo8 vBOadwQKsSaWFVfmHmKU4GBWEuF1mAAU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzhtcvS1QSCA9 sSQ1OzW1ILUIJsvEwSnVwLhh/iVRdZlvBxbN/RG2fofA82DjOc+XVdZna6UWuv85/v9P4kS/ XN4wEy6RRAHvv1NWrnypWOD4YuVy8eu2/878jyr1Dmxc1mlllXR/m96dw4k9/4XmPyi/d0V7 ru9+qWW7m3RKJ+f58zLYihyRNVqjKKjoxBf8aLPCvIu3Trqa7d0pdz/15UclluKMREMt5qLi RAAxwOZIEwIAAA== Subject: [pcp] History question: What happened to PCP version 1? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:43:46 -0000 Somewhere along the way we managed to lose PCP version number 1, and had to use 2 instead for the actual IETF standard protocol. Does anyone know specifically why that was? Were there shipping products using version number 1? Are there *still* shipping products using version number 1? Or was this just for test implementations in a lab somewhere? Stuart Cheshire From wim.henderickx@alcatel-lucent.com Wed Jun 12 11:46:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA311E80E8 for ; Wed, 12 Jun 2013 11:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPisdxg9I-1U for ; Wed, 12 Jun 2013 11:46:23 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0F05621E80A6 for ; Wed, 12 Jun 2013 11:46:20 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5CIkFSc015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jun 2013 13:46:16 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r5CIkFRd031745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Jun 2013 14:46:15 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 12 Jun 2013 14:46:15 -0400 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.100]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 12 Jun 2013 20:46:13 +0200 From: "Henderickx, Wim (Wim)" To: Stuart Cheshire , "pcp@ietf.org" Thread-Topic: [pcp] History question: What happened to PCP version 1? Thread-Index: AQHOZ5zMJR9q7gNp8UCYwAgZdkmBVZkyavkA Date: Wed, 12 Jun 2013 18:46:12 +0000 Message-ID: In-Reply-To: <0EB908DE-BB6E-4136-B6DD-BC1C137E87D3@apple.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <862D40858A3D52478043E5D1D93E3CB3@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [pcp] History question: What happened to PCP version 1? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:46:29 -0000 This was created once we introduced the nonce in the packet. We have shipping product with version 1 right now On 12/06/13 20:43, "Stuart Cheshire" wrote: >Somewhere along the way we managed to lose PCP version number 1, and had >to use 2 instead for the actual IETF standard protocol. Does anyone know >specifically why that was? Were there shipping products using version >number 1? Are there *still* shipping products using version number 1? Or >was this just for test implementations in a lab somewhere? > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Wed Jun 12 12:06:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C921E809D for ; Wed, 12 Jun 2013 12:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEN4Yu+csBzu for ; Wed, 12 Jun 2013 12:06:48 -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 E7F8511E80F1 for ; Wed, 12 Jun 2013 12:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2449; q=dns/txt; s=iport; t=1371064008; x=1372273608; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=1x8hjOnd7961SCKaYGZvWu2jgsWW5CEbyUEgvE2AYTs=; b=Rvkm7QBmU1bPGHS29srn254z8YtX7jtZpxgyF0lBVd0Mq6iWl3D8BWeH jVSqA2rx+gkGR94EpqxOvRXr4YitYPWsKorEUot6kQroP/lf6dXJ5P4m7 XyPYzSlPt09ZP8Xxo3QI8ysT1tV0NpTYaK75w+HJZgy4KpH5Twed3mNsX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIGALXFuFGtJV2d/2dsb2JhbABbgwkwSb5JgQMWbQeCJQEEHQwRUQECKBRCJQIEGwGIBQyaTKBBjgEQgQEzBYJ/YQOYaZAZgw+BcTY X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="222004761" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 12 Jun 2013 19:06:47 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5CJ6lFX026867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Jun 2013 19:06:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 14:06:47 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: PCP WG On-going Items + possible interim meeting Thread-Index: AQHOZ5/8feGQQ0L8wEKE/mzTK4hoUw== Importance: high X-Priority: 1 Date: Wed, 12 Jun 2013 19:06:46 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A67FA@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.146.153] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] PCP WG On-going Items + possible 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: Wed, 12 Jun 2013 19:06:52 -0000 FYI.=20 If a item needs correction or we need to track something I missed, feel free to send an email. Chairs/ADs are considering an interim meeting on July 2nd. Let me know your comments. Open =3D=3D=3D=3D - Call for Adoption of PCP DS-Lite (done, need new draft-ietf...) - WGLC for PCP Server Selection and gathering of reviewers (Open) - Further clarification on the use of IP address in DHCP PCP Option (AD + Chairs) - PCP Proxy needs a security section (open, Margaret Volunteered to work with authors) - PCP Proxy: discussion on processing of unknown options and opcods http://www.ietf.org/mail-archive/web/pcp/current/msg02935.html (open, med suggested text, folks commented, need draft respin) - Create a PCP nested NAT use-case and based on that the required extension (open, in-progress) - Radius Extension confirmation of adoption on list (done, need respin) - PCP failure scenarios need to contain only those scenarios not covered by base spec (respin done, failure scenarios draft proved useful in recent nonce discussion) - PCP authentication draft need updated based on discussion (done, discussed on interim, new update needed) - Nonce=20 http://www.ietf.org/mail-archive/web/pcp/current/msg03091.html - Authentication EAP vs. PANA Last message on subject: http://www.ietf.org/mail-archive/web/pcp/current/msg03086.html - Multiple Address family Requests: - Endpoint Independent _Family_ mappings and sharing of same internal source port. http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-02 - Stability of external addresses http://www.ietf.org/mail-archive/web/pcp/current/msg02922.html - Possible call of adoption of PCP failure and flows draft. - Authentication through a Proxy http://www.ietf.org/mail-archive/web/pcp/current/msg03086.html - Review of Analysis of Port Control Protocol in Mobile Networks (Tiru reviewed, need resin) - Call for Adoption of "Optimizing NAT and Firewall Keepalives Using Port Control Protocol" (Open) =20 Done: =3D=3D=3D=3D=3D - Adopt PCP Nat coord as WG document (done, comments received, respin done) - WGLC Learn NAT64 PREFIX64s (done, comments received, official reviewers done, respin done) - WGLC PCP Description option (done, comments received, respin done) - Publish UPnP-PCP IWF RFC (In RFC Ed Queue) - Updated charter milestones and deliverables (done) From cheshire@apple.com Wed Jun 12 14:03:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37B11E80D9 for ; Wed, 12 Jun 2013 14:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSdKfjczhhN4 for ; Wed, 12 Jun 2013 14:03:52 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E3C8D21F8895 for ; Wed, 12 Jun 2013 14:03:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOA0028TT5RJ9B0@mail-out.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 14:03:45 -0700 (PDT) X-AuditID: 1180715a-b7f506d000007d18-75-51b8e2306a63 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 82.8D.32024.032E8B15; Wed, 12 Jun 2013 14:03:45 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOA0026CT68VA50@spicerack.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 14:03:44 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Wed, 12 Jun 2013 14:03:44 -0700 Message-id: <55370C24-343B-40AE-87B6-FBA6FFE6E4E8@apple.com> References: To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FCsoWv4aEegweVjzBaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt+VM1kLdjJVPJp+jqmB8RtjFyMnh4SAicSa6T1sELaYxIV7 64FsLg4hgclMEieXn2WGcFYwSUyaPZEZpIpZQEti/c7jTCA2r4CexLa528C6hQVcJJr2rwKL swHVvPh8BSzOKWAvMXfCWnYQm0VAVeJwxz0miDnaEk/eXWDtYuQAmmMjcf1dDYgpJGAncWG5 FUiFiICixIFtN9ghbpOVeP38DcsERv5ZSI6YheSIWUiGLmBkXsUoUJSak1hpppdYUJCTqpec n7uJERxehVE7GBuWWx1iFOBgVOLhfdG6I1CINbGsuDL3EKMEB7OSCK/nIaAQb0piZVVqUX58 UWlOavEhRmkOFiVx3tnHgVIC6YklqdmpqQWpRTBZJg5OqQbGdrFMPw7nZ3dNHKZu9SjaWPZM 1t7uxf9dP+8tYjzKwpFxXW7+FP2VK/x1zULUOGbLue0R2u9c0q2u67l05bLlD4pzmmJ5sqJc o75FJ7zyulqXf6u7veFYDd+yX+Uv1Gz37c0r9eVXSJS9FGVz9aQEz7bSru3v1JPbFhXvbDi4 84Bm/PK47duUWIozEg21mIuKEwEoqzyzKwIAAA== Subject: Re: [pcp] History question: What happened to PCP version 1? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:03:58 -0000 On 12 Jun, 2013, at 11:46, "Henderickx, Wim (Wim)" wrote: > This was created once we introduced the nonce in the packet. We have shipping product with version 1 right now Thanks. What is the product? Is it going to be updated to version 2? Stuart Cheshire From yoshihiro.ohba@toshiba.co.jp Wed Jun 12 15:24:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232F921E80E4 for ; Wed, 12 Jun 2013 15:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.864 X-Spam-Level: X-Spam-Status: No, score=-6.864 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoA4qaRDx8MK for ; Wed, 12 Jun 2013 15:24:48 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFA11E8115 for ; Wed, 12 Jun 2013 15:24:47 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r5CMOfQM020371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 07:24:41 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5CMOfJG029056; Thu, 13 Jun 2013 07:24:41 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 708; Thu, 13 Jun 2013 07:24:41 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r5CMOfTn029053; Thu, 13 Jun 2013 07:24:41 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r5CMOfkP001176; Thu, 13 Jun 2013 07:24:41 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id HAA01175; Thu, 13 Jun 2013 07:24:41 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r5CMOe7G015915; Thu, 13 Jun 2013 07:24:41 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r5CMOeFe017396; Thu, 13 Jun 2013 07:24:40 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 07:24:40 +0900 From: To: , Thread-Topic: [pcp] PCP Proxy Authentication Requirements? Thread-Index: AQHOZu5ac/D9w5lqpUSEaMf2XzAP5Jkxcpcw Date: Wed, 12 Jun 2013 22:24:40 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D18227@tgxml338.toshiba.local> References: <51B79CB0.3050303@gmail.com> In-Reply-To: <51B79CB0.3050303@gmail.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.79] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D18227tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org Subject: Re: [pcp] PCP Proxy Authentication Requirements? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 22:24:55 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D18227tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I am responding to PANA-related questions. Please see below. From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Ben McCann Sent: Wednesday, June 12, 2013 6:55 AM To: tireddy@cisco.com Cc: pcp@ietf.org Subject: [pcp] PCP Proxy Authentication Requirements? Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate= message integrity and that it must be able to ensure message integrity if = it modifies any fields in the message. Doesn't this require authenticating the proxy to the PCP client and server = because the proxy will need separate Security Associations to both the clie= nt and the server? I.e. without knowledge of the EAP Master Session Key, th= e proxy can't modify PCP packets w/o detection so it has to participate in = the authentication process so it can form MSK's for both the client and the= server. (I know, I'm assuming EAP is part of the authentication design). Does Req-9 need clarification to note the presence of a proxy requires two = separately authenticated security associations? And, should the requirement= s permit authentication only on one side of the proxy? For example, a custo= mer premises host may not authenticate to the PCP proxy but the proxy may a= uthenticate to the PCP server? On another topic... There was substantial discussion on the list about two major PCP authentica= tion architectures, direct EAP-over-PCP and PANA. I'm still catching up on = the history of PCP authentication so forgive me if this question has been a= sked before. Are either of these protocols currently favored or has that di= scussion been tabled until the requirements are finalized? [YO] My understanding is that the discussion has been tabled until the requ= irements are finalized. I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent betwee= n the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't th= ink either of the PANA based approaches for PCP authentication (Side-by-Sid= e or Tunneled) would be interoperable with a PANA relay agent. If a PANA relay is required for a PANA deployment, and PCP was authenticate= d by PANA, then how would the PANA payloads embedded in PCP packets travers= e the PANA relay? This is another area where PANA requires tweaking to supp= ort PCP authentication. [YO] Although I believe those can be implementation specifics, first I woul= d like to fully understand PCP proxy requirements. Thanks, Yoshihiro Ohba IMO, it is preferable to design an EAP transport within PCP because it can = be purpose-built to address the specific requirements of PCP such as the PC= P proxy. (Again, I assume EAP will be part of the PCP authentication protoc= ol). -Ben McCann --_000_674F70E5F2BE564CB06B6901FD3DD78B12D18227tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I am respond= ing to PANA-related questions. 

 <= /o:p>

Please see b= elow.

 <= /o:p>

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Ben McCann
Sent: Wednesday, June 12, 2013 6:55 AM
To: tireddy@cisco.com
Cc: pcp@ietf.org
Subject: [pcp] PCP Proxy Authentication Requirements?

 

Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy mus= t be able to validate message integrity and that it must be able to ensure = message integrity if it modifies any fields in the message.

Doesn't this require authenticating the proxy to the PCP client and server = because the proxy will need separate Security Associations to both the clie= nt and the server? I.e. without knowledge of the EAP Master Session Key, th= e proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it= can form MSK's for both the client and the server. (I know, I'm assuming E= AP is part of the authentication design).

Does Req-9 need clarification to note the presence of a proxy requir= es two separately authenticated security associations? And, should the req= uirements permit authentication only on one side of the proxy? For example,= a customer premises host may not authenticate to the PCP proxy but the pro= xy may authenticate to the PCP server?


On another topic...

There was substantial discussion on the list about two major PCP authentica= tion architectures, direct EAP-over-PCP and PANA. I'm still catching up on= the history of PCP authentication so forgive me if this question has been = asked before. Are either of these protocols currently favored or has that discussion = been tabled until the requirements are finalized?

[YO] My understanding is that= the discussion has been tabled until the requirements are finalized.<= /o:p>


I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent between th= e PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP aut= hentication (Side-by-Side or Tunneled) would be interoperable with a PANA r= elay agent.<= /span>

If a PANA relay is required for a PANA deployment, and= PCP was authenticated by PANA, then how would the PANA payloads embedded i= n PCP packets traverse the PANA relay? This is another area where PANA requ= ires tweaking to support PCP authentication.

[YO] Although I believe those= can be implementation specifics, first I would like to fully understand PC= P proxy requirements.

Thanks,=

Yoshihiro Ohba

 <= /b>


IMO, it is preferable to design an EAP transport within PCP because it can = be purpose-built to address the specific requirements of PCP such as the PC= P proxy. (Again, I assume EAP will be part of the PCP authentication protoc= ol).<= /p>



-Ben McCann

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D18227tgxml338toshiba_-- From alper.yegin@yegin.org Wed Jun 12 23:14:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08A121F9399 for ; Wed, 12 Jun 2013 23:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xatsJ7yJQEj for ; Wed, 12 Jun 2013 23:14:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8437C21F9048 for ; Wed, 12 Jun 2013 23:14:38 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lxh59-1UGLXn22nb-016SHT; Thu, 13 Jun 2013 02:14:24 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=big5 From: Alper Yegin In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D33B7@mbx-01.win.nominum.com> Date: Thu, 13 Jun 2013 09:14:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF4632F-A3A1-4155-9587-7BEC839AA407@yegin.org> References: <8D23D4052ABE7A4490E77B1A012B6307751D33B7@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:mVaCd/gixOQTiHWx3kBg4WQTW78nOnEEC8bl6LXZTcx wLxQE2azrYKfBe+cXHmLkAx5FhNX2s9D81z8zo+wDsCpVamaxy /PHcHs80QG2s25yx9Dnc/RRpLrnzf+9We5x3KRG/79U7Re36r8 v5sVcUCt/4BemXdxtowIwgf5vX6fV47qDz29qU9WjypolDTYgO LbiQTpmusfpvdEkeYzo8l83pKfcSjCT6mZZMCvK2MIAj5INEdX KdaOAa4MnU2+C8WXm3u0DJA/9SEZSjN3GJDKu5PPs+Gi2FnS1u n42Lozp8cyJDNdYaVKinqSlrV4m3UOVccJro34kz4Mn+l1tBbA j8oVYSDLlzpk16WxeM68TtD2GwKz/3WkPRY35/u2Iqyj76crq/ Ij+eenQnUQ92g== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:14:44 -0000 I think what this requirement says is, "should support server-side only = authentication". "Must support mutual auth, and should support server-side only auth." (yeah, DHCP is not able to solve its own security problems, how is it = going to help others). On Jun 12, 2013, at 6:41 PM, Ted Lemon wrote: > On Jun 12, 2013, at 11:26 AM, Prashanth Patil (praspati) = wrote: >> For mutual trust b/w the client and server, some of the things = discussed were on the lines of doing DTLS with well known certificates = and deriving a key as a consequence for message integrity, client = obtains a key over secure DHCP or suchlike. >=20 > "secure DHCP"? >=20 > There is no confidentiality-providing security mechanism for DHCP, so = I think you need to explain what "or suchlike" is. :) >=20 > If you just mean to validate the public key using secure DHCP, bear in = mind that you've just pushed the key provisioning problem from PCP to = DHCP, and that there is no widely-implemented key provisioning solution = for DHCP either. >=20 From mohamed.boucadair@orange.com Wed Jun 12 23:17:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9130921F99D2 for ; Wed, 12 Jun 2013 23:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZZbJvUtT3d4 for ; Wed, 12 Jun 2013 23:16:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 40D6F21F896D for ; Wed, 12 Jun 2013 23:16:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id DA79D2646A9; Thu, 13 Jun 2013 08:16:57 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9196F35C058; Thu, 13 Jun 2013 08:16:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 13 Jun 2013 08:16:57 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Thu, 13 Jun 2013 08:16:55 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: Ac5nm0QU74wTQ9STSsOL1RVWNYXlBQAX/qZA Message-ID: <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> In-Reply-To: <66451318-8D44-4462-91A7-FD28461349E2@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.13.54223 Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:17:03 -0000 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: mercredi 12 juin 2013 20:33 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On 12 Jun, 2013, at 01:31, mohamed.boucadair@orange.com wrote: > >> Stuart, >> >> We are approaching the problem with two different perspectives: >> * You are more concerned about "poor" PCP client implementations >> * I'm more concerned about how a client can get connectivity and how the >server can help in maximizing the chance to honor a request >> >> I understand your concern but defining a new error code will create a ne= w >connectivity failure case if the client does not try another request with >the adjusted Suggested External IP Address. But what are the guarantees a >"poor" implementation will try another adjusted request? > > >Because the *human* writing the code cannot avoid noticing that their code >doesn't work, so they will fix it. [Med] This is part of the basic test cases to be conducted (no matter the e= rror code is defined or not). > >What makes you think that a "poor" implementation, that today only handles >one address family, will somehow spontaneously grow a new piece of code, i= n >the field, two years from now, which enables it to correctly handle replie= s >containing the other address family that it currently knows nothing about? > [Med] You can expect anything from a "poor" implementation. This is the poi= nt behind the question I raised above. We should not exacerbate connectivit= y failures because of some design choices motivated by the behavior of "poo= r" implementations. Instead of creating a new error code, sketching recomme= ndations for the client to increase its chance to get connectivity such as = recall implementors about basic PCP design choices, e.g.: (1) the PCP serve= r should service a valid request; no need to return an error (as you rightf= ully mentioned in slide 7 of http://www.ietf.org/proceedings/80/slides/pcp-= 8.pdf), (2) a PCP client is not aware of the external AF managed by the PCP= server; it should be prepared to receive a AF not matching the one indicat= ed in the suggested field. Of course a PCP client that wants to retrieve all AFs, will need to send tw= o requests to the server. The server will return two mappings or only the s= ame mapping for both requests. From alper.yegin@yegin.org Wed Jun 12 23:34:12 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B9721F99B7 for ; Wed, 12 Jun 2013 23:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rtdB7ViwpQO for ; Wed, 12 Jun 2013 23:34:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFED21F995F for ; Wed, 12 Jun 2013 23:34:07 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M4Geh-1UVl2K2l8d-00r0SW; Thu, 13 Jun 2013 02:34:05 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_621D7506-C8CB-401F-8314-47463C81C188" From: Alper Yegin In-Reply-To: <51B79CB0.3050303@gmail.com> Date: Thu, 13 Jun 2013 09:33:57 +0300 Message-Id: References: <51B79CB0.3050303@gmail.com> To: Ben McCann X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:SD3vaVwb2whMca96BlX4twhyM5cPPNMWFR7t/YBJLqK yI1zS3tZpCEiyY2TATPjpSkSb7q57hbI/cUxAXot5WO2oZPe/J NuRXGb5b4W9NXqhj+9uZ5FrZRhd9eVb/18YJ4ludkInv1k8jGy etQvIXRFPkSNBla/lv+zylp8fUXv7L8YUL+dPBzyZudFS2xe6z CEus0w7/CzJON/HnIXGh2l8xJUaSBFEZBg+Ixlw+Vqo3aPuYEW Sf8e1yWh++U/BIm9I6mgnra20tW1ItCBmeLIp4C01FD3JqrHgz 7ICfLLFP6mNxeu69dmCotYCv1Ms5ejk/o/34UG5o7Vca6RuI1t g35K0ELBZcXsfZuiY/+PlrCnid3AGy32FEiH/8dQ5iUCmT6FGD JhT7D7JHvhG8Q== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] PCP Proxy Authentication Requirements? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:34:12 -0000 --Apple-Mail=_621D7506-C8CB-401F-8314-47463C81C188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, On Jun 12, 2013, at 12:54 AM, Ben McCann wrote: > Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to = validate message integrity and that it must be able to ensure message = integrity if it modifies any fields in the message. >=20 > Doesn't this require authenticating the proxy to the PCP client and = server because the proxy will need separate Security Associations to = both the client and the server? I.e. without knowledge of the EAP Master = Session Key, the proxy can't modify PCP packets w/o detection so it has = to participate in the authentication process so it can form MSK's for = both the client and the server. (I know, I'm assuming EAP is part of the = authentication design). >=20 > Does Req-9 need clarification to note the presence of a proxy requires = two separately authenticated security associations? And, should the = requirements permit authentication only on one side of the proxy? For = example, a customer premises host may not authenticate to the PCP proxy = but the proxy may authenticate to the PCP server? >=20 For the proxy to be able to modify the PCP packets and still maintain = crypto-protection, we at least need two SAs: One between the PCP client = and PCP proxy, and another between the PCP proxy and the PCP server. We = could even talk about having a third one between the PCP client and the = PCP server if we want to have a direct SA and identify some PCP payloads = as untouchable by the proxy. >=20 > On another topic... >=20 > There was substantial discussion on the list about two major PCP = authentication architectures, direct EAP-over-PCP and PANA. I'm still = catching up on the history of PCP authentication so forgive me if this = question has been asked before. Are either of these protocols currently = favored or has that discussion been tabled until the requirements are = finalized? >=20 > I'm curious because PANA includes a secondary RFC (RFC 6345) which = describes the operation of a relay agent between the PANA Client (PaC) = and the PANA Authentication Agent (PAA). I don't think either of the = PANA based approaches for PCP authentication (Side-by-Side or Tunneled) = would be interoperable with a PANA relay agent. >=20 > If a PANA relay is required for a PANA deployment, and PCP was = authenticated by PANA, then how would the PANA payloads embedded in PCP = packets traverse the PANA relay? This is another area where PANA = requires tweaking to support PCP authentication. >=20 > IMO, it is preferable to design an EAP transport within PCP because it = can be purpose-built to address the specific requirements of PCP such as = the PCP proxy. (Again, I assume EAP will be part of the PCP = authentication protocol). >=20 PANA relay and PCP proxy are two independent things. Having said that=85. = And PANA relay is an optional feature that is designed for a very = special need (see Zigbee IP). Intro says: This document specifies PANA Relay Element (PRE) functionality, which enables PANA messaging between a PaC and a PAA where the two nodes cannot reach each other by means of regular IP routing. For example, in ZigBee IP [ZIGBEEIP] that uses 6LoWPAN [RFC4944], a joining node (PaC) can only use a link-local IPv6 address to communicate with a parent node prior to PANA authentication. The PAA typically resides in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often multiple IP hops away from the PaC. The PRE implemented on the parent node is used for relaying PANA messages between the PaC and the PAA in this scenario. When PANA is carried inside PCP, PANA gets transported over PCP directly = between the PCP client and the PCP server.=20 I don't see the need to use PANA relay in this case.=20 Alper > -Ben McCann >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_621D7506-C8CB-401F-8314-47463C81C188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=20 =20
Req-9 in draft-reddy-pcp-auth-03 notes a PCP proxy must be able to validate message integrity and that it must be able to ensure message integrity if it modifies any fields in the message.

Doesn't this require authenticating the proxy to the PCP client and server because the proxy will need separate Security Associations to both the client and the server? I.e. without knowledge of the EAP Master Session Key, the proxy can't modify PCP packets w/o detection so it has to participate in the authentication process so it can form MSK's for both the client and the server. (I know, I'm assuming EAP is part of the authentication design).

Does Req-9 need clarification to note the presence of a proxy = requires two separately authenticated security associations? And, should the requirements permit authentication only on one side of the proxy? For example, a customer premises host may not authenticate to the PCP proxy but the proxy may authenticate to the PCP server?


For the proxy to be able = to modify the PCP packets and still maintain crypto-protection, we at = least need two SAs: One between the PCP client and PCP proxy, and = another between the PCP proxy and the PCP server. We could even talk = about having a third one between the PCP client and the PCP server if we = want to have a direct SA and identify some PCP payloads as untouchable = by the proxy.



On another topic...

There was substantial discussion on the list about two major PCP authentication architectures, direct EAP-over-PCP and PANA. I'm still catching up on the history of PCP authentication so forgive me if this question has been asked = before. Are either of these protocols currently favored or has that discussion been tabled until the requirements are finalized?

I'm curious because PANA includes a secondary RFC (RFC 6345) which describes the operation of a relay agent between the PANA Client (PaC) and the PANA Authentication Agent (PAA). I don't think either of the PANA based approaches for PCP authentication (Side-by-Side or Tunneled) would be interoperable with a PANA relay agent.

If a PANA relay is required for a PANA deployment, and PCP was authenticated by PANA, then how would the PANA payloads embedded in PCP packets traverse the PANA relay? This is another area where PANA requires tweaking to support PCP authentication.

IMO, it is preferable to design an EAP transport within PCP because it can be purpose-built to address the specific requirements of PCP such as the PCP proxy. (Again, I assume EAP will be part of the PCP authentication protocol).


PANA relay and PCP proxy = are two independent things. Having said that=85. And PANA relay is an = optional feature that is designed for a very special need  (see = Zigbee IP).

Intro = says:

   This document specifies PANA Relay =
Element (PRE) functionality, which
   enables PANA messaging between a PaC and a PAA where the two nodes
   cannot reach each other by means of regular IP routing.  For example,
   in ZigBee IP [ZIGBEEIP] that uses =
6LoWPAN [RFC4944], a joining node
   (PaC) can only use a link-local IPv6 address to communicate with a
   parent node prior to PANA authentication.  The PAA typically resides
   in a 6LowPAN Border Router (6LBR) [6LoWPAN-ND], which is often
   multiple IP hops away from the PaC.  The PRE implemented on =
the
   parent node is used for relaying =
PANA messages between the PaC and
   the PAA in this =
scenario.



When PANA is carried inside PCP, PANA gets transported over = PCP directly between the PCP client and the PCP = server. 
I don't see the need to use PANA relay in this = case. 

Alper







<= /div>
-Ben McCann

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

= --Apple-Mail=_621D7506-C8CB-401F-8314-47463C81C188-- From cheshire@apple.com Wed Jun 12 23:34:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D781421F90FD for ; Wed, 12 Jun 2013 23:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG6AXB6uzSqQ for ; Wed, 12 Jun 2013 23:34:34 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id D81A221F90CD for ; Wed, 12 Jun 2013 23:34:33 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOB002SRJLJJ9F1@mail-out.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 23:34:33 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-1d-51b967f91278 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 78.9A.15051.9F769B15; Wed, 12 Jun 2013 23:34:33 -0700 (PDT) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOB00BTPJLK3V60@kencur.apple.com> for pcp@ietf.org; Wed, 12 Jun 2013 23:34:33 -0700 (PDT) From: Stuart Cheshire In-reply-to: <51B84E03.5050001@viagenie.ca> Date: Wed, 12 Jun 2013 23:34:32 -0700 Content-transfer-encoding: quoted-printable Message-id: <39E6B948-2E53-4F22-B32D-F50D2F3E50E2@apple.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> <51B84E03.5050001@viagenie.ca> To: pcp@ietf.org X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUiON1OTfdn+s5Ag+cb5SwmH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAd/LrIWnGSu6FzeztLA+I2pi5GTQ0LARGLarLOsELaYxIV7 69lAbCGBJiaJr3+B4lxA9j4miYWz9oI1MAvoSPR+/8YMYvMKGEosub6FHcQWFtCWeHv7FpjN JqAl8eLzFbBBnEDx5t8nGUFsFgFVifZZW5kh5mhLPHl3gRVijo3Ey5PXWCCWzWOU+DtzA1iR iICAxO/Vl6EulZXYeec0ywRG/llI7piF5I5ZSOYuYGRexShQlJqTWGmhl1hQkJOql5yfu4kR FGINhWk7GJuWWx1iFOBgVOLhfdG6I1CINbGsuDL3EKMEB7OSCK/nIaAQb0piZVVqUX58UWlO avEhRmkOFiVx3jnHgVIC6YklqdmpqQWpRTBZJg5OqQZGxdRIYfdmZZ0z866flQ6daSvP9y/9 F9f6I1s+G1md22lX+uBCodj82UauD3uS8vL2GfbEMe9LKfh8/uG0B1JxzFGft2XJJayZw35o yds/HBvNWT6FzUj7rOhVeu7x8rtyKnafWbtU1eKPpzO3TXvTdbFgYYLGhHnPzjzbJX7YRlPz pRefq+8uJZbijERDLeai4kQAFlIACi0CAAA= Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:34:40 -0000 On 12 Jun 2013, at 3:31, Simon Perreault wrote: > Le 2013-06-12 06:44, Stuart Cheshire a =E9crit : >> Done: = >=20 > Good job! >=20 > Still missing is the nonce check thing. Here's some text as a = contribution... Thanks. I have submitted = to add = the changes to nonce checking rules. Stuart Cheshire From simon.perreault@viagenie.ca Thu Jun 13 02:25:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0721F9121 for ; Thu, 13 Jun 2013 02:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2-kJ40ihFYV for ; Thu, 13 Jun 2013 02:25:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0E421F9976 for ; Thu, 13 Jun 2013 02:25:03 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:84c5:867d:e648:8153]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 01AFC4038A for ; Thu, 13 Jun 2013 05:25:01 -0400 (EDT) Message-ID: <51B98FEC.3070303@viagenie.ca> Date: Thu, 13 Jun 2013 11:25:00 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604090A601A@xmb-rcd-x04.cisco.com> <51B84E03.5050001@viagenie.ca> <39E6B948-2E53-4F22-B32D-F50D2F3E50E2@apple.com> In-Reply-To: <39E6B948-2E53-4F22-B32D-F50D2F3E50E2@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 09:25:48 -0000 Le 2013-06-13 08:34, Stuart Cheshire a écrit : > I have submitted to add the changes to nonce checking rules. Did you intentionally change the text describing the new behaviour? Sections 3.1 and 3.2 now say that the nonce and lifetime are updated. That's completely different from the thread consensus (return the request's nonce and remaining lifetime), and certainly different from what I wrote. Simon From praspati@cisco.com Thu Jun 13 05:43:47 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D615C21F9A26 for ; Thu, 13 Jun 2013 05:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL0gnQCY3Fyn for ; Thu, 13 Jun 2013 05:43:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA2021F9A24 for ; Thu, 13 Jun 2013 05:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=940; q=dns/txt; s=iport; t=1371127422; x=1372337022; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CcewbPYv6Tkyafco6kJX7YRusFBUBw4S854BSRpaRAw=; b=FmEN/75MTEbr0ypvW+8jg/Ko01F3EwyRGRozTukrXnhzvRNw0nLiQelz 02on0KR6T/dD2BQaNHnQvJ12zAhErnR57VlmsG6TfkgqQeB5TbXUbT6Sk CEPWiG5a0TIJ8JYzVdNei4/PoSGA7p5WxRmqrQN5EtGyeHFA1mo1uUmwG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAH29uVGtJV2a/2dsb2JhbABbgwl5gi28PYEAFnSCIwEBAQR5EgEIGApWJQIEDgUIE4dzuzaPEgYrB4J/YQOIaKAbgw+BaiQZ X-IronPort-AV: E=Sophos;i="4.87,858,1363132800"; d="scan'208";a="222374995" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jun 2013 12:43:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5DChfRc012471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 12:43:41 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 07:43:41 -0500 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHOZ4ElH5CsDT4ihUGA5aZ16KNZNJkyi4iAgAG8uwA= Date: Thu, 13 Jun 2013 12:43:40 +0000 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D33B7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.68.16.83] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5AC4E3B35099BF41AAF367913F6E1190@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" , "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:43:47 -0000 Hi Ted, On 12/06/13 9:11 PM, "Ted Lemon" wrote: >On Jun 12, 2013, at 11:26 AM, Prashanth Patil (praspati) > wrote: >> For mutual trust b/w the client and server, some of the things >>discussed were on the lines of doing DTLS with well known certificates >>and deriving a key as a consequence for message integrity, client >>obtains a key over secure DHCP or suchlike. > >"secure DHCP"? > >There is no confidentiality-providing security mechanism for DHCP, so I >think you need to explain what "or suchlike" is. :) > >If you just mean to validate the public key using secure DHCP, bear in >mind that you've just pushed the key provisioning problem from PCP to >DHCP, and that there is no widely-implemented key provisioning solution >for DHCP either. > Agreed. This wasn=B9t a recommendation, it was something that was discussed in the interim meeting. -Prashanth > From praspati@cisco.com Thu Jun 13 05:47:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A709621F9A4E for ; Thu, 13 Jun 2013 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiEIJzCWUWxd for ; Thu, 13 Jun 2013 05:47:21 -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 C0D0D21F9A72 for ; Thu, 13 Jun 2013 05:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1371127622; x=1372337222; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6xZz8Cl2Gbfitx9fPXBV/C3nkMy+qrZJEzUpbiFB7Kk=; b=MgSP+y3pfN7Yth0UZE+Mjcxy/eC+kOhQAAAlR1MJ5vNBLVjjwev8XCDZ /TCHspxO9rV0nGXFE6aQ8giGJooKa8T6tZRHyFz6G8VAgfNvjzRtEtpua s4mfVQ+vopojB08hAgK78bgzyEwE3ahi6vD/gFMuidT/PFzVjikc/KsMU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK2+uVGtJV2b/2dsb2JhbABbgwl5vmqBABZ0giMBAQEEOj8SAQgYChRCJQIEAQ0FCBOHc7s6jxIxB4J/YQOpA4MPgWokGQ X-IronPort-AV: E=Sophos;i="4.87,858,1363132800"; d="scan'208";a="222155606" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jun 2013 12:46:52 +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 r5DCkqNW016545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 12:46:52 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 07:46:51 -0500 From: "Prashanth Patil (praspati)" To: Alper Yegin , Ted Lemon Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHOZ4ElH5CsDT4ihUGA5aZ16KNZNJkyi4iAgADzvICAAMnhAA== Date: Thu, 13 Jun 2013 12:46:50 +0000 Message-ID: In-Reply-To: <9BF4632F-A3A1-4155-9587-7BEC839AA407@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.68.16.83] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] pcp auth requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 12:47:26 -0000 Hi Alper, On 13/06/13 11:44 AM, "Alper Yegin" wrote: >I think what this requirement says is, "should support server-side only >authentication". >"Must support mutual auth, and should support server-side only auth." Yes. An anonymous client should be able to verify a PCP server using server-side-only auth and as a consequence obtain an SA which will be used for PCP message integrity. -Prashanth > >(yeah, DHCP is not able to solve its own security problems, how is it >going to help others). > > >On Jun 12, 2013, at 6:41 PM, Ted Lemon wrote: > >> On Jun 12, 2013, at 11:26 AM, Prashanth Patil (praspati) >> wrote: >>> For mutual trust b/w the client and server, some of the things >>>discussed were on the lines of doing DTLS with well known certificates >>>and deriving a key as a consequence for message integrity, client >>>obtains a key over secure DHCP or suchlike. >>=20 >> "secure DHCP"? >>=20 >> There is no confidentiality-providing security mechanism for DHCP, so I >>think you need to explain what "or suchlike" is. :) >>=20 >> If you just mean to validate the public key using secure DHCP, bear in >>mind that you've just pushed the key provisioning problem from PCP to >>DHCP, and that there is no widely-implemented key provisioning solution >>for DHCP either. >>=20 > From internet-drafts@ietf.org Thu Jun 13 06:48:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4051021F9AD8; Thu, 13 Jun 2013 06:48:42 -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.084, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRQW6lP1-NpL; Thu, 13 Jun 2013 06:48:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D02F721F946C; Thu, 13 Jun 2013 06:48: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.51.p2 Message-ID: <20130613134841.23690.29218.idtracker@ietfa.amsl.com> Date: Thu, 13 Jun 2013 06:48:41 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dslite-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: Thu, 13 Jun 2013 13:48: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 : The Port Control Protocol in Dual-Stack Lite environments Author(s) : Francis Dupont Tina Tsou Jacni Qin Margaret Wasserman Dacheng Zhang Filename : draft-ietf-pcp-dslite-00.txt Pages : 6 Date : 2013-06-13 Abstract: This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dslite There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dslite-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Thu Jun 13 08:56:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51121F9967 for ; Thu, 13 Jun 2013 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.608 X-Spam-Level: X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHXs4DSAcHnI for ; Thu, 13 Jun 2013 08:56:21 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C53AD21F9A5B for ; Thu, 13 Jun 2013 08:56:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUbnrkfsCpcxCAMfL994RujmPClO5cEEO@postini.com; Thu, 13 Jun 2013 08:56:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 904B41B81D7 for ; Thu, 13 Jun 2013 08:56:01 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 87C1919005D; Thu, 13 Jun 2013 08:56:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 08:56:01 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgABQ54CAAZHLgIAAGbEAgACn9YCAAMS8gIAAocsA Date: Thu, 13 Jun 2013 15:56:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:56:29 -0000 Med, under what circumstances would a good implementation that is aware of = the UNSUPP_FAMILY error code fail to get the connectivity it needed? From mohamed.boucadair@orange.com Thu Jun 13 22:45:06 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1221F9B23 for ; Thu, 13 Jun 2013 22:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlC6WCv2qz1T for ; Thu, 13 Jun 2013 22:45:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D139121F9007 for ; Thu, 13 Jun 2013 22:44:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 67B8622D150; Fri, 14 Jun 2013 07:44:44 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4D96935C045; Fri, 14 Jun 2013 07:44:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 14 Jun 2013 07:44:44 +0200 From: To: Ted Lemon Date: Fri, 14 Jun 2013 07:44:42 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgABQ54CAAZHLgIAAGbEAgACn9YCAAMS8gIAAocsAgABuGlA= Message-ID: <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.14.32415 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 05:45:06 -0000 Hi Ted, Please see inline. >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: jeudi 13 juin 2013 17:56 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Stuart Cheshire; pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >Med, under what circumstances would a good implementation that is aware of >the UNSUPP_FAMILY error code fail to get the connectivity it needed? [Med] If it does not **systematically** re-send the request with another AF= after receiving an UNSUPP_AF error. Please refer to the table I provided h= ere: http://www.ietf.org/mail-archive/web/pcp/current/msg03081.html. We don= 't have that risk if we assume a good implementation should be prepared to = receive any AF from the server. =20 BTW, a client is not aware of the AF supported by the server. So suggested = external IP address is only a hint to create the mapping; which is only a m= eans to provide connectivity.=20 Take the example of an IPv6-only host located behind a NAT64: the host is n= ot aware external IPv4 @es are managed by the NAT64. How that client will a= djust the AF of the suggested external address field? My take on this is it= should not have any preference.=20 From Ted.Lemon@nominum.com Fri Jun 14 03:18:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4621F9C69 for ; Fri, 14 Jun 2013 03:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plyfsJNA3wXs for ; Fri, 14 Jun 2013 03:18:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22B21F9C67 for ; Fri, 14 Jun 2013 03:18:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUbruDcbhpT0OT0HQkIR2Hu9Lf86MGDAm@postini.com; Fri, 14 Jun 2013 03:18:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC4781B81E0 for ; Fri, 14 Jun 2013 03:18:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 88C0219005D; Fri, 14 Jun 2013 03:18:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 03:18:47 -0700 From: Ted Lemon To: " " Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgABQ54CAAZHLgIAAGbEAgACn9YCAAMS8gIAAocsAgABuGlCAAMYDgA== Date: Fri, 14 Jun 2013 10:18:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D72CE@mbx-01.win.nominum.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 10:19:00 -0000 On Jun 14, 2013, at 1:44 AM, wrote: > [Med] If it does not **systematically** re-send the request with another = AF after receiving an UNSUPP_AF error. Please refer to the table I provided= here: http://www.ietf.org/mail-archive/web/pcp/current/msg03081.html. We d= on't have that risk if we assume a good implementation should be prepared t= o receive any AF from the server.=20 So your point is that a PCP client that supports IPv6 connections might not= ask for an IPv6 connection. Stuart's point is that a client that doesn't= support IPv6 connections might get an IPv6 connection and crash. The downside in your case is that a broken client doesn't get service. Th= e downside in Stuart's case is that a service has to be shut off to avoid b= reaking broken clients. This seems like an easy decision. From mohamed.boucadair@orange.com Fri Jun 14 04:27:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2F21F9C37 for ; Fri, 14 Jun 2013 04:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVzeSjcyE3We for ; Fri, 14 Jun 2013 04:27: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 8639621F9C26 for ; Fri, 14 Jun 2013 04:27:50 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C970C324D3A; Fri, 14 Jun 2013 13:27:49 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AED064C083; Fri, 14 Jun 2013 13:27:49 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 14 Jun 2013 13:27:49 +0200 From: To: Ted Lemon Date: Fri, 14 Jun 2013 13:27:47 +0200 Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgABQ54CAAZHLgIAAGbEAgACn9YCAAMS8gIAAocsAgABuGlCAAMYDgP//m0XQ Message-ID: <94C682931C08B048B7A8645303FDC9F36ED963A143@PUEXCB1B.nanterre.francetelecom.fr> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D72CE@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D72CE@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.14.95415 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 11:27:56 -0000 Please see inline. >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: vendredi 14 juin 2013 12:19 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Stuart Cheshire; pcp@ietf.org >Objet=A0: Re: [pcp] UNSUPP_FAMILY error code > >On Jun 14, 2013, at 1:44 AM, wrote: >> [Med] If it does not **systematically** re-send the request with another >AF after receiving an UNSUPP_AF error. Please refer to the table I provide= d >here: http://www.ietf.org/mail-archive/web/pcp/current/msg03081.html. We >don't have that risk if we assume a good implementation should be prepared >to receive any AF from the server. > >So your point is that a PCP client that supports IPv6 connections might no= t >ask for an IPv6 connection. [Med] I guess you meant IPv4 connection.=20 Stuart's point is that a client that doesn't >support IPv6 connections might get an IPv6 connection and crash. [Med] This is what I'm objecting: we should not constraint the protocol bec= ause of the behavior of some "poor" implementations. This can be fixed by r= e-iterating PCP design choices: the server should service a well formed req= uest + the client should be prepared to receive any AF from the server. > >The downside in your case is that a broken client doesn't get service. >The downside in Stuart's case is that a service has to be shut off to avoi= d >breaking broken clients. > >This seems like an easy decision. From Ted.Lemon@nominum.com Fri Jun 14 04:40:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2094F21F9C56 for ; Fri, 14 Jun 2013 04:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwaUKzr15o5v for ; Fri, 14 Jun 2013 04:40:43 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8421F9C54 for ; Fri, 14 Jun 2013 04:40:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUbsBOrsxU96yA9LlJZfDjYv3Ec+yQZJz@postini.com; Fri, 14 Jun 2013 04:40:43 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B33501B81EA for ; Fri, 14 Jun 2013 04:40:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AAB9219005D; Fri, 14 Jun 2013 04:40:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 04:40:42 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5keYRmAgAkCMgCAAoKbgIAAeDCAgADvxgCAA8K/AIABSbuAgABQ54CAAZHLgIAAGbEAgACn9YCAAMS8gIAAocsAgABuGlCAAMYDgP//m0XQgAB7nYA= Date: Fri, 14 Jun 2013 11:40:42 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D764B@mbx-01.win.nominum.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D72CE@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36ED963A143@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED963A143@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9F8BCBB3894564458D541BBC3B2CD693@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire , "pcp@ietf.org" Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 11:40:50 -0000 On Jun 14, 2013, at 7:27 AM, mohamed.boucadair@orange.com wrote: >> So your point is that a PCP client that supports IPv6 connections might = not >> ask for an IPv6 connection. > [Med] I guess you meant IPv4 connection.=20 No, I mean an IPv6 connection. But it could go either way, sure. > Stuart's point is that a client that doesn't >> support IPv6 connections might get an IPv6 connection and crash. > [Med] This is what I'm objecting: we should not constraint the protocol b= ecause of the behavior of some "poor" implementations. This can be fixed by= re-iterating PCP design choices: the server should service a well formed r= equest + the client should be prepared to receive any AF from the server. Right, you are making an asymmetric assumption: that clients will be broken= in the sense that they will not ask for a connection they could otherwise = support, but will not be broken in the sense that they will not correctly s= upport a connection the implementor didn't anticipate them getting. I don't think this is reasonable. Clients can be broken in both ways; the= question is, what is the downside to each form of brokenness. From iesg-secretary@ietf.org Fri Jun 14 09:49:28 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56B221F9CA9; Fri, 14 Jun 2013 09:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRfr7Yrs9cC6; Fri, 14 Jun 2013 09:49:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCFF21F9BD1; Fri, 14 Jun 2013 09:49:28 -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.51.p2 Message-ID: <20130614164928.25712.43749.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 09:49:28 -0700 Cc: pcp@ietf.org Subject: [pcp] PCP Working Group Virtual Interim Meeting, July 2, 2013 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 14 Jun 2013 16:49:28 -0000 The PCP Working Group will hold a virtual interim meeting on Tuesday, = July 2, 2013 at 7:00 AM PDT. Additional information will be announced on the PCP WG mailing list: http://www.ietf.org/mail-archive/web/pcp/current/maillist.html From repenno@cisco.com Fri Jun 14 11:39:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4A221F96F5 for ; Fri, 14 Jun 2013 11:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJpUQNa4Qq3s for ; Fri, 14 Jun 2013 11:39:43 -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 CA80221F911B for ; Fri, 14 Jun 2013 11:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=573; q=dns/txt; s=iport; t=1371235180; x=1372444780; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=GsLr2gx5MvIdM0xWced2e6TOuUgMeXVm7TrlfNTyzQo=; b=FkxLfTslk/mdvz1CDFala7yMT8XrJKmbHxnBvjdYXt2GW2cE7u0FY9xU Tj5LogNo+KaEP0riE/BLfL9m9/Wx+PSJ+K3krDY99ol9v/uLRVQ+3iXc8 onn5nUKVPbD3u0SI3xVHHYrbEE+CRj91Oizlt5C2fCfpvnQYlW0vDvWwN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwGAChiu1GtJXG9/2dsb2JhbABbgwkwSYI4vCOBChZtB4IlAQQBAQE3NB0BKhQ3CyUCBBMIAYgFDJlToBKOBhCBATMFgn9hA6kDgViBN4FxNw X-IronPort-AV: E=Sophos;i="4.87,867,1363132800"; d="scan'208";a="222975116" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jun 2013 18:39:38 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5EIdc44000693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Jun 2013 18:39:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 13:39:38 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Presentation Requests - Re: [pcp] PCP Working Group Virtual Interim Meeting, July 2, 2013 Thread-Index: AQHOaR8pjXHww7b7uEqqSZlwuzzoRZk1rFGA Date: Fri, 14 Jun 2013 18:39:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A830E@xmb-rcd-x04.cisco.com> In-Reply-To: <20130614164928.25712.43749.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.13.0.110805 x-originating-ip: [10.21.71.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <91DC736F816CAC44AB02647E476B5555@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Presentation Requests - Re: PCP Working Group Virtual Interim Meeting, July 2, 2013 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 14 Jun 2013 18:39:48 -0000 If you want to present at the next interim meeting please send a email with topic, time and presenter. Thanks, Reinaldo On 6/14/13 1:49 PM, "IESG Secretary" wrote: >The PCP Working Group will hold a virtual interim meeting on Tuesday, >July 2, 2013 at 7:00 AM PDT. > >Additional information will be announced on the PCP WG mailing list: >http://www.ietf.org/mail-archive/web/pcp/current/maillist.html >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From bn.mccann@gmail.com Fri Jun 14 11:48:20 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5621F9CDC for ; Fri, 14 Jun 2013 11:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aby4ZbpBbIYo for ; Fri, 14 Jun 2013 11:48:20 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EE9CA21F9C8B for ; Fri, 14 Jun 2013 11:48:19 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so910032pab.41 for ; Fri, 14 Jun 2013 11:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; bh=j18oedcsVJF31IP3x/1AKYHhdlwvKr/LaOS7mZWfBSw=; b=O+7TAPJByfHd1iYTF0PN+THBsKLvOCnTqwuAJgBRjujWhp8Brx9U7WF7IPgh4vOghQ eVfwoxjO9B/8GwWF8uPtKJmLnqo6mSkV0mmJKoUV4yi8Uc2nelha0HK0e2ccFsepTe5i zOux3OHOvTwxkN5FbZ02mzNo+pAnW1C5uTIIP6aKFVy8UwIXSWChY3VC8tBJh2obEsne 2njf4ZPPjsiLzzfAQPd8YMBtZZmfuH6kDC6Gh3CSrM1uqmNFv5Lo2G7RMi8kHPtDFxra MLhOOslC3+fCO2TLxmi6ChHV5M9F48vUFYIZ5hjj/IocRmcTqdIEjwXHvF9+A7GWLarm k3gw== X-Received: by 10.68.247.131 with SMTP id ye3mr3825566pbc.87.1371235699701; Fri, 14 Jun 2013 11:48:19 -0700 (PDT) Received: from [10.10.20.129] (70-88-209-30-ubr905-ne-ma.hfc.comcastbusiness.net. [70.88.209.30]) by mx.google.com with ESMTPSA id wi6sm3188036pbc.22.2013.06.14.11.48.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 11:48:18 -0700 (PDT) Message-ID: <51BB6571.3000901@gmail.com> Date: Fri, 14 Jun 2013 14:48:17 -0400 From: Ben McCann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tireddy@cisco.com Content-Type: multipart/alternative; boundary="------------010104060705020306050401" Cc: pcp@ietf.org Subject: [pcp] PCP Authentication *Technique* Requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 18:48:20 -0000 This is a multi-part message in MIME format. --------------010104060705020306050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit draft-reddy-pcp-auth-03 defines about 14 requirements for the PCP authentication protocol. These requirements don't include any discussion about the cryptographic strength or user identity model of the authentication techniques(s) used within PCP authentication. The current requirements are too vague on this point because, I think, there's an assumption in the WG that PCP authentication will be based on EAP. I agree. I don't think the PCP WG should invent authentication techniques. So, I suggest we change the following recommendation: REQ-11: It is RECOMMENDED to choose a widely deployed authentication technique with known security properties rather than inventing a new authentication mechanism. to a requirement: REQ-11: A widely deployed authentication technique with known security properties MUST be selected as the authentication mechanism within PCP. I'd also add another recommendation: REQ-11-A: It is RECOMMENDED to choose an extensible authentication technique to ensure PCP authentication can adapt to future authentication methods. This may be obvious to WG members who've followed the authentication discussion to date but it's not clear by looking at the PCP authentications requirements draft. The draft leaves open the possibility of inventing a new authentication technique and I think that would be a distraction and a waste of time. -Ben McCann --------------010104060705020306050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit draft-reddy-pcp-auth-03 defines about 14 requirements for the PCP authentication protocol. These requirements don't include any discussion about the cryptographic strength or user identity model of the authentication techniques(s) used within PCP authentication.

The current requirements are too vague on this point because, I think, there's an assumption in the WG that PCP authentication will be based on EAP. I agree. I don't think the PCP WG should invent authentication techniques.

So, I suggest we change the following recommendation:

   REQ-11:  It is RECOMMENDED to choose a widely deployed authentication
      technique with known security properties rather than inventing a
      new authentication mechanism.

to a requirement:

   REQ-11:  A widely deployed authentication technique with known security
      properties MUST be selected as the authentication mechanism within PCP.

I'd also add another recommendation:

   REQ-11-A:  It is RECOMMENDED to choose an extensible authentication
      technique to ensure PCP authentication can adapt to future authentication
      methods.
This may be obvious to WG members who've followed the authentication discussion to date but it's not clear by looking at the PCP authentications requirements draft. The draft leaves open the possibility of inventing a new authentication technique and I think that would be a distraction and a waste of time.

-Ben McCann

--------------010104060705020306050401-- From repenno@cisco.com Sat Jun 15 12:32:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE621F9CD6 for ; Sat, 15 Jun 2013 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybNedd4pAjqw for ; Sat, 15 Jun 2013 12:32:40 -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 4285521F9C51 for ; Sat, 15 Jun 2013 12:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1371324760; x=1372534360; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ByMHZESrEfzMlewcGHL071Wlmou4URZtwkaVRfwkMTM=; b=mfgcEEam5Leewg1/YOsyR8nsEUEI49CHPJeDS+S3g8dJG4xZt4PaeADe 5ncGwVbEEzP3rJuJHj3CaX9OE+BGHxZptCFQpinof45P3mUkNDa0x+PNx +LAuP02SamThlqlc6Q2j6aqq+WLH4UqATbcnggXLsYYqGX9D5i3Zh/wjK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4IAEvAvFGtJV2a/2dsb2JhbABagwkxSYI4vBCBBhZtB4IlAQQ6UQEqFEIlAgQTCAGIBQyZGp98jxY4gn9hA5hqkBqDD4Io X-IronPort-AV: E=Sophos;i="4.87,872,1363132800"; d="scan'208";a="223342057" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jun 2013 19:32:40 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5FJWdZN032055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Jun 2013 19:32:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 15 Jun 2013 14:32:39 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: PCP Stability of External Address Recommendations Thread-Index: AQHOaf8YV2A6plmNz0ixMcfYf0A6Eg== Date: Sat, 15 Jun 2013 19:32:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090A862B@xmb-rcd-x04.cisco.com> In-Reply-To: <20130615155114.15420.62254.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.13.0.110805 x-originating-ip: [10.86.253.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] PCP Stability of External Address Recommendations X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 15 Jun 2013 19:32:45 -0000 On 6/15/13 12:51 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-penno-pcp-ext-addr-00.txt >has been successfully submitted by Reinaldo Penno and posted to the >IETF repository. > >Filename: draft-penno-pcp-ext-addr >Revision: 00 >Title: PCP Stability of External Address Recommendations >Creation date: 2013-06-15 >Group: Individual Submission >Number of pages: 6 >URL: =20 >http://www.ietf.org/internet-drafts/draft-penno-pcp-ext-addr-00.txt >Status: http://datatracker.ietf.org/doc/draft-penno-pcp-ext-addr >Htmlized: http://tools.ietf.org/html/draft-penno-pcp-ext-addr-00 > > >Abstract: > This document recommends PCP Server and client behavior in light of > Address Pooling Paired. > > > =20 > =20 > > >The IETF Secretariat > From internet-drafts@ietf.org Tue Jun 18 00:43:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AC021F9C65; Tue, 18 Jun 2013 00:43:10 -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.094, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5rFk+3vdzpy; Tue, 18 Jun 2013 00:43:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C503321F9AB2; Tue, 18 Jun 2013 00:43:09 -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.51.p2 Message-ID: <20130618074309.24619.2242.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 00:43:09 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 07:43:10 -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) Proxy Function Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-proxy-03.txt Pages : 11 Date : 2013-06-18 Abstract: This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-proxy-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cheshire@apple.com Tue Jun 18 15:04:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0CE21E80B7 for ; Tue, 18 Jun 2013 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv22ENdqLtzB for ; Tue, 18 Jun 2013 15:04:26 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id D24D321E80C8 for ; Tue, 18 Jun 2013 15:04:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOL0061AZYIU731@mail-out.apple.com> for pcp@ietf.org; Tue, 18 Jun 2013 15:04:22 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-9a-51c0d966a3a6 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 79.46.01734.669D0C15; Tue, 18 Jun 2013 15:04:22 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MOL006I7ZZ9EV00@spicerack.apple.com> for pcp@ietf.org; Tue, 18 Jun 2013 15:04:21 -0700 (PDT) Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. From: Stuart Cheshire In-reply-to: <8D23D4052ABE7A4490E77B1A012B6307751D764B@mbx-01.win.nominum.com> Date: Tue, 18 Jun 2013 15:04:21 -0700 Message-id: <96A646B1-4A25-4790-84FC-2A56D3D9BFD8@apple.com> References: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com> <94C682931C08B048B7A8645303FDC9F36ED4CD00B6@PUEXCB1B.nanterre.francetelecom.fr> <66190F1F-8C2D-400F-BF6B-5BCD60BD2B0F@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ECE62@PUEXCB1B.nanterre.francetelecom.fr> <77A24AFD-B3D1-4EDD-8FAF-FC6B177088E8@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED58ED224@PUEXCB1B.nanterre.francetelecom.fr> <7038F2ED-7AF4-4189-B4E3-C073B912089C@apple.com> <94C682931C08B048B7A8645303FDC9F36ED58ED736@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ED963981E@PUEXCB1B.nanterre.francetelecom.fr> <66451318-8D44-4462-91A7-FD28461349E2@apple.com> <94C682931C08B048B7A8645303FDC9F36ED9639B5D@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B6307751D5C02@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36ED9639FB6@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A44@apple.com> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCsoZt280Cgwf+/HBaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsezdYwFU7grri5qYm5g/MzRxcjJISFgIvG0Yw4ThC0mceHe erYuRi4OIYHJTBKHd/SxQzgrmCQ2/N3PClIlLBAg8alxHwuIzSygI9H7/RsziM0roCexecYL dogabYm3t2+B2WwCWhIvPl9hA7E5BfwkWhtvgdksAqoSM+cfY4KYoyqx6dppZghbW+LJuwtA uziAZtpILLlWBxIWEujnkGi7JQRiiwgoShzYdoMdpERCQFZi5++kCYyCs5AcNAvJQbOQDF3A yLyKUaAoNSex0kQvsaAgJ1UvOT93EyM4HAvDdzD+W2Z1iFGAg1GJh7dh5YFAIdbEsuLK3EOM EhzMSiK8f5qBQrwpiZVVqUX58UWlOanFhxilOViUxHkvnwVKCaQnlqRmp6YWpBbBZJk4OKUa GHcc9NRjuC9351mRqdu2fb+3HSnqiChdy7Dt6L2jv+OfHCrQ9LkTM/HvAp+L91YmRs75a1pW yzdxUuL7eZ+z87OSrRdz71nUZ3guZbuFt2/4soMLuEPC3XqjXkx9/LnUizFlURZv046HPyzl 97Nte7RfpUDVdyWvqoP6587CZsmjs3ezzp7SNV+JpTgj0VCLuag4EQB9MXsiQwIAAA== Subject: Re: [pcp] UNSUPP_FAMILY error code X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:04:33 -0000 On 14 Jun, 2013, at 04:40, Ted Lemon wrote: > Right, you are making an asymmetric assumption: that clients will be broken in the sense that they will not ask for a connection they could otherwise support, but will not be broken in the sense that they will not correctly support a connection the implementor didn't anticipate them getting. Good observation. A client could be broken in that it asks for IPv6, but actually only handles IPv4 replies. Now the question is, who should suffer in this case? (a) The client, which fails to get IPv4 until it is fixed to actually ask for what it wants, or (b) The gateway, which cannot offer IPv6 addresses until the broken clients get fixed. In case (a) the client vendor has a clear incentive to update their client so that it works. Effort and reward are aligned. In case (b) the gateway vendor has little leverage to get the client vendor to fix their client, but the gateway vendor feels the pain (the broken client "appears" to work with other gateways that don't support IPv6, and this new IPv6-capable gateway "appears" to break those existing "good" clients). The IPv4-only client vendor has has little economic justification to put out a costly software update just so that the gateway vendor can support this new IPv6 thing that the client doesn't even care about. Stuart Cheshire From sureshk@juniper.net Wed Jun 19 17:00:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B87621F8476 for ; Wed, 19 Jun 2013 17:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=1.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeD73GTxq9Tw for ; Wed, 19 Jun 2013 17:00:42 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBD621F9EDE for ; Wed, 19 Jun 2013 17:00:42 -0700 (PDT) Received: from mail180-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 00:00:41 +0000 Received: from mail180-co9 (localhost [127.0.0.1]) by mail180-co9-R.bigfish.com (Postfix) with ESMTP id A4E1AC803DC for ; Thu, 20 Jun 2013 00:00:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zzc85dhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail180-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=sureshk@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail180-co9 (localhost.localdomain [127.0.0.1]) by mail180-co9 (MessageSwitch) id 1371686386871130_13581; Wed, 19 Jun 2013 23:59:46 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.245]) by mail180-co9.bigfish.com (Postfix) with ESMTP id D25F3C000DC for ; Wed, 19 Jun 2013 23:59:46 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.51) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 23:59:45 +0000 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, 19 Jun 2013 16:59:44 -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; Wed, 19 Jun 2013 16:59:43 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Jun 2013 17:11:42 -0700 Received: from mail110-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Jun 2013 23:59:42 +0000 Received: from mail110-va3 (localhost [127.0.0.1]) by mail110-va3-R.bigfish.com (Postfix) with ESMTP id 1821030011B for ; Wed, 19 Jun 2013 23:59:42 +0000 (UTC) Received: from mail110-va3 (localhost.localdomain [127.0.0.1]) by mail110-va3 (MessageSwitch) id 1371686378652949_26682; Wed, 19 Jun 2013 23:59:38 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.239]) by mail110-va3.bigfish.com (Postfix) with ESMTP id 9B150E0059; Wed, 19 Jun 2013 23:59:38 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Jun 2013 23:59:31 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0324.000; Wed, 19 Jun 2013 23:59:31 +0000 From: Suresh Kumar Vinapamula Venkata To: "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRK Date: Wed, 19 Jun 2013 23:59:30 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: multipart/alternative; boundary="_000_CC261D3611209A47A6CB39B67375041C190B91EDBL2PRD0510MB349_" 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "fdupont@isc.org" Subject: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 00:00:53 -0000 --_000_CC261D3611209A47A6CB39B67375041C190B91EDBL2PRD0510MB349_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, An external IP address of the CPE device may change as and when DHCP lease = expires or when there is a reboot of CPE for any reason. Traffic destined from external world, to these mappings, may not reach inte= nded CPE, as there is change in external address. RFC 6887 recommends no host renumbering to handle it. However this is not sufficient in v6 environment especially with DS-Lite, w= here a CPE is assigned a v6prefix and is free to use any address with in th= e prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion i= s typically filled by CPE and typically with mac address, which changes whe= n there is a change in CPE device or for some reason. Since the end systems (Hosts behind CPE/B4, and the CGN box) has not reboot= ed, the mappings that were created before and the traffic destined to those= mappings if tunneled over to old B4 address would be dropped by the CPE de= vice. This also causes other inconvenience as these mappings hangs around till th= ey timeout(scaling impact and non usage of ports and memory) or, unless, a = packet faked with the old B4 address as source and a delete request is issu= ed. Even if those mappings are deleted in someway, a new set of mappings h= ave to be created and published for external world to connect, every time, = when such an event happens. This is a scenario, where end systems(hosts behind B4 and CGNAT device) are= not rebooted, but intermediate CPE device is rebooted. Since the end systems are not rebooted, can those mappings be migrated over= DS-Lite tunnels? There are two options here, to reuse these mappings. 1. The option is, create mappings and flows on per prefix. This way mapp= ings and flows are migrated to any address in the same prefix when ever the= re is change in address. The destination address to be used by the CGNAT bo= x, to tunnel packets over those mappings to the CPE should be the address l= ast seen by the CGNAT from the CPE of the prefix. This way, traffic over ma= ppings and flows created over old B4 address, can continue to reach intende= d host over the new DS-Lite tunnel. 2. CPE to accept packets destined to any address in that prefix. This ma= y be a generic stack change and may not be desirable. This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslit= e-00. Can this be included for the discussion? Please comment. -Suresh --_000_CC261D3611209A47A6CB39B67375041C190B91EDBL2PRD0510MB349_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, 

An external IP address of the CPE device ma= y change as and when DHCP lease expires or when there is a reboot of CPE fo= r any reason.
Traffic destined from external world, to these mappings, may not = reach intended CPE, as there is change in external address.
RFC 6887 recommends no host renumbering to = handle it.

However this is not sufficient in v6 enviro= nment especially with DS-Lite, where a CPE is assigned a v6prefix and is fr= ee to use any address with in the prefix. Though DHPCv6 may assign same pre= fix to a CPE, the host portion is typically filled by CPE and typically with mac address, which changes when= there is a change in CPE device or for some reason. 

Since the end systems (Hosts behind CPE/B4,= and the CGN box) has not rebooted, the mappings that were created before a= nd the traffic destined to those mappings if tunneled over to old B4 addres= s would be dropped by the CPE device. 

This also causes other inconvenience as the= se mappings hangs around till they timeout(scaling impact and non usage of = ports and memory) or, unless, a packet faked with the old B4 address as sou= rce and a delete request is issued. Even if those mappings are deleted  in someway, a new set of mappings= have to be created and published for external world to connect, every time= , when such an event happens.

This is a scenario, where end systems(hosts behind B4 and CGNAT = device) are not rebooted, but intermediate CPE device is rebooted. 

Since the end systems are not rebooted, can= those mappings be migrated over DS-Lite tunnels? 

There are two options here, to reuse these = mappings. 
  1. The option is, create mappings and flows on per prefix. This way mappin= gs and flows are migrated to any address in the same prefix when ever there= is change in address. The destination address to be used by the CGNAT box,= to tunnel packets over those mappings to the CPE should be the address last seen by the CGNAT from the CPE of th= e prefix. This way, traffic over mappings and flows created over old B4 add= ress, can continue to reach intended host over the new DS-Lite tunnel. = ;
  2. CPE to accept packets destined to any address in that prefix. Thi= s may be a generic stack change and may not be desirable.
This is not covered in http://trac.tools= .ietf.org/html/draft-ietf-pcp-dslite-00. Can this be included for the d= iscussion?

Please comment.

-Suresh
--_000_CC261D3611209A47A6CB39B67375041C190B91EDBL2PRD0510MB349_-- From mohamed.boucadair@orange.com Thu Jun 20 06:24:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF1021F9BD0 for ; Thu, 20 Jun 2013 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uqWdzHX8kCQ for ; Thu, 20 Jun 2013 06:24:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E8EBD21F9BCF for ; Thu, 20 Jun 2013 06:24:40 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7E00B18C15B; Thu, 20 Jun 2013 15:24:39 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5E54B4C07D; Thu, 20 Jun 2013 15:24:39 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 20 Jun 2013 15:24:39 +0200 From: To: Suresh Kumar Vinapamula Venkata , "pcp@ietf.org" Date: Thu, 20 Jun 2013 15:24:38 +0200 Thread-Topic: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB259315@PUEXCB1B.nanterre.francetelecom.fr> References: , In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EDB259315PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "mrw@painless-security.com" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:24:47 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EDB259315PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Suresh, FWIW, you may find some text describing this failure case at: http://tools.= ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Sures= h Kumar Vinapamula Venkata Envoy=E9 : jeudi 20 juin 2013 02:00 =C0 : pcp@ietf.org Cc : mrw@painless-security.com; fdupont@isc.org Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Hi, An external IP address of the CPE device may change as and when DHCP lease = expires or when there is a reboot of CPE for any reason. Traffic destined from external world, to these mappings, may not reach inte= nded CPE, as there is change in external address. RFC 6887 recommends no host renumbering to handle it. However this is not sufficient in v6 environment especially with DS-Lite, w= here a CPE is assigned a v6prefix and is free to use any address with in th= e prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion i= s typically filled by CPE and typically with mac address, which changes whe= n there is a change in CPE device or for some reason. Since the end systems (Hosts behind CPE/B4, and the CGN box) has not reboot= ed, the mappings that were created before and the traffic destined to those= mappings if tunneled over to old B4 address would be dropped by the CPE de= vice. This also causes other inconvenience as these mappings hangs around till th= ey timeout(scaling impact and non usage of ports and memory) or, unless, a = packet faked with the old B4 address as source and a delete request is issu= ed. Even if those mappings are deleted in someway, a new set of mappings h= ave to be created and published for external world to connect, every time, = when such an event happens. This is a scenario, where end systems(hosts behind B4 and CGNAT device) are= not rebooted, but intermediate CPE device is rebooted. Since the end systems are not rebooted, can those mappings be migrated over= DS-Lite tunnels? There are two options here, to reuse these mappings. 1. The option is, create mappings and flows on per prefix. This way mappi= ngs and flows are migrated to any address in the same prefix when ever ther= e is change in address. The destination address to be used by the CGNAT box= , to tunnel packets over those mappings to the CPE should be the address la= st seen by the CGNAT from the CPE of the prefix. This way, traffic over map= pings and flows created over old B4 address, can continue to reach intended= host over the new DS-Lite tunnel. 2. CPE to accept packets destined to any address in that prefix. This may= be a generic stack change and may not be desirable. This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslit= e-00. Can this be included for the discussion? Please comment. -Suresh --_000_94C682931C08B048B7A8645303FDC9F36EDB259315PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Suresh,

 

FWIW, you may find some text describing this failure case= at: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#secti= on-2.5.

 = ;

Cheers,=

Med

 

De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] = De la part de Suresh Kumar Vinapamula Venkata
Envoy=E9 := jeudi 20 juin 2013 02:00
=C0 : pcp@ietf.org
Cc := mrw@painless-security.com; fdupont@isc.org
Objet : [pcp= ] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

 

 

Hi,=  

<= div>

 

An ex= ternal IP address of the CPE device may change as and when DHCP lease expir= es or when there is a reboot of CPE for any reason.

Traffic destined from external world, to these map= pings, may not reach intended CPE, as there is change in external address.<= o:p>

RFC 6887 recommends no host renu= mbering to handle it.

=  = ;

However this is not sufficient in v= 6 environment especially with DS-Lite, where a CPE is assigned a v6prefix a= nd is free to use any address with in the prefix. Though DHPCv6 may assign = same prefix to a CPE, the host portion is typically filled by CPE and typic= ally with mac address, which changes when there is a change in CPE device o= r for some reason. 

&n= bsp;

Since the end systems (Hosts beh= ind CPE/B4, and the CGN box) has not rebooted, the mappings that were creat= ed before and the traffic destined to those mappings if tunneled over to ol= d B4 address would be dropped by the CPE device. 

 

Th= is also causes other inconvenience as these mappings hangs around till they= timeout(scaling impact and non usage of ports and memory) or, unless, a pa= cket faked with the old B4 address as source and a delete request is issued= . Even if those mappings are deleted  in someway, a new set of mapping= s have to be created and published for external world to connect, every tim= e, when such an event happens.

<= o:p> 

This is a scenario, where = end systems(hosts behind B4 and CGNAT device) are not rebooted, but interme= diate CPE device is rebooted. 

 

Since the end systems= are not rebooted, can those mappings be migrated over DS-Lite tunnels?&nbs= p;

 

<= /div>

There are two options here, to reuse these mappings.&n= bsp;

  1. The option is, create mappings and flows on per prefix. This way map= pings and flows are migrated to any address in the same prefix when ever th= ere is change in address. The destination address to be used by the CGNAT b= ox, to tunnel packets over those mappings to the CPE should be the address = last seen by the CGNAT from the CPE of the prefix. This way, traffic over m= appings and flows created over old B4 address, can continue to reach intend= ed host over the new DS-Lite tunnel. 
  2. CPE to accept packets destined to any address in that prefix. = This may be a generic stack change and may not be desirable.

This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can thi= s be included for the discussion?

 

Please comme= nt.

 

=

-Suresh

=
= --_000_94C682931C08B048B7A8645303FDC9F36EDB259315PUEXCB1Bnante_-- From sureshk@juniper.net Thu Jun 20 08:08:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794B21F9DEE for ; Thu, 20 Jun 2013 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t+Nb+wn026W for ; Thu, 20 Jun 2013 08:08:32 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE721F9BAA for ; Thu, 20 Jun 2013 08:07:18 -0700 (PDT) Received: from mail109-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 15:07:18 +0000 Received: from mail109-co9 (localhost [127.0.0.1]) by mail109-co9-R.bigfish.com (Postfix) with ESMTP id 444B64E0864 for ; Thu, 20 Jun 2013 15:07:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371Ic89bhc85dhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h8275bh8275dhz2fh2a8h683h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail109-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=sureshk@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail109-co9 (localhost.localdomain [127.0.0.1]) by mail109-co9 (MessageSwitch) id 1371740796808463_31913; Thu, 20 Jun 2013 15:06:36 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.225]) by mail109-co9.bigfish.com (Postfix) with ESMTP id ACBFE8005F for ; Thu, 20 Jun 2013 15:06:36 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 15:06:33 +0000 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; Thu, 20 Jun 2013 08:05:50 -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; Thu, 20 Jun 2013 08:05:49 -0700 Received: from CO9EHSOBE024.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 20 Jun 2013 08:09:18 -0700 Received: from mail99-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Jun 2013 15:05:49 +0000 Received: from mail99-co9 (localhost [127.0.0.1]) by mail99-co9-R.bigfish.com (Postfix) with ESMTP id 44B7A4A02BA for ; Thu, 20 Jun 2013 15:05:49 +0000 (UTC) Received: from mail99-co9 (localhost.localdomain [127.0.0.1]) by mail99-co9 (MessageSwitch) id 1371740745974973_10862; Thu, 20 Jun 2013 15:05:45 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.241]) by mail99-co9.bigfish.com (Postfix) with ESMTP id 09A66E008A; Thu, 20 Jun 2013 15:05:45 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Jun 2013 15:05:41 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0324.000; Thu, 20 Jun 2013 15:05:38 +0000 From: Suresh Kumar Vinapamula Venkata To: "mohamed.boucadair@orange.com" Thread-Topic: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYg== Date: Thu, 20 Jun 2013 15:05:37 +0000 Message-ID: <67D84203-2352-46A9-B160-DCAEDA8B2E2C@juniper.net> References: , , <94C682931C08B048B7A8645303FDC9F36EDB259315@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB259315@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.136.207.230] Content-Type: multipart/alternative; boundary="_000_67D84203235246A9B160DCAEDA8B2E2Cjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 15:08:40 -0000 --_000_67D84203235246A9B160DCAEDA8B2E2Cjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mohammed Please correct me if I am missing some thing. How can CGNAT know, whether t= he request is to refresh existing mappings or for new mappings when the CPE= address changed? Addresses behind B4 can overlap right? They have to rely on B4 address righ= t? Suresh On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" > wrote: Dear Suresh, FWIW, you may find some text describing this failure case at: http://tools.= ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] De la part de Suresh Kumar Vinapamula Venkata Envoy=E9 : jeudi 20 juin 2013 02:00 =C0 : pcp@ietf.org Cc : mrw@painless-security.com; fdupont@i= sc.org Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Hi, An external IP address of the CPE device may change as and when DHCP lease = expires or when there is a reboot of CPE for any reason. Traffic destined from external world, to these mappings, may not reach inte= nded CPE, as there is change in external address. RFC 6887 recommends no host renumbering to handle it. However this is not sufficient in v6 environment especially with DS-Lite, w= here a CPE is assigned a v6prefix and is free to use any address with in th= e prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion i= s typically filled by CPE and typically with mac address, which changes whe= n there is a change in CPE device or for some reason. Since the end systems (Hosts behind CPE/B4, and the CGN box) has not reboot= ed, the mappings that were created before and the traffic destined to those= mappings if tunneled over to old B4 address would be dropped by the CPE de= vice. This also causes other inconvenience as these mappings hangs around till th= ey timeout(scaling impact and non usage of ports and memory) or, unless, a = packet faked with the old B4 address as source and a delete request is issu= ed. Even if those mappings are deleted in someway, a new set of mappings h= ave to be created and published for external world to connect, every time, = when such an event happens. This is a scenario, where end systems(hosts behind B4 and CGNAT device) are= not rebooted, but intermediate CPE device is rebooted. Since the end systems are not rebooted, can those mappings be migrated over= DS-Lite tunnels? There are two options here, to reuse these mappings. 1. The option is, create mappings and flows on per prefix. This way mapp= ings and flows are migrated to any address in the same prefix when ever the= re is change in address. The destination address to be used by the CGNAT bo= x, to tunnel packets over those mappings to the CPE should be the address l= ast seen by the CGNAT from the CPE of the prefix. This way, traffic over ma= ppings and flows created over old B4 address, can continue to reach intende= d host over the new DS-Lite tunnel. 2. CPE to accept packets destined to any address in that prefix. This ma= y be a generic stack change and may not be desirable. This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslit= e-00. Can this be included for the discussion? Please comment. -Suresh --_000_67D84203235246A9B160DCAEDA8B2E2Cjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mohammed

Please correct me if I am missing some thing. How can CGNAT know, whet= her the request is to refresh existing mappings or for new mappings when th= e CPE address changed?  
Addresses behind B4 can overlap right? They have to rely on B4 address= right?

Suresh

On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

Dear Suresh,

 

FWIW, you may find some text = describing this failure case at: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.= 5.

 

Cheers,

Med

 

De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Suresh Kumar Vinapamula Venkata
Envoy=E9 : jeudi 20 juin 2013 02:00
=C0 : pcp@ietf.org
Cc : mrw@painless-= security.com; fdupont@isc.org
Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lit= e Handling)

 

 

Hi, =

 

An external IP address of the CPE device may change as and whe= n DHCP lease expires or when there is a reboot of CPE for any reason.<= /o:p>

Traffic destined from external world, to these mappings, = may not reach intended CPE, as there is change in external address.

RFC 6887 recommends no host renumbering to handle it.

 

However this is not sufficient in v6 environment especially wi= th DS-Lite, where a CPE is assigned a v6prefix and is free to use any addre= ss with in the prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion is typically filled by C= PE and typically with mac address, which changes when there is a change in = CPE device or for some reason. 

 

Since the end systems (Hosts behind CPE/B4, and the CGN box) h= as not rebooted, the mappings that were created before and the traffic dest= ined to those mappings if tunneled over to old B4 address would be dropped by the CPE device. 

 

This also causes other inconvenience as these mappings hangs a= round till they timeout(scaling impact and non usage of ports and memory) o= r, unless, a packet faked with the old B4 address as source and a delete request is issued. Even if those mapping= s are deleted  in someway, a new set of mappings have to be created an= d published for external world to connect, every time, when such an event h= appens.

 

This is a scenario, where end systems(hosts behind B4 and CGNA= T device) are not rebooted, but intermediate CPE device is rebooted. <= o:p>

 

Since the end systems are not rebooted, can those mappings be = migrated over DS-Lite tunnels? 

 

There are two options here, to reuse these mappings. 

  1. The option is, create = mappings and flows on per prefix. This way mappings and flows are migrated = to any address in the same prefix when ever there is change in address. The= destination address to be used by the CGNAT box, to tunnel packets over those mappings to the CPE should be = the address last seen by the CGNAT from the CPE of the prefix. This way, tr= affic over mappings and flows created over old B4 address, can continue to = reach intended host over the new DS-Lite tunnel. 
  2. CPE to accept packets = destined to any address in that prefix. This may be a generic stack change = and may not be desirable.

This is not covered in http://trac.tools.ietf= .org/html/draft-ietf-pcp-dslite-00. Can this be included for the discussion?

 

Please comment.

 

-Suresh

--_000_67D84203235246A9B160DCAEDA8B2E2Cjunipernet_-- From mohamed.boucadair@orange.com Fri Jun 21 02:03:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0721F9D06 for ; Fri, 21 Jun 2013 02:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vWTi7Fqqbau for ; Fri, 21 Jun 2013 02:02: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 1E7A011E80D9 for ; Fri, 21 Jun 2013 02:02:48 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B23C22DD363; Fri, 21 Jun 2013 11:02:47 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 94630238059; Fri, 21 Jun 2013 11:02:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 21 Jun 2013 11:02:47 +0200 From: To: Suresh Kumar Vinapamula Venkata Date: Fri, 21 Jun 2013 11:02:45 +0200 Thread-Topic: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsA Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB2595DF@PUEXCB1B.nanterre.francetelecom.fr> References: , , <94C682931C08B048B7A8645303FDC9F36EDB259315@PUEXCB1B.nanterre.francetelecom.fr> <67D84203-2352-46A9-B160-DCAEDA8B2E2C@juniper.net> In-Reply-To: <67D84203-2352-46A9-B160-DCAEDA8B2E2C@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EDB2595DFPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 09:03:03 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EDB2595DFPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suresh, If a new address is assigned to the B4, the co-located PCP client will need= to re-install the mappings it manages. This will be seen by the PCP server= as new requests if the PCP Client IP Address is not already in use in tabl= e or refresh mappings otherwise. In both cases, there is a failure risk due= to the presence of stale mappings. You can check: http://tools.ietf.org/ht= ml/draft-boucadair-pcp-failure-06#section-2.4 Cheers, Med De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] Envoy=E9 : jeudi 20 juin 2013 17:06 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Hi Mohammed Please correct me if I am missing some thing. How can CGNAT know, whether t= he request is to refresh existing mappings or for new mappings when the CPE= address changed? Addresses behind B4 can overlap right? They have to rely on B4 address righ= t? Suresh On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" > wrote: Dear Suresh, FWIW, you may find some text describing this failure case at: http://tools.= ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@= ietf.org] De la part de Suresh Kumar Vinapamula Venkata Envoy=E9 : jeudi 20 juin 2013 02:00 =C0 : pcp@ietf.org Cc : mrw@painless-security.com; fdupont@i= sc.org Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Hi, An external IP address of the CPE device may change as and when DHCP lease = expires or when there is a reboot of CPE for any reason. Traffic destined from external world, to these mappings, may not reach inte= nded CPE, as there is change in external address. RFC 6887 recommends no host renumbering to handle it. However this is not sufficient in v6 environment especially with DS-Lite, w= here a CPE is assigned a v6prefix and is free to use any address with in th= e prefix. Though DHPCv6 may assign same prefix to a CPE, the host portion i= s typically filled by CPE and typically with mac address, which changes whe= n there is a change in CPE device or for some reason. Since the end systems (Hosts behind CPE/B4, and the CGN box) has not reboot= ed, the mappings that were created before and the traffic destined to those= mappings if tunneled over to old B4 address would be dropped by the CPE de= vice. This also causes other inconvenience as these mappings hangs around till th= ey timeout(scaling impact and non usage of ports and memory) or, unless, a = packet faked with the old B4 address as source and a delete request is issu= ed. Even if those mappings are deleted in someway, a new set of mappings h= ave to be created and published for external world to connect, every time, = when such an event happens. This is a scenario, where end systems(hosts behind B4 and CGNAT device) are= not rebooted, but intermediate CPE device is rebooted. Since the end systems are not rebooted, can those mappings be migrated over= DS-Lite tunnels? There are two options here, to reuse these mappings. 1. The option is, create mappings and flows on per prefix. This way mappi= ngs and flows are migrated to any address in the same prefix when ever ther= e is change in address. The destination address to be used by the CGNAT box= , to tunnel packets over those mappings to the CPE should be the address la= st seen by the CGNAT from the CPE of the prefix. This way, traffic over map= pings and flows created over old B4 address, can continue to reach intended= host over the new DS-Lite tunnel. 2. CPE to accept packets destined to any address in that prefix. This may= be a generic stack change and may not be desirable. This is not covered in http://trac.tools.ietf.org/html/draft-ietf-pcp-dslit= e-00. Can this be included for the discussion? Please comment. -Suresh --_000_94C682931C08B048B7A8645303FDC9F36EDB2595DFPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Suresh,

 

If a new address is assigned to the B4= , the co-located PCP client will need to re-install the mappings it manages= . This will be seen by the PCP server as new requests if the PCP Client IP = Address is not already in use in table or refresh mappings otherwise. In bo= th cases, there is a failure risk due to the presence of stale mappings. Yo= u can check: http://tools.ietf.org/html/draft-boucadair-pcp-failure-= 06#section-2.4

 

Che= ers,

Med

 

De : Suresh Kumar Vinap= amula Venkata [mailto:sureshk@juniper.net]
Envoy=E9 : jeudi= 20 juin 2013 17:06
=C0 : BOUCADAIR Mohamed OLNC/OLN
C= c : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org
Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Ha= ndling)

 

Hi Mohammed

 

Pleas= e correct me if I am missing some thing. How can CGNAT know, whether the re= quest is to refresh existing mappings or for new mappings when the CPE addr= ess changed?  

Addresses= behind B4 can overlap right? They have to rely on B4 address right?

 

Suresh


On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com&q= uot; <mohamed.boucadair@= orange.com> wrote:

Dear Suresh,

 

http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#sectio= n-2.5.

 

Cheers,<= /p>

Med

De : pcp-bounces@ie= tf.org [mailto:pcp-bounces@ietf= .org] De la part de Suresh Kumar Vinapamula Venkata
Envoy= =E9 : jeudi 20 juin 2013 02:00
=C0 : pcp@ietf.org
Cc : mrw@painless-security.com; fdupont@isc.org
Objet : [pcp] Comments o= n draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling)

 

 

Hi, 

 

An external IP address of the CPE device may change = as and when DHCP lease expires or when there is a reboot of CPE for any rea= son.

Traffic destined from exter= nal world, to these mappings, may not reach intended CPE, as there is = change in external address.

RFC = 6887 recommends no host renumbering to handle it.

 

However= this is not sufficient in v6 environment especially with DS-Lite, where a = CPE is assigned a v6prefix and is free to use any address with in the prefi= x. Though DHPCv6 may assign same prefix to a CPE, the host portion is typic= ally filled by CPE and typically with mac address, which changes when there= is a change in CPE device or for some reason. 

<= /div>

 

Sinc= e the end systems (Hosts behind CPE/B4, and the CGN box) has not rebooted, = the mappings that were created before and the traffic destined to those map= pings if tunneled over to old B4 address would be dropped by the CPE device= . 

 =

This also causes other inconvenience as these map= pings hangs around till they timeout(scaling impact and non usage of ports = and memory) or, unless, a packet faked with the old B4 address as source an= d a delete request is issued. Even if those mappings are deleted  in s= omeway, a new set of mappings have to be created and published for external= world to connect, every time, when such an event happens.

 

This is a scenario, where end systems(hosts behind B4 and CGNAT device) = are not rebooted, but intermediate CPE device is rebooted. 

 

Since the end systems are not rebooted, can those mappings be migra= ted over DS-Lite tunnels? 

=  

There are two options her= e, to reuse these mappings. 

  1. The option is, create mappings and flow= s on per prefix. This way mappings and flows are migrated to any address in= the same prefix when ever there is change in address. The destination addr= ess to be used by the CGNAT box, to tunnel packets over those mappings to t= he CPE should be the address last seen by the CGNAT from the CPE of the pre= fix. This way, traffic over mappings and flows created over old B4 address,= can continue to reach intended host over the new DS-Lite tunnel. 
  2. CPE to accept packets destined to= any address in that prefix. This may be a generic stack change and may not= be desirable.

This = is not covered in http://trac.tools.ietf.org/html/draft-ie= tf-pcp-dslite-00. Can this be included for the discussion?<= /o:p>

 

=

Please comment.

=  

-Suresh=

= --_000_94C682931C08B048B7A8645303FDC9F36EDB2595DFPUEXCB1Bnante_-- From dwing@cisco.com Fri Jun 21 15:55:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533CB21F9DA3 for ; Fri, 21 Jun 2013 15:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.939 X-Spam-Level: X-Spam-Status: No, score=-109.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFm+BZP930pD for ; Fri, 21 Jun 2013 15:55:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC421F9E81 for ; Fri, 21 Jun 2013 15:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4937; q=dns/txt; s=iport; t=1371855306; x=1373064906; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1/ftTRRd+GCyMe155Tcxs20oPnJ26gwUZ8TZTWv1usk=; b=WG1X5zqRUwHx7Lb5bcnt+ctdJ6ms/nv3pUChg4uf0g/a+Ryq0MyhhJDe VtiZ0WfCMBXOWaR0Hogs+mnHnqc5wtmHw6qrUtnkCXJESiP4NgpBGD1Ft sUlfiHt8wQo+KNrSR+Puu8mZrN3xGuE1oMWllEDCl8ViTjwK1R2l3QMPn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAK3YxFGrRDoI/2dsb2JhbABbgwkxv36BAxZ0giMBAQEDAQEBAWsLBQsLGCcHJx8RGYgIBQ28I48WMweDAGEDiSGOIoEpkBuDLxw X-IronPort-AV: E=Sophos;i="4.87,916,1363132800"; d="scan'208";a="84032335" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 21 Jun 2013 22:55:04 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5LMt2V4022277; Fri, 21 Jun 2013 22:55:02 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB2595DF@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 21 Jun 2013 15:55:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: , , <94C682931C08B048B7A8645303FDC9F36EDB259315@PUEXCB1B.nanterre.francetelecom.fr> <67D84203-2352-46A9-B160-DCAEDA8B2E2C@juniper.net> <94C682931C08B048B7A8645303FDC9F36EDB2595DF@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:55:13 -0000 On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: > Hi Suresh, > =20 > If a new address is assigned to the B4, the co-located PCP client will = need to re-install the mappings it manages. When a new address is assigned to the B4, the B4's PCP server should = follow the procedures in "Address Change Events", = http://tools.ietf.org/html/rfc6887#section-11.5. The host which created = the mappings (the PCP client) needs to be aware of the address change to = update the information in the rendezvous server (DNS, SIP, XMPP, = whatever), which means the B4's PCP server isn't helping things by = updating mappings on the CGN by itself. -d > This will be seen by the PCP server as new requests if the PCP Client = IP Address is not already in use in table or refresh mappings otherwise. = In both cases, there is a failure risk due to the presence of stale = mappings. You can check: = http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4 > =20 > Cheers, > Med > =20 > De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]=20 > Envoy=E9 : jeudi 20 juin 2013 17:06 > =C0 : BOUCADAIR Mohamed OLNC/OLN > Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org > Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite = Handling) > =20 > Hi Mohammed > =20 > Please correct me if I am missing some thing. How can CGNAT know, = whether the request is to refresh existing mappings or for new mappings = when the CPE address changed? =20 > Addresses behind B4 can overlap right? They have to rely on B4 address = right? > =20 > Suresh >=20 > On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" = wrote: >=20 > Dear Suresh, > =20 > FWIW, you may find some text describing this failure case = at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5. > =20 > Cheers, > Med > =20 > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de = Suresh Kumar Vinapamula Venkata > Envoy=E9 : jeudi 20 juin 2013 02:00 > =C0 : pcp@ietf.org > Cc : mrw@painless-security.com; fdupont@isc.org > Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite = Handling) > =20 > =20 > Hi,=20 > =20 > An external IP address of the CPE device may change as and when DHCP = lease expires or when there is a reboot of CPE for any reason. > Traffic destined from external world, to these mappings, may not reach = intended CPE, as there is change in external address. > RFC 6887 recommends no host renumbering to handle it. > =20 > However this is not sufficient in v6 environment especially with = DS-Lite, where a CPE is assigned a v6prefix and is free to use any = address with in the prefix. Though DHPCv6 may assign same prefix to a = CPE, the host portion is typically filled by CPE and typically with mac = address, which changes when there is a change in CPE device or for some = reason.=20 > =20 > Since the end systems (Hosts behind CPE/B4, and the CGN box) has not = rebooted, the mappings that were created before and the traffic destined = to those mappings if tunneled over to old B4 address would be dropped by = the CPE device.=20 > =20 > This also causes other inconvenience as these mappings hangs around = till they timeout(scaling impact and non usage of ports and memory) or, = unless, a packet faked with the old B4 address as source and a delete = request is issued. Even if those mappings are deleted in someway, a new = set of mappings have to be created and published for external world to = connect, every time, when such an event happens. > =20 > This is a scenario, where end systems(hosts behind B4 and CGNAT = device) are not rebooted, but intermediate CPE device is rebooted.=20 > =20 > Since the end systems are not rebooted, can those mappings be migrated = over DS-Lite tunnels?=20 > =20 > There are two options here, to reuse these mappings.=20 > =95 The option is, create mappings and flows on per prefix. This = way mappings and flows are migrated to any address in the same prefix = when ever there is change in address. The destination address to be used = by the CGNAT box, to tunnel packets over those mappings to the CPE = should be the address last seen by the CGNAT from the CPE of the prefix. = This way, traffic over mappings and flows created over old B4 address, = can continue to reach intended host over the new DS-Lite tunnel.=20 > =95 CPE to accept packets destined to any address in that = prefix. This may be a generic stack change and may not be desirable. > This is not covered in = http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this be = included for the discussion? > =20 > Please comment. > =20 > -Suresh > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From sureshk@juniper.net Fri Jun 21 17:37:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7701821F9A40 for ; Fri, 21 Jun 2013 17:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.586 X-Spam-Level: X-Spam-Status: No, score=0.586 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iod92jHj8RKk for ; Fri, 21 Jun 2013 17:37:28 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4E21F9A25 for ; Fri, 21 Jun 2013 17:37:28 -0700 (PDT) Received: from mail161-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE032.bigfish.com (10.243.66.97) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 00:37:27 +0000 Received: from mail161-co1 (localhost [127.0.0.1]) by mail161-co1-R.bigfish.com (Postfix) with ESMTP id 34C9B9201E7 for ; Sat, 22 Jun 2013 00:37:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic89bh148cI1432I168aJzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail161-co1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=sureshk@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail161-co1 (localhost.localdomain [127.0.0.1]) by mail161-co1 (MessageSwitch) id 1371861445168575_8145; Sat, 22 Jun 2013 00:37:25 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.240]) by mail161-co1.bigfish.com (Postfix) with ESMTP id 26F8F1A020E for ; Sat, 22 Jun 2013 00:37:25 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Jun 2013 00:37:25 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 17:37:24 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 17:37:23 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 17:40:47 -0700 Received: from mail72-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 00:37:20 +0000 Received: from mail72-ch1 (localhost [127.0.0.1]) by mail72-ch1-R.bigfish.com (Postfix) with ESMTP id D5FB86019E for ; Sat, 22 Jun 2013 00:37:20 +0000 (UTC) Received: from mail72-ch1 (localhost.localdomain [127.0.0.1]) by mail72-ch1 (MessageSwitch) id 1371861437382648_14932; Sat, 22 Jun 2013 00:37:17 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail72-ch1.bigfish.com (Postfix) with ESMTP id 4FB312E0069; Sat, 22 Jun 2013 00:37:17 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Jun 2013 00:37:17 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0324.000; Sat, 22 Jun 2013 00:37:16 +0000 From: Suresh Kumar Vinapamula Venkata To: Dan Wing , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gA== Date: Sat, 22 Jun 2013 00:37:15 +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.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: 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%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 00:37:45 -0000 Hi Mohamed/Dan,=20 Thanks for pointing to the drafts. I understand from the drafts that if a CPE is assigned a same IP address after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE request to the PCP clients. This way, PCP clients would refresh their mappings. Suppose prefix say 3001::/56 is assigned to CPE after reboot and is same as before reboot. Suppose IPv6 address before reboot is 3001::a and created some mappings. However, after a reboot, a new IPv6 address may be taken as B4 say 3001::b.=20 As per the current drafts, clients will try to refresh mappings with the newly assigned IPv6 address as the B4 address. Since the requests are from the different IPv6 address, CGNAT will try to create new mappings and the old mappings have to age out. Now hosts using these mappings have to publish these mappings, for external hosts to connect right? This is an overhead. My point is, this over head can be eliminated when there is a change in address in the prefix, why do we need to force creation of new mappings and timeout of old mappings? Instead, can the mappings and the corresponding traffic be migrated to newer B4?=20 If the same address is acquired by the B4 after reboot, CGNAT box doesn't differentiate right? I am suggesting can this be extended to prefix, such that any mappings created over one B4 address of the prefix be migrated to another B4 address within the same prefix? If there is a change in prefix, there is no option to migrate as mentioned, new mappings have to be created and old mappings have to expire.=20 Address change with in a prefix can be handled more gracefully right? Am I missing something? -Suresh On 6/21/13 3:55 PM, "Dan Wing" wrote: > >On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: > >> Hi Suresh, >> =20 >> If a new address is assigned to the B4, the co-located PCP client will >>need to re-install the mappings it manages. > >When a new address is assigned to the B4, the B4's PCP server should >follow the procedures in "Address Change Events", >http://tools.ietf.org/html/rfc6887#section-11.5. The host which created >the mappings (the PCP client) needs to be aware of the address change to >update the information in the rendezvous server (DNS, SIP, XMPP, >whatever), which means the B4's PCP server isn't helping things by >updating mappings on the CGN by itself. > >-d > > >> This will be seen by the PCP server as new requests if the PCP Client >>IP Address is not already in use in table or refresh mappings otherwise. >>In both cases, there is a failure risk due to the presence of stale >>mappings. You can check: >>http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4 >> =20 >> Cheers, >> Med >> =20 >> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >> Envoy=E9 : jeudi 20 juin 2013 17:06 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) >> =20 >> Hi Mohammed >> =20 >> Please correct me if I am missing some thing. How can CGNAT know, >>whether the request is to refresh existing mappings or for new mappings >>when the CPE address changed? >> Addresses behind B4 can overlap right? They have to rely on B4 address >>right? >> =20 >> Suresh >>=20 >> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >> wrote: >>=20 >> Dear Suresh, >> =20 >> FWIW, you may find some text describing this failure case >>at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5. >> =20 >> Cheers, >> Med >> =20 >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >>Suresh Kumar Vinapamula Venkata >> Envoy=E9 : jeudi 20 juin 2013 02:00 >> =C0 : pcp@ietf.org >> Cc : mrw@painless-security.com; fdupont@isc.org >> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>Handling) >> =20 >> =20 >> Hi,=20 >> =20 >> An external IP address of the CPE device may change as and when DHCP >>lease expires or when there is a reboot of CPE for any reason. >> Traffic destined from external world, to these mappings, may not reach >>intended CPE, as there is change in external address. >> RFC 6887 recommends no host renumbering to handle it. >> =20 >> However this is not sufficient in v6 environment especially with >>DS-Lite, where a CPE is assigned a v6prefix and is free to use any >>address with in the prefix. Though DHPCv6 may assign same prefix to a >>CPE, the host portion is typically filled by CPE and typically with mac >>address, which changes when there is a change in CPE device or for some >>reason.=20 >> =20 >> Since the end systems (Hosts behind CPE/B4, and the CGN box) has not >>rebooted, the mappings that were created before and the traffic destined >>to those mappings if tunneled over to old B4 address would be dropped by >>the CPE device.=20 >> =20 >> This also causes other inconvenience as these mappings hangs around >>till they timeout(scaling impact and non usage of ports and memory) or, >>unless, a packet faked with the old B4 address as source and a delete >>request is issued. Even if those mappings are deleted in someway, a new >>set of mappings have to be created and published for external world to >>connect, every time, when such an event happens. >> =20 >> This is a scenario, where end systems(hosts behind B4 and CGNAT device) >>are not rebooted, but intermediate CPE device is rebooted. >> =20 >> Since the end systems are not rebooted, can those mappings be migrated >>over DS-Lite tunnels? >> =20 >> There are two options here, to reuse these mappings. >> =80 The option is, create mappings and flows on per prefix. This way >>mappings and flows are migrated to any address in the same prefix when >>ever there is change in address. The destination address to be used by >>the CGNAT box, to tunnel packets over those mappings to the CPE should >>be the address last seen by the CGNAT from the CPE of the prefix. This >>way, traffic over mappings and flows created over old B4 address, can >>continue to reach intended host over the new DS-Lite tunnel. >> =80 CPE to accept packets destined to any address in that prefix. This >>may be a generic stack change and may not be desirable. >> This is not covered in >>http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this be >>included for the discussion? >> =20 >> Please comment. >> =20 >> -Suresh >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > > From repenno@cisco.com Fri Jun 21 18:16:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7361F0D35 for ; Fri, 21 Jun 2013 18:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.656 X-Spam-Level: X-Spam-Status: No, score=-9.656 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wquEpPelV-6K for ; Fri, 21 Jun 2013 18:16:45 -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 962D521F94D3 for ; Fri, 21 Jun 2013 18:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10268; q=dns/txt; s=iport; t=1371863805; x=1373073405; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=D86oil9+isI8aGFCMTuYH0cYCqqXKxiel+DP1kz9wJo=; b=ZbF52WUA3kwStnukak0h1WO/2QFVskxKm3kkSdP7SiOICWzE//T2Fgdz Sn9R9Cpz14VwDhSLyAIUdZ8VCTMvaN7sXzO1fyoEfuCl8rKbwq6lfdE97 M7g/v3Janed/nfja8hM+gu1WWqS282xE1TG8Flr2ACGVKtTq8nhBX7ouS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAGz6xFGtJXG//2dsb2JhbABbgwkxSYMDvDYNdRZ0giMBAQEEAQEBIBE6CxIBCBgCAgYdAwIEJQsUARACBAENBQiIBgyqcZEWgSaNcAIxB4JNM2EDmGyQG4MPgig X-IronPort-AV: E=Sophos;i="4.87,916,1363132800"; d="scan'208";a="226013867" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jun 2013 01:16:43 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5M1GhwW021468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Jun 2013 01:16:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 20:16:42 -0500 From: "Reinaldo Penno (repenno)" To: Suresh Kumar Vinapamula Venkata , "Dan Wing (dwing)" , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObuC65vAiBS138kWSwhBqkqKfOJlBEBEA Date: Sat, 22 Jun 2013 01:16:42 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090ADDA9@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.245.115] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 01:16:50 -0000 SXQgc2VlbXMgeW91IGFyZSBzdWdnZXN0aW5nIGEgcGVyIHByZWZpeCBiaW5kaW5nLiBTbywgaW4g eW91ciBleGFtcGxlIGlmDQppbnRlcm5hbCBob3N0IDEwLjAuMC4yIHNlbmRzIGEgbmV3IE1BUCBy ZXF1ZXN0IHRoYXQgdXNlcyAzMDAxOmIgYXMgc291cmNlDQphZGRyZXNzLCB0aGUgQUZUUiBzaG91 bGQgdXBkYXRlIGFueSBleGlzdGluZyBtYXBwaW5ncyB0byB1c2UgdGhpcyBuZXcNCnNvdXJjZSBJ UHY2IHRvIHJlYWNoIHRoZSBCNCB3aGlsZSBleHRlcm5hbCBwdWJsaWMgSVA6cG9ydCB3b3VsZCBi ZSB0aGUNCnNhbWUuIFRoZXJlZm9yZSBubyBuZWVkIHRvIHVwZGF0ZSBkeW5ETlMgb3Igb3RoZXIg c3R1ZmYuDQoNCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCB0aGlzIGlzIGludGVyZXN0 aW5nLg0KDQpPbiA2LzIxLzEzIDk6MzcgUE0sICJTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5r YXRhIg0KPHN1cmVzaGtAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgTW9oYW1lZC9EYW4sIA0K Pg0KPlRoYW5rcyBmb3IgcG9pbnRpbmcgdG8gdGhlIGRyYWZ0cy4NCj5JIHVuZGVyc3RhbmQgZnJv bSB0aGUgZHJhZnRzIHRoYXQgaWYgYSBDUEUgaXMgYXNzaWduZWQgYSBzYW1lIElQIGFkZHJlc3MN Cj5hZnRlciByZWJvb3QsIGluIGNhc2Ugb2YgRFMtTGl0ZSwgUENQIHByb3h5IHNob3VsZCBzZW5k IEFOTk9VTkNFIHJlcXVlc3QNCj50byB0aGUgUENQIGNsaWVudHMuDQo+VGhpcyB3YXksIFBDUCBj bGllbnRzIHdvdWxkIHJlZnJlc2ggdGhlaXIgbWFwcGluZ3MuDQo+DQo+U3VwcG9zZSBwcmVmaXgg c2F5IDMwMDE6Oi81NiBpcyBhc3NpZ25lZCB0byBDUEUgYWZ0ZXIgcmVib290IGFuZCBpcyBzYW1l DQo+YXMgYmVmb3JlIHJlYm9vdC4NCj5TdXBwb3NlIElQdjYgYWRkcmVzcyBiZWZvcmUgcmVib290 IGlzIDMwMDE6OmEgYW5kIGNyZWF0ZWQgc29tZSBtYXBwaW5ncy4NCj4NCj5Ib3dldmVyLCBhZnRl ciBhIHJlYm9vdCwgYSBuZXcgSVB2NiBhZGRyZXNzIG1heSBiZSB0YWtlbiBhcyBCNCBzYXkNCj4z MDAxOjpiLiANCj5BcyBwZXIgdGhlIGN1cnJlbnQgZHJhZnRzLCBjbGllbnRzIHdpbGwgdHJ5IHRv IHJlZnJlc2ggbWFwcGluZ3Mgd2l0aCB0aGUNCj5uZXdseSBhc3NpZ25lZCBJUHY2IGFkZHJlc3Mg YXMgdGhlIEI0IGFkZHJlc3MuDQo+U2luY2UgdGhlIHJlcXVlc3RzIGFyZSBmcm9tIHRoZSBkaWZm ZXJlbnQgSVB2NiBhZGRyZXNzLCBDR05BVCB3aWxsIHRyeSB0bw0KPmNyZWF0ZSBuZXcgbWFwcGlu Z3MgYW5kIHRoZSBvbGQgbWFwcGluZ3MgaGF2ZSB0byBhZ2Ugb3V0Lg0KPk5vdyBob3N0cyB1c2lu ZyB0aGVzZSBtYXBwaW5ncyBoYXZlIHRvIHB1Ymxpc2ggdGhlc2UgbWFwcGluZ3MsIGZvcg0KPmV4 dGVybmFsIGhvc3RzIHRvIGNvbm5lY3QgcmlnaHQ/IFRoaXMgaXMgYW4gb3ZlcmhlYWQuDQo+DQo+ TXkgcG9pbnQgaXMsIHRoaXMgb3ZlciBoZWFkIGNhbiBiZSBlbGltaW5hdGVkIHdoZW4gdGhlcmUg aXMgYSBjaGFuZ2UgaW4NCj5hZGRyZXNzIGluIHRoZSBwcmVmaXgsIHdoeSBkbyB3ZSBuZWVkIHRv IGZvcmNlIGNyZWF0aW9uIG9mIG5ldyBtYXBwaW5ncw0KPmFuZCB0aW1lb3V0IG9mIG9sZCBtYXBw aW5ncz8NCj5JbnN0ZWFkLCBjYW4gdGhlIG1hcHBpbmdzIGFuZCB0aGUgY29ycmVzcG9uZGluZyB0 cmFmZmljIGJlIG1pZ3JhdGVkIHRvDQo+bmV3ZXIgQjQ/IA0KPklmIHRoZSBzYW1lIGFkZHJlc3Mg aXMgYWNxdWlyZWQgYnkgdGhlIEI0IGFmdGVyIHJlYm9vdCwgQ0dOQVQgYm94IGRvZXNuJ3QNCj5k aWZmZXJlbnRpYXRlIHJpZ2h0PyBJIGFtIHN1Z2dlc3RpbmcgY2FuIHRoaXMgYmUgZXh0ZW5kZWQg dG8gcHJlZml4LCBzdWNoDQo+dGhhdCBhbnkgbWFwcGluZ3MgY3JlYXRlZCBvdmVyIG9uZSBCNCBh ZGRyZXNzIG9mIHRoZSBwcmVmaXggYmUgbWlncmF0ZWQgdG8NCj5hbm90aGVyIEI0IGFkZHJlc3Mg d2l0aGluIHRoZSBzYW1lIHByZWZpeD8NCj4NCj5JZiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBwcmVm aXgsIHRoZXJlIGlzIG5vIG9wdGlvbiB0byBtaWdyYXRlIGFzDQo+bWVudGlvbmVkLCBuZXcgbWFw cGluZ3MgaGF2ZSB0byBiZSBjcmVhdGVkIGFuZCBvbGQgbWFwcGluZ3MgaGF2ZSB0bw0KPmV4cGly ZS4gDQo+QWRkcmVzcyBjaGFuZ2Ugd2l0aCBpbiBhIHByZWZpeCBjYW4gYmUgaGFuZGxlZCBtb3Jl IGdyYWNlZnVsbHkgcmlnaHQ/IEFtIEkNCj5taXNzaW5nIHNvbWV0aGluZz8NCj4NCj4tU3VyZXNo DQo+DQo+DQo+DQo+T24gNi8yMS8xMyAzOjU1IFBNLCAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5j b20+IHdyb3RlOg0KPg0KPj4NCj4+T24gSnVuIDIxLCAyMDEzLCBhdCAyOjAyIEFNLCBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4NCj4+PiBIaSBTdXJlc2gsDQo+Pj4gIA0K Pj4+IElmIGEgbmV3IGFkZHJlc3MgaXMgYXNzaWduZWQgdG8gdGhlIEI0LCB0aGUgY28tbG9jYXRl ZCBQQ1AgY2xpZW50IHdpbGwNCj4+Pm5lZWQgdG8gcmUtaW5zdGFsbCB0aGUgbWFwcGluZ3MgaXQg bWFuYWdlcy4NCj4+DQo+PldoZW4gYSBuZXcgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byB0aGUgQjQs IHRoZSBCNCdzIFBDUCBzZXJ2ZXIgc2hvdWxkDQo+PmZvbGxvdyB0aGUgcHJvY2VkdXJlcyBpbiAi QWRkcmVzcyBDaGFuZ2UgRXZlbnRzIiwNCj4+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njg4NyNzZWN0aW9uLTExLjUuICBUaGUgaG9zdCB3aGljaCBjcmVhdGVkDQo+PnRoZSBtYXBwaW5n cyAodGhlIFBDUCBjbGllbnQpIG5lZWRzIHRvIGJlIGF3YXJlIG9mIHRoZSBhZGRyZXNzIGNoYW5n ZSB0bw0KPj51cGRhdGUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSByZW5kZXp2b3VzIHNlcnZlciAo RE5TLCBTSVAsIFhNUFAsDQo+PndoYXRldmVyKSwgd2hpY2ggbWVhbnMgdGhlIEI0J3MgUENQIHNl cnZlciBpc24ndCBoZWxwaW5nIHRoaW5ncyBieQ0KPj51cGRhdGluZyBtYXBwaW5ncyBvbiB0aGUg Q0dOIGJ5IGl0c2VsZi4NCj4+DQo+Pi1kDQo+Pg0KPj4NCj4+PiBUaGlzIHdpbGwgYmUgc2VlbiBi eSB0aGUgUENQIHNlcnZlciBhcyBuZXcgcmVxdWVzdHMgaWYgdGhlIFBDUCBDbGllbnQNCj4+PklQ IEFkZHJlc3MgaXMgbm90IGFscmVhZHkgaW4gdXNlIGluIHRhYmxlIG9yIHJlZnJlc2ggbWFwcGlu Z3Mgb3RoZXJ3aXNlLg0KPj4+SW4gYm90aCBjYXNlcywgdGhlcmUgaXMgYSBmYWlsdXJlIHJpc2sg ZHVlIHRvIHRoZSBwcmVzZW5jZSBvZiBzdGFsZQ0KPj4+bWFwcGluZ3MuIFlvdSBjYW4gY2hlY2s6 DQo+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItcGNwLWZhaWx1 cmUtMDYjc2VjdGlvbi0yLjQNCj4+PiAgDQo+Pj4gQ2hlZXJzLA0KPj4+IE1lZA0KPj4+ICANCj4+ PiBEZSA6IFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGEgW21haWx0bzpzdXJlc2hrQGp1 bmlwZXIubmV0XQ0KPj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMgMTc6MDYNCj4+PiDD gCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Pj4gQ2MgOiBwY3BAaWV0Zi5vcmc7IG1y d0BwYWlubGVzcy1zZWN1cml0eS5jb207IGZkdXBvbnRAaXNjLm9yZw0KPj4+IE9iamV0IDogUmU6 IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlDQo+Pj5I YW5kbGluZykNCj4+PiAgDQo+Pj4gSGkgTW9oYW1tZWQNCj4+PiAgDQo+Pj4gUGxlYXNlIGNvcnJl Y3QgbWUgaWYgSSBhbSBtaXNzaW5nIHNvbWUgdGhpbmcuIEhvdyBjYW4gQ0dOQVQga25vdywNCj4+ PndoZXRoZXIgdGhlIHJlcXVlc3QgaXMgdG8gcmVmcmVzaCBleGlzdGluZyBtYXBwaW5ncyBvciBm b3IgbmV3IG1hcHBpbmdzDQo+Pj53aGVuIHRoZSBDUEUgYWRkcmVzcyBjaGFuZ2VkPw0KPj4+IEFk ZHJlc3NlcyBiZWhpbmQgQjQgY2FuIG92ZXJsYXAgcmlnaHQ/IFRoZXkgaGF2ZSB0byByZWx5IG9u IEI0IGFkZHJlc3MNCj4+PnJpZ2h0Pw0KPj4+ICANCj4+PiBTdXJlc2gNCj4+PiANCj4+PiBPbiBK dW4gMjAsIDIwMTMsIGF0IDY6MjUgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0K Pj4+PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IERlYXIg U3VyZXNoLA0KPj4+ICANCj4+PiBGV0lXLCB5b3UgbWF5IGZpbmQgc29tZSB0ZXh0IGRlc2NyaWJp bmcgdGhpcyBmYWlsdXJlIGNhc2UNCj4+PmF0Omh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJvdWNhZGFpci1wY3AtZmFpbHVyZS0wNiNzZWN0aW9uLTIuNQ0KPj4+Lg0KPj4+ICANCj4+ PiBDaGVlcnMsDQo+Pj4gTWVkDQo+Pj4gIA0KPj4+IERlIDogcGNwLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpwY3AtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPj4+U3VyZXNoIEt1 bWFyIFZpbmFwYW11bGEgVmVua2F0YQ0KPj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMg MDI6MDANCj4+PiDDgCA6IHBjcEBpZXRmLm9yZw0KPj4+IENjIDogbXJ3QHBhaW5sZXNzLXNlY3Vy aXR5LmNvbTsgZmR1cG9udEBpc2Mub3JnDQo+Pj4gT2JqZXQgOiBbcGNwXSBDb21tZW50cyBvbiBk cmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIChQQ1AgRFMtTGl0ZQ0KPj4+SGFuZGxpbmcpDQo+Pj4g IA0KPj4+ICANCj4+PiBIaSwgDQo+Pj4gIA0KPj4+IEFuIGV4dGVybmFsIElQIGFkZHJlc3Mgb2Yg dGhlIENQRSBkZXZpY2UgbWF5IGNoYW5nZSBhcyBhbmQgd2hlbiBESENQDQo+Pj5sZWFzZSBleHBp cmVzIG9yIHdoZW4gdGhlcmUgaXMgYSByZWJvb3Qgb2YgQ1BFIGZvciBhbnkgcmVhc29uLg0KPj4+ IFRyYWZmaWMgZGVzdGluZWQgZnJvbSBleHRlcm5hbCB3b3JsZCwgdG8gdGhlc2UgbWFwcGluZ3Ms IG1heSBub3QgcmVhY2gNCj4+PmludGVuZGVkIENQRSwgYXMgdGhlcmUgaXMgY2hhbmdlIGluIGV4 dGVybmFsIGFkZHJlc3MuDQo+Pj4gUkZDIDY4ODcgcmVjb21tZW5kcyBubyBob3N0IHJlbnVtYmVy aW5nIHRvIGhhbmRsZSBpdC4NCj4+PiAgDQo+Pj4gSG93ZXZlciB0aGlzIGlzIG5vdCBzdWZmaWNp ZW50IGluIHY2IGVudmlyb25tZW50IGVzcGVjaWFsbHkgd2l0aA0KPj4+RFMtTGl0ZSwgd2hlcmUg YSBDUEUgaXMgYXNzaWduZWQgYSB2NnByZWZpeCBhbmQgaXMgZnJlZSB0byB1c2UgYW55DQo+Pj5h ZGRyZXNzIHdpdGggaW4gdGhlIHByZWZpeC4gVGhvdWdoIERIUEN2NiBtYXkgYXNzaWduIHNhbWUg cHJlZml4IHRvIGENCj4+PkNQRSwgdGhlIGhvc3QgcG9ydGlvbiBpcyB0eXBpY2FsbHkgZmlsbGVk IGJ5IENQRSBhbmQgdHlwaWNhbGx5IHdpdGggbWFjDQo+Pj5hZGRyZXNzLCB3aGljaCBjaGFuZ2Vz IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgaW4gQ1BFIGRldmljZSBvciBmb3Igc29tZQ0KPj4+cmVh c29uLiANCj4+PiAgDQo+Pj4gU2luY2UgdGhlIGVuZCBzeXN0ZW1zIChIb3N0cyBiZWhpbmQgQ1BF L0I0LCBhbmQgdGhlIENHTiBib3gpIGhhcyBub3QNCj4+PnJlYm9vdGVkLCB0aGUgbWFwcGluZ3Mg dGhhdCB3ZXJlIGNyZWF0ZWQgYmVmb3JlIGFuZCB0aGUgdHJhZmZpYyBkZXN0aW5lZA0KPj4+dG8g dGhvc2UgbWFwcGluZ3MgaWYgdHVubmVsZWQgb3ZlciB0byBvbGQgQjQgYWRkcmVzcyB3b3VsZCBi ZSBkcm9wcGVkIGJ5DQo+Pj50aGUgQ1BFIGRldmljZS4gDQo+Pj4gIA0KPj4+IFRoaXMgYWxzbyBj YXVzZXMgb3RoZXIgaW5jb252ZW5pZW5jZSBhcyB0aGVzZSBtYXBwaW5ncyBoYW5ncyBhcm91bmQN Cj4+PnRpbGwgdGhleSB0aW1lb3V0KHNjYWxpbmcgaW1wYWN0IGFuZCBub24gdXNhZ2Ugb2YgcG9y dHMgYW5kIG1lbW9yeSkgb3IsDQo+Pj51bmxlc3MsIGEgcGFja2V0IGZha2VkIHdpdGggdGhlIG9s ZCBCNCBhZGRyZXNzIGFzIHNvdXJjZSBhbmQgYSBkZWxldGUNCj4+PnJlcXVlc3QgaXMgaXNzdWVk LiBFdmVuIGlmIHRob3NlIG1hcHBpbmdzIGFyZSBkZWxldGVkICBpbiBzb21ld2F5LCBhIG5ldw0K Pj4+c2V0IG9mIG1hcHBpbmdzIGhhdmUgdG8gYmUgY3JlYXRlZCBhbmQgcHVibGlzaGVkIGZvciBl eHRlcm5hbCB3b3JsZCB0bw0KPj4+Y29ubmVjdCwgZXZlcnkgdGltZSwgd2hlbiBzdWNoIGFuIGV2 ZW50IGhhcHBlbnMuDQo+Pj4gIA0KPj4+IFRoaXMgaXMgYSBzY2VuYXJpbywgd2hlcmUgZW5kIHN5 c3RlbXMoaG9zdHMgYmVoaW5kIEI0IGFuZCBDR05BVCBkZXZpY2UpDQo+Pj5hcmUgbm90IHJlYm9v dGVkLCBidXQgaW50ZXJtZWRpYXRlIENQRSBkZXZpY2UgaXMgcmVib290ZWQuDQo+Pj4gIA0KPj4+ IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyBhcmUgbm90IHJlYm9vdGVkLCBjYW4gdGhvc2UgbWFwcGlu Z3MgYmUgbWlncmF0ZWQNCj4+Pm92ZXIgRFMtTGl0ZSB0dW5uZWxzPw0KPj4+ICANCj4+PiBUaGVy ZSBhcmUgdHdvIG9wdGlvbnMgaGVyZSwgdG8gcmV1c2UgdGhlc2UgbWFwcGluZ3MuDQo+Pj4gCeKC rCBUaGUgb3B0aW9uIGlzLCBjcmVhdGUgbWFwcGluZ3MgYW5kIGZsb3dzIG9uIHBlciBwcmVmaXgu IFRoaXMgd2F5DQo+Pj5tYXBwaW5ncyBhbmQgZmxvd3MgYXJlIG1pZ3JhdGVkIHRvIGFueSBhZGRy ZXNzIGluIHRoZSBzYW1lIHByZWZpeCB3aGVuDQo+Pj5ldmVyIHRoZXJlIGlzIGNoYW5nZSBpbiBh ZGRyZXNzLiBUaGUgZGVzdGluYXRpb24gYWRkcmVzcyB0byBiZSB1c2VkIGJ5DQo+Pj50aGUgQ0dO QVQgYm94LCB0byB0dW5uZWwgcGFja2V0cyBvdmVyIHRob3NlIG1hcHBpbmdzIHRvIHRoZSBDUEUg c2hvdWxkDQo+Pj5iZSB0aGUgYWRkcmVzcyBsYXN0IHNlZW4gYnkgdGhlIENHTkFUIGZyb20gdGhl IENQRSBvZiB0aGUgcHJlZml4LiBUaGlzDQo+Pj53YXksIHRyYWZmaWMgb3ZlciBtYXBwaW5ncyBh bmQgZmxvd3MgY3JlYXRlZCBvdmVyIG9sZCBCNCBhZGRyZXNzLCBjYW4NCj4+PmNvbnRpbnVlIHRv IHJlYWNoIGludGVuZGVkIGhvc3Qgb3ZlciB0aGUgbmV3IERTLUxpdGUgdHVubmVsLg0KPj4+IAni gqwgQ1BFIHRvIGFjY2VwdCBwYWNrZXRzIGRlc3RpbmVkIHRvIGFueSBhZGRyZXNzIGluIHRoYXQg cHJlZml4LiBUaGlzDQo+Pj5tYXkgYmUgYSBnZW5lcmljIHN0YWNrIGNoYW5nZSBhbmQgbWF5IG5v dCBiZSBkZXNpcmFibGUuDQo+Pj4gVGhpcyBpcyBub3QgY292ZXJlZCBpbg0KPj4+aHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIENhbiB0aGlz IGJlDQo+Pj5pbmNsdWRlZCBmb3IgdGhlIGRpc2N1c3Npb24/DQo+Pj4gIA0KPj4+IFBsZWFzZSBj b21tZW50Lg0KPj4+ICANCj4+PiAtU3VyZXNoDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBwY3AgbWFpbGluZyBsaXN0DQo+Pj4gcGNwQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3ANCj4+ DQo+Pg0KPj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPnBjcCBtYWlsaW5nIGxpc3QNCj5wY3BAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KDQo= From dwing@cisco.com Fri Jun 21 19:08:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B7421F9C75 for ; Fri, 21 Jun 2013 19:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.605 X-Spam-Level: X-Spam-Status: No, score=-109.605 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpsl5ufdtLv3 for ; Fri, 21 Jun 2013 19:08:43 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D860E21F9C71 for ; Fri, 21 Jun 2013 19:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8893; q=dns/txt; s=iport; t=1371866923; x=1373076523; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OGgbUN2L9lg+pJDyQuTc6FEs7BIMBKPtefjd8USd/J4=; b=DriH25o5T4owK8bOgs0cx/PbVwJOIFy972pZfiwlADS8pcSrHIOdufyw uE4bqvADiaRIMEuQaoGx6Jh/GsnO2JGinSuvxMT6VLSAxOfNcWVqGG7Ix F+jv9Tt1MZqCsQk+ml3tErdwjkrfYp8OqgoeglbgBfK9gPSEeaM8iGOMi 4=; X-IronPort-AV: E=Sophos;i="4.87,916,1363132800"; d="scan'208";a="81532617" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2013 02:08:43 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5M28f81025333; Sat, 22 Jun 2013 02:08:41 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090ADDA9@xmb-rcd-x04.cisco.com> Date: Fri, 21 Jun 2013 19:08:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F0604090ADDA9@xmb-rcd-x04.cisco.com> To: "Reinaldo Penno (repenno)" X-Mailer: Apple Mail (2.1508) Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 02:08:48 -0000 On Jun 21, 2013, at 6:16 PM, "Reinaldo Penno (repenno)" = wrote: > It seems you are suggesting a per prefix binding. So, in your example = if > internal host 10.0.0.2 sends a new MAP request that uses 3001:b as = source > address, the AFTR should update any existing mappings to use this new > source IPv6 to reach the B4 while external public IP:port would be the > same. Therefore no need to update dynDNS or other stuff. >=20 > If my understanding is correct this is interesting. Thanks for summarizing - I understand the proposal now. It seems to = require the B4 and the AFTR know that the same IPv4 mapping is available = after IPv6 renumbering -- specifically that the same AFTR is being used = and it will assign the same IPv4 address to the B4. Seems a lot of = coordination between the B4 and AFTR to avoid updating a rendezvous = server. However, the host (and the B4) will always need to be able to = handle network renumbering where the same IPv4 mapping is not available, = so this increases implementation and testing effort. The gain, in my = mind, is pretty small especially considering the IP renumbering has to = be infrequent (or else TCP sessions are disrupted, nobody much = appreciates that). -d >=20 > On 6/21/13 9:37 PM, "Suresh Kumar Vinapamula Venkata" > wrote: >=20 >> Hi Mohamed/Dan,=20 >>=20 >> Thanks for pointing to the drafts. >> I understand from the drafts that if a CPE is assigned a same IP = address >> after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE = request >> to the PCP clients. >> This way, PCP clients would refresh their mappings. >>=20 >> Suppose prefix say 3001::/56 is assigned to CPE after reboot and is = same >> as before reboot. >> Suppose IPv6 address before reboot is 3001::a and created some = mappings. >>=20 >> However, after a reboot, a new IPv6 address may be taken as B4 say >> 3001::b.=20 >> As per the current drafts, clients will try to refresh mappings with = the >> newly assigned IPv6 address as the B4 address. >> Since the requests are from the different IPv6 address, CGNAT will = try to >> create new mappings and the old mappings have to age out. >> Now hosts using these mappings have to publish these mappings, for >> external hosts to connect right? This is an overhead. >>=20 >> My point is, this over head can be eliminated when there is a change = in >> address in the prefix, why do we need to force creation of new = mappings >> and timeout of old mappings? >> Instead, can the mappings and the corresponding traffic be migrated = to >> newer B4?=20 >> If the same address is acquired by the B4 after reboot, CGNAT box = doesn't >> differentiate right? I am suggesting can this be extended to prefix, = such >> that any mappings created over one B4 address of the prefix be = migrated to >> another B4 address within the same prefix? >>=20 >> If there is a change in prefix, there is no option to migrate as >> mentioned, new mappings have to be created and old mappings have to >> expire.=20 >> Address change with in a prefix can be handled more gracefully right? = Am I >> missing something? >>=20 >> -Suresh >>=20 >>=20 >>=20 >> On 6/21/13 3:55 PM, "Dan Wing" wrote: >>=20 >>>=20 >>> On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: >>>=20 >>>> Hi Suresh, >>>>=20 >>>> If a new address is assigned to the B4, the co-located PCP client = will >>>> need to re-install the mappings it manages. >>>=20 >>> When a new address is assigned to the B4, the B4's PCP server should >>> follow the procedures in "Address Change Events", >>> http://tools.ietf.org/html/rfc6887#section-11.5. The host which = created >>> the mappings (the PCP client) needs to be aware of the address = change to >>> update the information in the rendezvous server (DNS, SIP, XMPP, >>> whatever), which means the B4's PCP server isn't helping things by >>> updating mappings on the CGN by itself. >>>=20 >>> -d >>>=20 >>>=20 >>>> This will be seen by the PCP server as new requests if the PCP = Client >>>> IP Address is not already in use in table or refresh mappings = otherwise. >>>> In both cases, there is a failure risk due to the presence of stale >>>> mappings. You can check: >>>> = http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4 >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>>> Envoy=E9 : jeudi 20 juin 2013 17:06 >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >>>> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>> Handling) >>>>=20 >>>> Hi Mohammed >>>>=20 >>>> Please correct me if I am missing some thing. How can CGNAT know, >>>> whether the request is to refresh existing mappings or for new = mappings >>>> when the CPE address changed? >>>> Addresses behind B4 can overlap right? They have to rely on B4 = address >>>> right? >>>>=20 >>>> Suresh >>>>=20 >>>> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >>>> wrote: >>>>=20 >>>> Dear Suresh, >>>>=20 >>>> FWIW, you may find some text describing this failure case >>>> = at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.5 >>>> . >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part = de >>>> Suresh Kumar Vinapamula Venkata >>>> Envoy=E9 : jeudi 20 juin 2013 02:00 >>>> =C0 : pcp@ietf.org >>>> Cc : mrw@painless-security.com; fdupont@isc.org >>>> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>> Handling) >>>>=20 >>>>=20 >>>> Hi,=20 >>>>=20 >>>> An external IP address of the CPE device may change as and when = DHCP >>>> lease expires or when there is a reboot of CPE for any reason. >>>> Traffic destined from external world, to these mappings, may not = reach >>>> intended CPE, as there is change in external address. >>>> RFC 6887 recommends no host renumbering to handle it. >>>>=20 >>>> However this is not sufficient in v6 environment especially with >>>> DS-Lite, where a CPE is assigned a v6prefix and is free to use any >>>> address with in the prefix. Though DHPCv6 may assign same prefix to = a >>>> CPE, the host portion is typically filled by CPE and typically with = mac >>>> address, which changes when there is a change in CPE device or for = some >>>> reason.=20 >>>>=20 >>>> Since the end systems (Hosts behind CPE/B4, and the CGN box) has = not >>>> rebooted, the mappings that were created before and the traffic = destined >>>> to those mappings if tunneled over to old B4 address would be = dropped by >>>> the CPE device.=20 >>>>=20 >>>> This also causes other inconvenience as these mappings hangs around >>>> till they timeout(scaling impact and non usage of ports and memory) = or, >>>> unless, a packet faked with the old B4 address as source and a = delete >>>> request is issued. Even if those mappings are deleted in someway, = a new >>>> set of mappings have to be created and published for external world = to >>>> connect, every time, when such an event happens. >>>>=20 >>>> This is a scenario, where end systems(hosts behind B4 and CGNAT = device) >>>> are not rebooted, but intermediate CPE device is rebooted. >>>>=20 >>>> Since the end systems are not rebooted, can those mappings be = migrated >>>> over DS-Lite tunnels? >>>>=20 >>>> There are two options here, to reuse these mappings. >>>> =80 The option is, create mappings and flows on per prefix. This = way >>>> mappings and flows are migrated to any address in the same prefix = when >>>> ever there is change in address. The destination address to be used = by >>>> the CGNAT box, to tunnel packets over those mappings to the CPE = should >>>> be the address last seen by the CGNAT from the CPE of the prefix. = This >>>> way, traffic over mappings and flows created over old B4 address, = can >>>> continue to reach intended host over the new DS-Lite tunnel. >>>> =80 CPE to accept packets destined to any address in that = prefix. This >>>> may be a generic stack change and may not be desirable. >>>> This is not covered in >>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this = be >>>> included for the discussion? >>>>=20 >>>> Please comment. >>>>=20 >>>> -Suresh >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From sureshk@juniper.net Fri Jun 21 21:32:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685DE11E80CC for ; Fri, 21 Jun 2013 21:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWPIjzrri6FR for ; Fri, 21 Jun 2013 21:32:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 94B7311E80AE for ; Fri, 21 Jun 2013 21:32:36 -0700 (PDT) Received: from mail128-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 04:32:35 +0000 Received: from mail128-ch1 (localhost [127.0.0.1]) by mail128-ch1-R.bigfish.com (Postfix) with ESMTP id B74E92000A7 for ; Sat, 22 Jun 2013 04:32:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic89bh148cI1432I168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h683h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail128-ch1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=sureshk@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail128-ch1 (localhost.localdomain [127.0.0.1]) by mail128-ch1 (MessageSwitch) id 1371875553495035_2394; Sat, 22 Jun 2013 04:32:33 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail128-ch1.bigfish.com (Postfix) with ESMTP id 6C5FD40065 for ; Sat, 22 Jun 2013 04:32:33 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Jun 2013 04:32:33 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 21 Jun 2013 21:32:32 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 21 Jun 2013 21:32:31 -0700 Received: from DB8EHSOBE008.bigfish.com (213.199.154.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 21 Jun 2013 21:35:52 -0700 Received: from mail143-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE008.bigfish.com (10.174.4.71) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 04:32:25 +0000 Received: from mail143-db8 (localhost [127.0.0.1]) by mail143-db8-R.bigfish.com (Postfix) with ESMTP id 4D58EE0152 for ; Sat, 22 Jun 2013 04:32:25 +0000 (UTC) Received: from mail143-db8 (localhost.localdomain [127.0.0.1]) by mail143-db8 (MessageSwitch) id 1371875542330961_27071; Sat, 22 Jun 2013 04:32:22 +0000 (UTC) Received: from DB8EHSMHS009.bigfish.com (unknown [10.174.8.244]) by mail143-db8.bigfish.com (Postfix) with ESMTP id 42B3280044; Sat, 22 Jun 2013 04:32:22 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS009.bigfish.com (10.174.4.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 22 Jun 2013 04:32:22 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0324.000; Sat, 22 Jun 2013 04:32:20 +0000 From: Suresh Kumar Vinapamula Venkata To: Dan Wing , "Reinaldo Penno (repenno)" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAAgGEAgAAOhoD//7LFAA== Date: Sat, 22 Jun 2013 04:32:19 +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.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="utf-8" Content-ID: <2BA2BD9517CE9843BD7385E01BC516F3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 04:32:42 -0000 WWVzIFJlaW5hbGRvLCB0aGF0IGlzIGNvcnJlY3QuDQoNCkRhbiwgDQoNCk5vdGUsIGl0IGlzIHRo ZSBDUEUgdGhhdCByZWJvb3RlZCBvciB3ZW50IGJhZCBhbmQgc28gY2hhbmdlZC4NCkVuZCBzeXN0 ZW1zIGFyZSBub3QgcmVib290ZWQuDQoNCldpdGggbm8gcmVudW1iZXJpbmcgQ1BFIGlzIGFzc2ln bmVkIHNhbWUgdjYgcHJlZml4IDMwMDE6Oi4NCkRlcGVuZGluZyBvbiB0aGUgYWxnb3JpdGhtIHRv IGZpbGwgaW4gdGhlIGhvc3QgcG9ydGlvbiBmb3JtaW5nIGEgQjQNCnByZWZpeCwgYSBuZXcgQjQg YWRkcmVzcyAzMDAxOjpiIGNhbiBiZSBwaWNrZWQgd2hpY2ggaXMgZGlmZmVyZW50IGZyb20gb2xk DQpCNCBhZGRyZXNzIDMwMDE6OmEuDQoNClNpbmNlIHRoZSBlbmQgc3lzdGVtcyAxMC4wLjAuMiBo YXZlbid0IHJlYm9vdGVkLCB0aGV5IHNob3VsZCBiZSBhYmxlIHRvDQpjb250aW51ZSB1c2luZyB0 aG9zZSBtYXBwaW5ncy4gV2hlbiBob3N0cyBiZWhpbmQgQjQgc2VlcyBBTk5PVU5DRSwgYW5kDQpz ZW5kcyByZWZyZXNoIHJlcXVlc3RzLCBpdCB3b3VsZCBub3QgcmVzdWx0IGluIGNyZWF0aW5nIGEg bmV3IG1hcHBpbmcgYnV0DQp1c2UgZXhpc3RpbmcgbWFwcGluZy4gVGhlIGJlbmVmaXQsIGhvc3Rz IGJlaGluZCBCNCBkb24ndCBuZWVkIHRvIHB1Ymxpc2gNCnRvIGV4dGVybmFsIHdvcmxkIGFib3V0 IHRoZSBjaGFuZ2UsIHRvIHJlY2VpdmUgdHJhZmZpYyBmcm9tIGV4dGVybmFsIHdvcmxkLg0KDQpD b25zaWRlciBhIGNhc2Ugd2hlcmUgYW4gSVB2NiBhZGRyZXNzIGlzIGFzc2lnbmVkIGFuZCBub3Qg cHJlZml4IHRvIHRoZQ0KQ1BFLg0KSWYgdGhlIHNhbWUgSVB2NiBhZGRyZXNzIGFzc2lnbmVkIGFm dGVyIHJlYm9vdCBvciBjaGFuZ2Ugb2YgQ1BFLCBob3N0cyBvbg0Kc2VlaW5nIFBDUCBBTk5PVU5D RSwgd2hlbiByZWZyZXNoZXMgdGhlaXIgbWFwcGluZ3MsIFBDUCBzZXJ2ZXIgcmVzcG9uc2VzDQpi YWNrIHdpdGggdGhlIGV4aXN0aW5nIG1hcHBpbmcsIGl0IGlzIG5vdCBnb2luZyB0byBjcmVhdGUg bmV3IHNldCBvZg0KbWFwcGluZ3MgYW5kIGFnZSBvdXQgZXhpc3RpbmcgbWFwcGluZ3MgcmlnaHQ/ DQoNCkkgYW0gZXh0ZW5kaW5nIHRoZSBzYW1lIGFyZ3VtZW50IHRvIHByZWZpeGVzLCB3aGVyZSBD UEVzIGFyZSBhc3NpZ25lZCB3aXRoDQpwcmVmaXhlcyBhbmQgYXJlIGZyZWUgdG8gdXNlIGFueSB2 NiBhZGRyZXNzIGluIHRoZSBwcmVmaXggYXMgQjQgYWRkcmVzcy4NClNvLCBjaGFuZ2UgaW4gdGhh dCBhZGRyZXNzIHNob3VsZCBub3QgcmVzdWx0IGluIGNyZWF0aW5nIG5ldyBtYXBwaW5ncyBhbmQN CmFnZSBvdXQgb2xkIG1hcHBpbmdzLg0KDQpTdXBwb3NlIGlmIHdlIGdvIHdpdGggdGhlIGFwcHJv YWNoIGRlZmluZWQgaW4gdGhlIGRyYWZ0cyB3aGVyZSBuZXcNCm1hcHBpbmdzIGhhdmUgdG8gYmUg Y3JlYXRlZCB3aGVuIHRoZXJlIGlzIGNoYW5nZSBpbiBhZGRyZXNzLCBhcyBhbg0KYXR0YWNrZXIs IEkgY2FuIGV4aGF1c3QgQ0dOQVQvUENQIHNlcnZlciByZXNvdXJjZXMsIGJ5IHBpY2tpbmcgbXVs dGlwbGUNCklQdjYgYWRkcmVzc2VzIHdpdGggaW4gdGhlIGFzc2lnbmVkIHByZWZpeCBhcyBCNCBh bmQgZmFraW5nIFBDUCByZXF1ZXN0cy4NCg0KSWYgd2UgbGltaXQgdGhlIHJlc291cmNlcyBvbiBw ZXIgcHJlZml4IGJhc2VzIG9uIENHTkFUL1BDUCwgdGhlbiBhcyBhDQpnZW51aW5lIHVzZXIgd2hl biB0aGVyZSBpcyBhIGNoYW5nZSBpbiBCNCBhZGRyZXNzLCBJIHdpbGwgbm90IGJlIGFibGUgdG8N CmNyZWF0ZSBhbmQgdXNlIGFsbCBteSBxdW90YSBvZiBtYXBwaW5ncywgYXMgdGhlcmUgd291bGQg YmUgc29tZSBzdGFsZQ0KbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgbXkgQjQgY2hhbmdlIGVhdGlu ZyBteSBxdW90YS4gQW5kIHRoZSB0cmFmZmljDQpkZXN0aW5lZCB0byB0aG9zZSBtYXBwaW5ncyBm cm9tIGludGVybmV0IHdvdWxkIGJlIHByb2Nlc3NlZCBieSBDR05BVCBib3gNCm9ubHkgdG8gYmUg ZHJvcHBlZCBhdCBDUEUhDQoNClBsZWFzZSBjb21tZW50Lg0KDQpTdXJlc2gNCg0KDQpPbiA2LzIx LzEzIDc6MDggUE0sICJEYW4gV2luZyIgPGR3aW5nQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj4NCj5P biBKdW4gMjEsIDIwMTMsIGF0IDY6MTYgUE0sICJSZWluYWxkbyBQZW5ubyAocmVwZW5ubykiDQo+ PHJlcGVubm9AY2lzY28uY29tPiB3cm90ZToNCj4NCj4+IEl0IHNlZW1zIHlvdSBhcmUgc3VnZ2Vz dGluZyBhIHBlciBwcmVmaXggYmluZGluZy4gU28sIGluIHlvdXIgZXhhbXBsZSBpZg0KPj4gaW50 ZXJuYWwgaG9zdCAxMC4wLjAuMiBzZW5kcyBhIG5ldyBNQVAgcmVxdWVzdCB0aGF0IHVzZXMgMzAw MTpiIGFzDQo+PnNvdXJjZQ0KPj4gYWRkcmVzcywgdGhlIEFGVFIgc2hvdWxkIHVwZGF0ZSBhbnkg ZXhpc3RpbmcgbWFwcGluZ3MgdG8gdXNlIHRoaXMgbmV3DQo+PiBzb3VyY2UgSVB2NiB0byByZWFj aCB0aGUgQjQgd2hpbGUgZXh0ZXJuYWwgcHVibGljIElQOnBvcnQgd291bGQgYmUgdGhlDQo+PiBz YW1lLiBUaGVyZWZvcmUgbm8gbmVlZCB0byB1cGRhdGUgZHluRE5TIG9yIG90aGVyIHN0dWZmLg0K Pj4gDQo+PiBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QgdGhpcyBpcyBpbnRlcmVzdGlu Zy4NCj4NCj5UaGFua3MgZm9yIHN1bW1hcml6aW5nIC0gSSB1bmRlcnN0YW5kIHRoZSBwcm9wb3Nh bCBub3cuICBJdCBzZWVtcyB0bw0KPnJlcXVpcmUgdGhlIEI0IGFuZCB0aGUgQUZUUiBrbm93IHRo YXQgdGhlIHNhbWUgSVB2NCBtYXBwaW5nIGlzIGF2YWlsYWJsZQ0KPmFmdGVyIElQdjYgcmVudW1i ZXJpbmcgLS0gc3BlY2lmaWNhbGx5IHRoYXQgdGhlIHNhbWUgQUZUUiBpcyBiZWluZyB1c2VkDQo+ YW5kIGl0IHdpbGwgYXNzaWduIHRoZSBzYW1lIElQdjQgYWRkcmVzcyB0byB0aGUgQjQuICBTZWVt cyBhIGxvdCBvZg0KPmNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSBCNCBhbmQgQUZUUiB0byBhdm9p ZCB1cGRhdGluZyBhIHJlbmRlenZvdXMNCj5zZXJ2ZXIuICBIb3dldmVyLCB0aGUgaG9zdCAoYW5k IHRoZSBCNCkgd2lsbCBhbHdheXMgbmVlZCB0byBiZSBhYmxlIHRvDQo+aGFuZGxlIG5ldHdvcmsg cmVudW1iZXJpbmcgd2hlcmUgdGhlIHNhbWUgSVB2NCBtYXBwaW5nIGlzIG5vdCBhdmFpbGFibGUs DQo+c28gdGhpcyBpbmNyZWFzZXMgaW1wbGVtZW50YXRpb24gYW5kIHRlc3RpbmcgZWZmb3J0LiAg VGhlIGdhaW4sIGluIG15DQo+bWluZCwgaXMgcHJldHR5IHNtYWxsIGVzcGVjaWFsbHkgY29uc2lk ZXJpbmcgdGhlIElQIHJlbnVtYmVyaW5nIGhhcyB0byBiZQ0KPmluZnJlcXVlbnQgKG9yIGVsc2Ug VENQIHNlc3Npb25zIGFyZSBkaXNydXB0ZWQsIG5vYm9keSBtdWNoIGFwcHJlY2lhdGVzDQo+dGhh dCkuDQo+DQo+LWQNCj4NCj4NCj4+IA0KPj4gT24gNi8yMS8xMyA5OjM3IFBNLCAiU3VyZXNoIEt1 bWFyIFZpbmFwYW11bGEgVmVua2F0YSINCj4+IDxzdXJlc2hrQGp1bmlwZXIubmV0PiB3cm90ZToN Cj4+IA0KPj4+IEhpIE1vaGFtZWQvRGFuLA0KPj4+IA0KPj4+IFRoYW5rcyBmb3IgcG9pbnRpbmcg dG8gdGhlIGRyYWZ0cy4NCj4+PiBJIHVuZGVyc3RhbmQgZnJvbSB0aGUgZHJhZnRzIHRoYXQgaWYg YSBDUEUgaXMgYXNzaWduZWQgYSBzYW1lIElQDQo+Pj5hZGRyZXNzDQo+Pj4gYWZ0ZXIgcmVib290 LCBpbiBjYXNlIG9mIERTLUxpdGUsIFBDUCBwcm94eSBzaG91bGQgc2VuZCBBTk5PVU5DRQ0KPj4+ cmVxdWVzdA0KPj4+IHRvIHRoZSBQQ1AgY2xpZW50cy4NCj4+PiBUaGlzIHdheSwgUENQIGNsaWVu dHMgd291bGQgcmVmcmVzaCB0aGVpciBtYXBwaW5ncy4NCj4+PiANCj4+PiBTdXBwb3NlIHByZWZp eCBzYXkgMzAwMTo6LzU2IGlzIGFzc2lnbmVkIHRvIENQRSBhZnRlciByZWJvb3QgYW5kIGlzDQo+ Pj5zYW1lDQo+Pj4gYXMgYmVmb3JlIHJlYm9vdC4NCj4+PiBTdXBwb3NlIElQdjYgYWRkcmVzcyBi ZWZvcmUgcmVib290IGlzIDMwMDE6OmEgYW5kIGNyZWF0ZWQgc29tZQ0KPj4+bWFwcGluZ3MuDQo+ Pj4gDQo+Pj4gSG93ZXZlciwgYWZ0ZXIgYSByZWJvb3QsIGEgbmV3IElQdjYgYWRkcmVzcyBtYXkg YmUgdGFrZW4gYXMgQjQgc2F5DQo+Pj4gMzAwMTo6Yi4gDQo+Pj4gQXMgcGVyIHRoZSBjdXJyZW50 IGRyYWZ0cywgY2xpZW50cyB3aWxsIHRyeSB0byByZWZyZXNoIG1hcHBpbmdzIHdpdGgNCj4+PnRo ZQ0KPj4+IG5ld2x5IGFzc2lnbmVkIElQdjYgYWRkcmVzcyBhcyB0aGUgQjQgYWRkcmVzcy4NCj4+ PiBTaW5jZSB0aGUgcmVxdWVzdHMgYXJlIGZyb20gdGhlIGRpZmZlcmVudCBJUHY2IGFkZHJlc3Ms IENHTkFUIHdpbGwgdHJ5DQo+Pj50bw0KPj4+IGNyZWF0ZSBuZXcgbWFwcGluZ3MgYW5kIHRoZSBv bGQgbWFwcGluZ3MgaGF2ZSB0byBhZ2Ugb3V0Lg0KPj4+IE5vdyBob3N0cyB1c2luZyB0aGVzZSBt YXBwaW5ncyBoYXZlIHRvIHB1Ymxpc2ggdGhlc2UgbWFwcGluZ3MsIGZvcg0KPj4+IGV4dGVybmFs IGhvc3RzIHRvIGNvbm5lY3QgcmlnaHQ/IFRoaXMgaXMgYW4gb3ZlcmhlYWQuDQo+Pj4gDQo+Pj4g TXkgcG9pbnQgaXMsIHRoaXMgb3ZlciBoZWFkIGNhbiBiZSBlbGltaW5hdGVkIHdoZW4gdGhlcmUg aXMgYSBjaGFuZ2UgaW4NCj4+PiBhZGRyZXNzIGluIHRoZSBwcmVmaXgsIHdoeSBkbyB3ZSBuZWVk IHRvIGZvcmNlIGNyZWF0aW9uIG9mIG5ldyBtYXBwaW5ncw0KPj4+IGFuZCB0aW1lb3V0IG9mIG9s ZCBtYXBwaW5ncz8NCj4+PiBJbnN0ZWFkLCBjYW4gdGhlIG1hcHBpbmdzIGFuZCB0aGUgY29ycmVz cG9uZGluZyB0cmFmZmljIGJlIG1pZ3JhdGVkIHRvDQo+Pj4gbmV3ZXIgQjQ/IA0KPj4+IElmIHRo ZSBzYW1lIGFkZHJlc3MgaXMgYWNxdWlyZWQgYnkgdGhlIEI0IGFmdGVyIHJlYm9vdCwgQ0dOQVQg Ym94DQo+Pj5kb2Vzbid0DQo+Pj4gZGlmZmVyZW50aWF0ZSByaWdodD8gSSBhbSBzdWdnZXN0aW5n IGNhbiB0aGlzIGJlIGV4dGVuZGVkIHRvIHByZWZpeCwNCj4+PnN1Y2gNCj4+PiB0aGF0IGFueSBt YXBwaW5ncyBjcmVhdGVkIG92ZXIgb25lIEI0IGFkZHJlc3Mgb2YgdGhlIHByZWZpeCBiZQ0KPj4+ bWlncmF0ZWQgdG8NCj4+PiBhbm90aGVyIEI0IGFkZHJlc3Mgd2l0aGluIHRoZSBzYW1lIHByZWZp eD8NCj4+PiANCj4+PiBJZiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBwcmVmaXgsIHRoZXJlIGlzIG5v IG9wdGlvbiB0byBtaWdyYXRlIGFzDQo+Pj4gbWVudGlvbmVkLCBuZXcgbWFwcGluZ3MgaGF2ZSB0 byBiZSBjcmVhdGVkIGFuZCBvbGQgbWFwcGluZ3MgaGF2ZSB0bw0KPj4+IGV4cGlyZS4gDQo+Pj4g QWRkcmVzcyBjaGFuZ2Ugd2l0aCBpbiBhIHByZWZpeCBjYW4gYmUgaGFuZGxlZCBtb3JlIGdyYWNl ZnVsbHkgcmlnaHQ/DQo+Pj5BbSBJDQo+Pj4gbWlzc2luZyBzb21ldGhpbmc/DQo+Pj4gDQo+Pj4g LVN1cmVzaA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDYvMjEvMTMgMzo1NSBQTSwgIkRhbiBX aW5nIiA8ZHdpbmdAY2lzY28uY29tPiB3cm90ZToNCj4+PiANCj4+Pj4gDQo+Pj4+IE9uIEp1biAy MSwgMjAxMywgYXQgMjowMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4+Pj4gDQo+Pj4+PiBIaSBTdXJlc2gsDQo+Pj4+PiANCj4+Pj4+IElmIGEgbmV3IGFkZHJlc3Mg aXMgYXNzaWduZWQgdG8gdGhlIEI0LCB0aGUgY28tbG9jYXRlZCBQQ1AgY2xpZW50DQo+Pj4+Pndp bGwNCj4+Pj4+IG5lZWQgdG8gcmUtaW5zdGFsbCB0aGUgbWFwcGluZ3MgaXQgbWFuYWdlcy4NCj4+ Pj4gDQo+Pj4+IFdoZW4gYSBuZXcgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byB0aGUgQjQsIHRoZSBC NCdzIFBDUCBzZXJ2ZXIgc2hvdWxkDQo+Pj4+IGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBpbiAiQWRk cmVzcyBDaGFuZ2UgRXZlbnRzIiwNCj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Njg4NyNzZWN0aW9uLTExLjUuICBUaGUgaG9zdCB3aGljaA0KPj4+PmNyZWF0ZWQNCj4+Pj4gdGhl IG1hcHBpbmdzICh0aGUgUENQIGNsaWVudCkgbmVlZHMgdG8gYmUgYXdhcmUgb2YgdGhlIGFkZHJl c3MgY2hhbmdlDQo+Pj4+dG8NCj4+Pj4gdXBkYXRlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVu ZGV6dm91cyBzZXJ2ZXIgKEROUywgU0lQLCBYTVBQLA0KPj4+PiB3aGF0ZXZlciksIHdoaWNoIG1l YW5zIHRoZSBCNCdzIFBDUCBzZXJ2ZXIgaXNuJ3QgaGVscGluZyB0aGluZ3MgYnkNCj4+Pj4gdXBk YXRpbmcgbWFwcGluZ3Mgb24gdGhlIENHTiBieSBpdHNlbGYuDQo+Pj4+IA0KPj4+PiAtZA0KPj4+ PiANCj4+Pj4gDQo+Pj4+PiBUaGlzIHdpbGwgYmUgc2VlbiBieSB0aGUgUENQIHNlcnZlciBhcyBu ZXcgcmVxdWVzdHMgaWYgdGhlIFBDUCBDbGllbnQNCj4+Pj4+IElQIEFkZHJlc3MgaXMgbm90IGFs cmVhZHkgaW4gdXNlIGluIHRhYmxlIG9yIHJlZnJlc2ggbWFwcGluZ3MNCj4+Pj4+b3RoZXJ3aXNl Lg0KPj4+Pj4gSW4gYm90aCBjYXNlcywgdGhlcmUgaXMgYSBmYWlsdXJlIHJpc2sgZHVlIHRvIHRo ZSBwcmVzZW5jZSBvZiBzdGFsZQ0KPj4+Pj4gbWFwcGluZ3MuIFlvdSBjYW4gY2hlY2s6DQo+Pj4+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItcGNwLWZhaWx1cmUt MDYjc2VjdGlvbi0yLjQNCj4+Pj4+IA0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gTWVkDQo+Pj4+PiAN Cj4+Pj4+IERlIDogU3VyZXNoIEt1bWFyIFZpbmFwYW11bGEgVmVua2F0YSBbbWFpbHRvOnN1cmVz aGtAanVuaXBlci5uZXRdDQo+Pj4+PiBFbnZvecOpIDogamV1ZGkgMjAganVpbiAyMDEzIDE3OjA2 DQo+Pj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+Pj4+PiBDYyA6IHBjcEBp ZXRmLm9yZzsgbXJ3QHBhaW5sZXNzLXNlY3VyaXR5LmNvbTsgZmR1cG9udEBpc2Mub3JnDQo+Pj4+ PiBPYmpldCA6IFJlOiBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIChQQ1Ag RFMtTGl0ZQ0KPj4+Pj4gSGFuZGxpbmcpDQo+Pj4+PiANCj4+Pj4+IEhpIE1vaGFtbWVkDQo+Pj4+ PiANCj4+Pj4+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gbWlzc2luZyBzb21lIHRoaW5nLiBI b3cgY2FuIENHTkFUIGtub3csDQo+Pj4+PiB3aGV0aGVyIHRoZSByZXF1ZXN0IGlzIHRvIHJlZnJl c2ggZXhpc3RpbmcgbWFwcGluZ3Mgb3IgZm9yIG5ldw0KPj4+Pj5tYXBwaW5ncw0KPj4+Pj4gd2hl biB0aGUgQ1BFIGFkZHJlc3MgY2hhbmdlZD8NCj4+Pj4+IEFkZHJlc3NlcyBiZWhpbmQgQjQgY2Fu IG92ZXJsYXAgcmlnaHQ/IFRoZXkgaGF2ZSB0byByZWx5IG9uIEI0DQo+Pj4+PmFkZHJlc3MNCj4+ Pj4+IHJpZ2h0Pw0KPj4+Pj4gDQo+Pj4+PiBTdXJlc2gNCj4+Pj4+IA0KPj4+Pj4gT24gSnVuIDIw LCAyMDEzLCBhdCA2OjI1IEFNLCAibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSINCj4+Pj4+ IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gRGVh ciBTdXJlc2gsDQo+Pj4+PiANCj4+Pj4+IEZXSVcsIHlvdSBtYXkgZmluZCBzb21lIHRleHQgZGVz Y3JpYmluZyB0aGlzIGZhaWx1cmUgY2FzZQ0KPj4+Pj4gDQo+Pj4+PmF0Omh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1wY3AtZmFpbHVyZS0wNiNzZWN0aW9uLTINCj4+ Pj4+LjUNCj4+Pj4+IC4NCj4+Pj4+IA0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gTWVkDQo+Pj4+PiAN Cj4+Pj4+IERlIDogcGNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY3AtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZQ0KPj4+Pj4gU3VyZXNoIEt1bWFyIFZpbmFwYW11bGEgVmVua2F0 YQ0KPj4+Pj4gRW52b3nDqSA6IGpldWRpIDIwIGp1aW4gMjAxMyAwMjowMA0KPj4+Pj4gw4AgOiBw Y3BAaWV0Zi5vcmcNCj4+Pj4+IENjIDogbXJ3QHBhaW5sZXNzLXNlY3VyaXR5LmNvbTsgZmR1cG9u dEBpc2Mub3JnDQo+Pj4+PiBPYmpldCA6IFtwY3BdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNw LWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlDQo+Pj4+PiBIYW5kbGluZykNCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiBIaSwgDQo+Pj4+PiANCj4+Pj4+IEFuIGV4dGVybmFsIElQIGFkZHJlc3Mgb2YgdGhl IENQRSBkZXZpY2UgbWF5IGNoYW5nZSBhcyBhbmQgd2hlbiBESENQDQo+Pj4+PiBsZWFzZSBleHBp cmVzIG9yIHdoZW4gdGhlcmUgaXMgYSByZWJvb3Qgb2YgQ1BFIGZvciBhbnkgcmVhc29uLg0KPj4+ Pj4gVHJhZmZpYyBkZXN0aW5lZCBmcm9tIGV4dGVybmFsIHdvcmxkLCB0byB0aGVzZSBtYXBwaW5n cywgbWF5IG5vdA0KPj4+Pj5yZWFjaA0KPj4+Pj4gaW50ZW5kZWQgQ1BFLCBhcyB0aGVyZSBpcyBj aGFuZ2UgaW4gZXh0ZXJuYWwgYWRkcmVzcy4NCj4+Pj4+IFJGQyA2ODg3IHJlY29tbWVuZHMgbm8g aG9zdCByZW51bWJlcmluZyB0byBoYW5kbGUgaXQuDQo+Pj4+PiANCj4+Pj4+IEhvd2V2ZXIgdGhp cyBpcyBub3Qgc3VmZmljaWVudCBpbiB2NiBlbnZpcm9ubWVudCBlc3BlY2lhbGx5IHdpdGgNCj4+ Pj4+IERTLUxpdGUsIHdoZXJlIGEgQ1BFIGlzIGFzc2lnbmVkIGEgdjZwcmVmaXggYW5kIGlzIGZy ZWUgdG8gdXNlIGFueQ0KPj4+Pj4gYWRkcmVzcyB3aXRoIGluIHRoZSBwcmVmaXguIFRob3VnaCBE SFBDdjYgbWF5IGFzc2lnbiBzYW1lIHByZWZpeCB0byBhDQo+Pj4+PiBDUEUsIHRoZSBob3N0IHBv cnRpb24gaXMgdHlwaWNhbGx5IGZpbGxlZCBieSBDUEUgYW5kIHR5cGljYWxseSB3aXRoDQo+Pj4+ Pm1hYw0KPj4+Pj4gYWRkcmVzcywgd2hpY2ggY2hhbmdlcyB3aGVuIHRoZXJlIGlzIGEgY2hhbmdl IGluIENQRSBkZXZpY2Ugb3IgZm9yDQo+Pj4+PnNvbWUNCj4+Pj4+IHJlYXNvbi4gDQo+Pj4+PiAN Cj4+Pj4+IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyAoSG9zdHMgYmVoaW5kIENQRS9CNCwgYW5kIHRo ZSBDR04gYm94KSBoYXMgbm90DQo+Pj4+PiByZWJvb3RlZCwgdGhlIG1hcHBpbmdzIHRoYXQgd2Vy ZSBjcmVhdGVkIGJlZm9yZSBhbmQgdGhlIHRyYWZmaWMNCj4+Pj4+ZGVzdGluZWQNCj4+Pj4+IHRv IHRob3NlIG1hcHBpbmdzIGlmIHR1bm5lbGVkIG92ZXIgdG8gb2xkIEI0IGFkZHJlc3Mgd291bGQg YmUNCj4+Pj4+ZHJvcHBlZCBieQ0KPj4+Pj4gdGhlIENQRSBkZXZpY2UuDQo+Pj4+PiANCj4+Pj4+ IFRoaXMgYWxzbyBjYXVzZXMgb3RoZXIgaW5jb252ZW5pZW5jZSBhcyB0aGVzZSBtYXBwaW5ncyBo YW5ncyBhcm91bmQNCj4+Pj4+IHRpbGwgdGhleSB0aW1lb3V0KHNjYWxpbmcgaW1wYWN0IGFuZCBu b24gdXNhZ2Ugb2YgcG9ydHMgYW5kIG1lbW9yeSkNCj4+Pj4+b3IsDQo+Pj4+PiB1bmxlc3MsIGEg cGFja2V0IGZha2VkIHdpdGggdGhlIG9sZCBCNCBhZGRyZXNzIGFzIHNvdXJjZSBhbmQgYSBkZWxl dGUNCj4+Pj4+IHJlcXVlc3QgaXMgaXNzdWVkLiBFdmVuIGlmIHRob3NlIG1hcHBpbmdzIGFyZSBk ZWxldGVkICBpbiBzb21ld2F5LCBhDQo+Pj4+Pm5ldw0KPj4+Pj4gc2V0IG9mIG1hcHBpbmdzIGhh dmUgdG8gYmUgY3JlYXRlZCBhbmQgcHVibGlzaGVkIGZvciBleHRlcm5hbCB3b3JsZA0KPj4+Pj50 bw0KPj4+Pj4gY29ubmVjdCwgZXZlcnkgdGltZSwgd2hlbiBzdWNoIGFuIGV2ZW50IGhhcHBlbnMu DQo+Pj4+PiANCj4+Pj4+IFRoaXMgaXMgYSBzY2VuYXJpbywgd2hlcmUgZW5kIHN5c3RlbXMoaG9z dHMgYmVoaW5kIEI0IGFuZCBDR05BVA0KPj4+Pj5kZXZpY2UpDQo+Pj4+PiBhcmUgbm90IHJlYm9v dGVkLCBidXQgaW50ZXJtZWRpYXRlIENQRSBkZXZpY2UgaXMgcmVib290ZWQuDQo+Pj4+PiANCj4+ Pj4+IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyBhcmUgbm90IHJlYm9vdGVkLCBjYW4gdGhvc2UgbWFw cGluZ3MgYmUNCj4+Pj4+bWlncmF0ZWQNCj4+Pj4+IG92ZXIgRFMtTGl0ZSB0dW5uZWxzPw0KPj4+ Pj4gDQo+Pj4+PiBUaGVyZSBhcmUgdHdvIG9wdGlvbnMgaGVyZSwgdG8gcmV1c2UgdGhlc2UgbWFw cGluZ3MuDQo+Pj4+PiAJ4oKsIFRoZSBvcHRpb24gaXMsIGNyZWF0ZSBtYXBwaW5ncyBhbmQgZmxv d3Mgb24gcGVyIHByZWZpeC4gVGhpcyB3YXkNCj4+Pj4+IG1hcHBpbmdzIGFuZCBmbG93cyBhcmUg bWlncmF0ZWQgdG8gYW55IGFkZHJlc3MgaW4gdGhlIHNhbWUgcHJlZml4DQo+Pj4+PndoZW4NCj4+ Pj4+IGV2ZXIgdGhlcmUgaXMgY2hhbmdlIGluIGFkZHJlc3MuIFRoZSBkZXN0aW5hdGlvbiBhZGRy ZXNzIHRvIGJlIHVzZWQNCj4+Pj4+YnkNCj4+Pj4+IHRoZSBDR05BVCBib3gsIHRvIHR1bm5lbCBw YWNrZXRzIG92ZXIgdGhvc2UgbWFwcGluZ3MgdG8gdGhlIENQRQ0KPj4+Pj5zaG91bGQNCj4+Pj4+ IGJlIHRoZSBhZGRyZXNzIGxhc3Qgc2VlbiBieSB0aGUgQ0dOQVQgZnJvbSB0aGUgQ1BFIG9mIHRo ZSBwcmVmaXguDQo+Pj4+PlRoaXMNCj4+Pj4+IHdheSwgdHJhZmZpYyBvdmVyIG1hcHBpbmdzIGFu ZCBmbG93cyBjcmVhdGVkIG92ZXIgb2xkIEI0IGFkZHJlc3MsIGNhbg0KPj4+Pj4gY29udGludWUg dG8gcmVhY2ggaW50ZW5kZWQgaG9zdCBvdmVyIHRoZSBuZXcgRFMtTGl0ZSB0dW5uZWwuDQo+Pj4+ PiAJ4oKsIENQRSB0byBhY2NlcHQgcGFja2V0cyBkZXN0aW5lZCB0byBhbnkgYWRkcmVzcyBpbiB0 aGF0IHByZWZpeC4gVGhpcw0KPj4+Pj4gbWF5IGJlIGEgZ2VuZXJpYyBzdGFjayBjaGFuZ2UgYW5k IG1heSBub3QgYmUgZGVzaXJhYmxlLg0KPj4+Pj4gVGhpcyBpcyBub3QgY292ZXJlZCBpbg0KPj4+ Pj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjcC1kc2xpdGUt MDAuIENhbiB0aGlzIGJlDQo+Pj4+PiBpbmNsdWRlZCBmb3IgdGhlIGRpc2N1c3Npb24/DQo+Pj4+ PiANCj4+Pj4+IFBsZWFzZSBjb21tZW50Lg0KPj4+Pj4gDQo+Pj4+PiAtU3VyZXNoDQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gcGNw IG1haWxpbmcgbGlzdA0KPj4+Pj4gcGNwQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gcGNwIG1haWxpbmcgbGlzdA0KPj4+IHBjcEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo+PiANCj4NCj4NCj4NCg0K From dwing@cisco.com Fri Jun 21 22:06:38 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5F021F9D21 for ; Fri, 21 Jun 2013 22:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.558 X-Spam-Level: X-Spam-Status: No, score=-109.558 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4SHbAGBBLjh for ; Fri, 21 Jun 2013 22:06:33 -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 C69CF21F9D1A for ; Fri, 21 Jun 2013 22:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13581; q=dns/txt; s=iport; t=1371877593; x=1373087193; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8YlrLmcrtW6mo0dSyAWpcsDMxW6NQNQpQLYRJnEOcg8=; b=ahTZxCr4KKUnH5NXjTDr86Tdyqe5ugEfQARlY+x+mq3WA7VTZ8iMqb9P by8a4Eq7kIDU+XF1BhP84U2CybrD8saXqyW2rT3X/GmtZEQ2jAkhOp2mi /wctJPzn3gkwLwTjPkqRHNkKmwsc+uL+eY3NUjEgwWxWRsVXsuJ7s3pyz 4=; X-IronPort-AV: E=Sophos;i="4.87,917,1363132800"; d="scan'208";a="81541719" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2013 05:06:33 +0000 Received: from sjc-vpn3-98.cisco.com (sjc-vpn3-98.cisco.com [10.21.64.98]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5M56Vbm011075; Sat, 22 Jun 2013 05:06:32 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Fri, 21 Jun 2013 22:06:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <305C351F-C20A-43E6-BA7E-7B1DDA73CD92@cisco.com> References: To: Suresh Kumar Vinapamula Venkata X-Mailer: Apple Mail (2.1508) Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 05:06:38 -0000 On Jun 21, 2013, at 9:32 PM, Suresh Kumar Vinapamula Venkata = wrote: > Yes Reinaldo, that is correct. >=20 > Dan,=20 >=20 > Note, it is the CPE that rebooted or went bad and so changed. > End systems are not rebooted. >=20 > With no renumbering CPE is assigned same v6 prefix 3001::. > Depending on the algorithm to fill in the host portion forming a B4 > prefix, a new B4 address 3001::b can be picked which is different from = old > B4 address 3001::a. >=20 > Since the end systems 10.0.0.2 haven't rebooted, they should be able = to > continue using those mappings. When hosts behind B4 sees ANNOUNCE, and > sends refresh requests, it would not result in creating a new mapping = but > use existing mapping. The benefit, hosts behind B4 don't need to = publish > to external world about the change, to receive traffic from external = world. What are the security implications of 3001::b taking over 3001::a's = mappings? Is there a way to ensure that doesn't happen maliciously? >=20 > Consider a case where an IPv6 address is assigned and not prefix to = the > CPE. > If the same IPv6 address assigned after reboot or change of CPE, hosts = on > seeing PCP ANNOUNCE, when refreshes their mappings, PCP server = responses > back with the existing mapping, it is not going to create new set of > mappings and age out existing mappings right? >=20 > I am extending the same argument to prefixes, where CPEs are assigned = with > prefixes and are free to use any v6 address in the prefix as B4 = address. > So, change in that address should not result in creating new mappings = and > age out old mappings. >=20 > Suppose if we go with the approach defined in the drafts where new > mappings have to be created when there is change in address, as an > attacker, I can exhaust CGNAT/PCP server resources, by picking = multiple > IPv6 addresses with in the assigned prefix as B4 and faking PCP = requests. That attack is still possible with your idea. The mitigation, with or = without your idea, is that the AFTR has to apply its port quota to the = entirety of the IPv6 prefix assigned to a B4 -- the entire "subscriber", = if you will -- typically the entire /64. That seems an important point = to include in draft-ietf-pcp-dslite. > If we limit the resources on per prefix bases on CGNAT/PCP, then as a > genuine user when there is a change in B4 address, I will not be able = to > create and use all my quota of mappings, as there would be some stale > mappings created before my B4 change eating my quota. Ignoring PCP for a moment, that problem exists with implicit mappings if = the ISP renumbers hosts behind the CGN. I admit that PCP's long = lifetimes can make that problem worse. One easy solution is to reduce = the maximum assigned PCP lifetime on the CGN prior to an address change = event -- much like we do with lowering DNS TTL prior to changing DNS = records. But perhaps it is operationally difficult to know when an = address change is going to occur. A slightly more difficult solution, = which works even if address changes aren't planned, is to send a PCP = THIRD_PARTY delete message from the ISP's management system when an = address change occurs. > And the traffic > destined to those mappings from internet would be processed by CGNAT = box > only to be dropped at CPE! But the CPE dropping those packets is not a new or significant problem = when the ISP renumbered the subscriber. Such dropping of packets would = happen on today's IPv4 Internet if the ISP renumbered two subscribers to = suddenly have each other's IP addresses -- packets would be routed to = the wrong home and get dropped by NATs or host-based firewalls, or (if = they aren't dropped) the packets would be processed by the host to = confuse TCP stacks or applications. -d >=20 > Please comment. >=20 > Suresh >=20 >=20 > On 6/21/13 7:08 PM, "Dan Wing" wrote: >=20 >>=20 >> On Jun 21, 2013, at 6:16 PM, "Reinaldo Penno (repenno)" >> wrote: >>=20 >>> It seems you are suggesting a per prefix binding. So, in your = example if >>> internal host 10.0.0.2 sends a new MAP request that uses 3001:b as >>> source >>> address, the AFTR should update any existing mappings to use this = new >>> source IPv6 to reach the B4 while external public IP:port would be = the >>> same. Therefore no need to update dynDNS or other stuff. >>>=20 >>> If my understanding is correct this is interesting. >>=20 >> Thanks for summarizing - I understand the proposal now. It seems to >> require the B4 and the AFTR know that the same IPv4 mapping is = available >> after IPv6 renumbering -- specifically that the same AFTR is being = used >> and it will assign the same IPv4 address to the B4. Seems a lot of >> coordination between the B4 and AFTR to avoid updating a rendezvous >> server. However, the host (and the B4) will always need to be able = to >> handle network renumbering where the same IPv4 mapping is not = available, >> so this increases implementation and testing effort. The gain, in my >> mind, is pretty small especially considering the IP renumbering has = to be >> infrequent (or else TCP sessions are disrupted, nobody much = appreciates >> that). >>=20 >> -d >>=20 >>=20 >>>=20 >>> On 6/21/13 9:37 PM, "Suresh Kumar Vinapamula Venkata" >>> wrote: >>>=20 >>>> Hi Mohamed/Dan, >>>>=20 >>>> Thanks for pointing to the drafts. >>>> I understand from the drafts that if a CPE is assigned a same IP >>>> address >>>> after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE >>>> request >>>> to the PCP clients. >>>> This way, PCP clients would refresh their mappings. >>>>=20 >>>> Suppose prefix say 3001::/56 is assigned to CPE after reboot and is >>>> same >>>> as before reboot. >>>> Suppose IPv6 address before reboot is 3001::a and created some >>>> mappings. >>>>=20 >>>> However, after a reboot, a new IPv6 address may be taken as B4 say >>>> 3001::b.=20 >>>> As per the current drafts, clients will try to refresh mappings = with >>>> the >>>> newly assigned IPv6 address as the B4 address. >>>> Since the requests are from the different IPv6 address, CGNAT will = try >>>> to >>>> create new mappings and the old mappings have to age out. >>>> Now hosts using these mappings have to publish these mappings, for >>>> external hosts to connect right? This is an overhead. >>>>=20 >>>> My point is, this over head can be eliminated when there is a = change in >>>> address in the prefix, why do we need to force creation of new = mappings >>>> and timeout of old mappings? >>>> Instead, can the mappings and the corresponding traffic be migrated = to >>>> newer B4?=20 >>>> If the same address is acquired by the B4 after reboot, CGNAT box >>>> doesn't >>>> differentiate right? I am suggesting can this be extended to = prefix, >>>> such >>>> that any mappings created over one B4 address of the prefix be >>>> migrated to >>>> another B4 address within the same prefix? >>>>=20 >>>> If there is a change in prefix, there is no option to migrate as >>>> mentioned, new mappings have to be created and old mappings have to >>>> expire.=20 >>>> Address change with in a prefix can be handled more gracefully = right? >>>> Am I >>>> missing something? >>>>=20 >>>> -Suresh >>>>=20 >>>>=20 >>>>=20 >>>> On 6/21/13 3:55 PM, "Dan Wing" wrote: >>>>=20 >>>>>=20 >>>>> On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: >>>>>=20 >>>>>> Hi Suresh, >>>>>>=20 >>>>>> If a new address is assigned to the B4, the co-located PCP client >>>>>> will >>>>>> need to re-install the mappings it manages. >>>>>=20 >>>>> When a new address is assigned to the B4, the B4's PCP server = should >>>>> follow the procedures in "Address Change Events", >>>>> http://tools.ietf.org/html/rfc6887#section-11.5. The host which >>>>> created >>>>> the mappings (the PCP client) needs to be aware of the address = change >>>>> to >>>>> update the information in the rendezvous server (DNS, SIP, XMPP, >>>>> whatever), which means the B4's PCP server isn't helping things by >>>>> updating mappings on the CGN by itself. >>>>>=20 >>>>> -d >>>>>=20 >>>>>=20 >>>>>> This will be seen by the PCP server as new requests if the PCP = Client >>>>>> IP Address is not already in use in table or refresh mappings >>>>>> otherwise. >>>>>> In both cases, there is a failure risk due to the presence of = stale >>>>>> mappings. You can check: >>>>>> = http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4 >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>>>>> Envoy=E9 : jeudi 20 juin 2013 17:06 >>>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>>>> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >>>>>> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>>>> Handling) >>>>>>=20 >>>>>> Hi Mohammed >>>>>>=20 >>>>>> Please correct me if I am missing some thing. How can CGNAT know, >>>>>> whether the request is to refresh existing mappings or for new >>>>>> mappings >>>>>> when the CPE address changed? >>>>>> Addresses behind B4 can overlap right? They have to rely on B4 >>>>>> address >>>>>> right? >>>>>>=20 >>>>>> Suresh >>>>>>=20 >>>>>> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >>>>>> wrote: >>>>>>=20 >>>>>> Dear Suresh, >>>>>>=20 >>>>>> FWIW, you may find some text describing this failure case >>>>>>=20 >>>>>> = at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2 >>>>>> .5 >>>>>> . >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la = part de >>>>>> Suresh Kumar Vinapamula Venkata >>>>>> Envoy=E9 : jeudi 20 juin 2013 02:00 >>>>>> =C0 : pcp@ietf.org >>>>>> Cc : mrw@painless-security.com; fdupont@isc.org >>>>>> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>>>> Handling) >>>>>>=20 >>>>>>=20 >>>>>> Hi,=20 >>>>>>=20 >>>>>> An external IP address of the CPE device may change as and when = DHCP >>>>>> lease expires or when there is a reboot of CPE for any reason. >>>>>> Traffic destined from external world, to these mappings, may not >>>>>> reach >>>>>> intended CPE, as there is change in external address. >>>>>> RFC 6887 recommends no host renumbering to handle it. >>>>>>=20 >>>>>> However this is not sufficient in v6 environment especially with >>>>>> DS-Lite, where a CPE is assigned a v6prefix and is free to use = any >>>>>> address with in the prefix. Though DHPCv6 may assign same prefix = to a >>>>>> CPE, the host portion is typically filled by CPE and typically = with >>>>>> mac >>>>>> address, which changes when there is a change in CPE device or = for >>>>>> some >>>>>> reason.=20 >>>>>>=20 >>>>>> Since the end systems (Hosts behind CPE/B4, and the CGN box) has = not >>>>>> rebooted, the mappings that were created before and the traffic >>>>>> destined >>>>>> to those mappings if tunneled over to old B4 address would be >>>>>> dropped by >>>>>> the CPE device. >>>>>>=20 >>>>>> This also causes other inconvenience as these mappings hangs = around >>>>>> till they timeout(scaling impact and non usage of ports and = memory) >>>>>> or, >>>>>> unless, a packet faked with the old B4 address as source and a = delete >>>>>> request is issued. Even if those mappings are deleted in = someway, a >>>>>> new >>>>>> set of mappings have to be created and published for external = world >>>>>> to >>>>>> connect, every time, when such an event happens. >>>>>>=20 >>>>>> This is a scenario, where end systems(hosts behind B4 and CGNAT >>>>>> device) >>>>>> are not rebooted, but intermediate CPE device is rebooted. >>>>>>=20 >>>>>> Since the end systems are not rebooted, can those mappings be >>>>>> migrated >>>>>> over DS-Lite tunnels? >>>>>>=20 >>>>>> There are two options here, to reuse these mappings. >>>>>> =80 The option is, create mappings and flows on per prefix. This = way >>>>>> mappings and flows are migrated to any address in the same prefix >>>>>> when >>>>>> ever there is change in address. The destination address to be = used >>>>>> by >>>>>> the CGNAT box, to tunnel packets over those mappings to the CPE >>>>>> should >>>>>> be the address last seen by the CGNAT from the CPE of the prefix. >>>>>> This >>>>>> way, traffic over mappings and flows created over old B4 address, = can >>>>>> continue to reach intended host over the new DS-Lite tunnel. >>>>>> =80 CPE to accept packets destined to any address in that = prefix. This >>>>>> may be a generic stack change and may not be desirable. >>>>>> This is not covered in >>>>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can = this be >>>>>> included for the discussion? >>>>>>=20 >>>>>> Please comment. >>>>>>=20 >>>>>> -Suresh >>>>>> _______________________________________________ >>>>>> pcp mailing list >>>>>> pcp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pcp >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>=20 >>=20 >>=20 >=20 From sureshk@juniper.net Sat Jun 22 01:02:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600921F9D89 for ; Sat, 22 Jun 2013 01:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.06 X-Spam-Level: * X-Spam-Status: No, score=1.06 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcIAfPjE5K4 for ; Sat, 22 Jun 2013 01:02:20 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 408B421F9D7F for ; Sat, 22 Jun 2013 01:02:20 -0700 (PDT) Received: from mail196-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 08:02:19 +0000 Received: from mail196-co1 (localhost [127.0.0.1]) by mail196-co1-R.bigfish.com (Postfix) with ESMTP id 789E0380460 for ; Sat, 22 Jun 2013 08:02:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371Ic89bh148cI1432I168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h683h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail196-co1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=sureshk@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail196-co1 (localhost.localdomain [127.0.0.1]) by mail196-co1 (MessageSwitch) id 1371888136138376_12956; Sat, 22 Jun 2013 08:02:16 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.245]) by mail196-co1.bigfish.com (Postfix) with ESMTP id 1F4FB100100 for ; Sat, 22 Jun 2013 08:02:16 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.51) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Jun 2013 08:02:13 +0000 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; Sat, 22 Jun 2013 01:02:12 -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; Sat, 22 Jun 2013 01:02:12 -0700 Received: from CO9EHSOBE022.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 22 Jun 2013 01:14:06 -0700 Received: from mail192-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.23; Sat, 22 Jun 2013 08:02:09 +0000 Received: from mail192-co9 (localhost [127.0.0.1]) by mail192-co9-R.bigfish.com (Postfix) with ESMTP id AD6824C02A8 for ; Sat, 22 Jun 2013 08:02:09 +0000 (UTC) Received: from mail192-co9 (localhost.localdomain [127.0.0.1]) by mail192-co9 (MessageSwitch) id 1371888126944057_14169; Sat, 22 Jun 2013 08:02:06 +0000 (UTC) Received: from CO9EHSMHS027.bigfish.com (unknown [10.236.132.229]) by mail192-co9.bigfish.com (Postfix) with ESMTP id D9BF632004D; Sat, 22 Jun 2013 08:02:06 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS027.bigfish.com (10.236.130.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 22 Jun 2013 08:02:06 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0324.000; Sat, 22 Jun 2013 08:02:05 +0000 From: Suresh Kumar Vinapamula Venkata To: Dan Wing Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAAgGEAgAAOhoD//7LFAIAAfuuA//+4moA= Date: Sat, 22 Jun 2013 08:02:04 +0000 Message-ID: In-Reply-To: <305C351F-C20A-43E6-BA7E-7B1DDA73CD92@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="utf-8" Content-ID: <4F5AB57944D0194CB114688D471DCA2C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 22 Jun 2013 08:02:26 -0000 DQoNCk9uIDYvMjEvMTMgMTA6MDYgUE0sICJEYW4gV2luZyIgPGR3aW5nQGNpc2NvLmNvbT4gd3Jv dGU6DQoNCj4NCj5PbiBKdW4gMjEsIDIwMTMsIGF0IDk6MzIgUE0sIFN1cmVzaCBLdW1hciBWaW5h cGFtdWxhIFZlbmthdGENCj48c3VyZXNoa0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+DQo+PiBZZXMg UmVpbmFsZG8sIHRoYXQgaXMgY29ycmVjdC4NCj4+IA0KPj4gRGFuLCANCj4+IA0KPj4gTm90ZSwg aXQgaXMgdGhlIENQRSB0aGF0IHJlYm9vdGVkIG9yIHdlbnQgYmFkIGFuZCBzbyBjaGFuZ2VkLg0K Pj4gRW5kIHN5c3RlbXMgYXJlIG5vdCByZWJvb3RlZC4NCj4+IA0KPj4gV2l0aCBubyByZW51bWJl cmluZyBDUEUgaXMgYXNzaWduZWQgc2FtZSB2NiBwcmVmaXggMzAwMTo6Lg0KPj4gRGVwZW5kaW5n IG9uIHRoZSBhbGdvcml0aG0gdG8gZmlsbCBpbiB0aGUgaG9zdCBwb3J0aW9uIGZvcm1pbmcgYSBC NA0KPj4gcHJlZml4LCBhIG5ldyBCNCBhZGRyZXNzIDMwMDE6OmIgY2FuIGJlIHBpY2tlZCB3aGlj aCBpcyBkaWZmZXJlbnQgZnJvbQ0KPj5vbGQNCj4+IEI0IGFkZHJlc3MgMzAwMTo6YS4NCj4+IA0K Pj4gU2luY2UgdGhlIGVuZCBzeXN0ZW1zIDEwLjAuMC4yIGhhdmVuJ3QgcmVib290ZWQsIHRoZXkg c2hvdWxkIGJlIGFibGUgdG8NCj4+IGNvbnRpbnVlIHVzaW5nIHRob3NlIG1hcHBpbmdzLiBXaGVu IGhvc3RzIGJlaGluZCBCNCBzZWVzIEFOTk9VTkNFLCBhbmQNCj4+IHNlbmRzIHJlZnJlc2ggcmVx dWVzdHMsIGl0IHdvdWxkIG5vdCByZXN1bHQgaW4gY3JlYXRpbmcgYSBuZXcgbWFwcGluZw0KPj5i dXQNCj4+IHVzZSBleGlzdGluZyBtYXBwaW5nLiBUaGUgYmVuZWZpdCwgaG9zdHMgYmVoaW5kIEI0 IGRvbid0IG5lZWQgdG8gcHVibGlzaA0KPj4gdG8gZXh0ZXJuYWwgd29ybGQgYWJvdXQgdGhlIGNo YW5nZSwgdG8gcmVjZWl2ZSB0cmFmZmljIGZyb20gZXh0ZXJuYWwNCj4+d29ybGQuDQo+DQo+V2hh dCBhcmUgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiAzMDAxOjpiIHRha2luZyBvdmVyIDMw MDE6OmEncw0KPm1hcHBpbmdzPyAgSXMgdGhlcmUgYSB3YXkgdG8gZW5zdXJlIHRoYXQgZG9lc24n dCBoYXBwZW4gbWFsaWNpb3VzbHk/DQoNClNpbmNlIFNpbmNlIHRoZXkgYXJlIGZyb20gdGhlIHNh bWUgcHJlZml4LCBhbmQgdGhlIHByZWZpeCBsZW4NCmNvbmZpZ3VyYXRpb24gaXMgdW5kZXIgYWRt aW4gY29udHJvbCwgSSBhbSBub3QgdGhpbmtpbmcgb2YgYW55IF9uZXdfDQptYWxpY2lvdXMgYXR0 YWNrcy4NCklmIHlvdSB0aGluayBvZiBhbnkgc3VjaCBzY2VuYXJpb3MsIGNhbiB5b3UgcGxlYXNl IHBvaW50IHRoZW0/DQoNCj4NCj4NCj4+IA0KPj4gQ29uc2lkZXIgYSBjYXNlIHdoZXJlIGFuIElQ djYgYWRkcmVzcyBpcyBhc3NpZ25lZCBhbmQgbm90IHByZWZpeCB0byB0aGUNCj4+IENQRS4NCj4+ IElmIHRoZSBzYW1lIElQdjYgYWRkcmVzcyBhc3NpZ25lZCBhZnRlciByZWJvb3Qgb3IgY2hhbmdl IG9mIENQRSwgaG9zdHMNCj4+b24NCj4+IHNlZWluZyBQQ1AgQU5OT1VOQ0UsIHdoZW4gcmVmcmVz aGVzIHRoZWlyIG1hcHBpbmdzLCBQQ1Agc2VydmVyIHJlc3BvbnNlcw0KPj4gYmFjayB3aXRoIHRo ZSBleGlzdGluZyBtYXBwaW5nLCBpdCBpcyBub3QgZ29pbmcgdG8gY3JlYXRlIG5ldyBzZXQgb2YN Cj4+IG1hcHBpbmdzIGFuZCBhZ2Ugb3V0IGV4aXN0aW5nIG1hcHBpbmdzIHJpZ2h0Pw0KPj4gDQo+ PiBJIGFtIGV4dGVuZGluZyB0aGUgc2FtZSBhcmd1bWVudCB0byBwcmVmaXhlcywgd2hlcmUgQ1BF cyBhcmUgYXNzaWduZWQNCj4+d2l0aA0KPj4gcHJlZml4ZXMgYW5kIGFyZSBmcmVlIHRvIHVzZSBh bnkgdjYgYWRkcmVzcyBpbiB0aGUgcHJlZml4IGFzIEI0IGFkZHJlc3MuDQo+PiBTbywgY2hhbmdl IGluIHRoYXQgYWRkcmVzcyBzaG91bGQgbm90IHJlc3VsdCBpbiBjcmVhdGluZyBuZXcgbWFwcGlu Z3MNCj4+YW5kDQo+PiBhZ2Ugb3V0IG9sZCBtYXBwaW5ncy4NCj4+IA0KPj4gU3VwcG9zZSBpZiB3 ZSBnbyB3aXRoIHRoZSBhcHByb2FjaCBkZWZpbmVkIGluIHRoZSBkcmFmdHMgd2hlcmUgbmV3DQo+ PiBtYXBwaW5ncyBoYXZlIHRvIGJlIGNyZWF0ZWQgd2hlbiB0aGVyZSBpcyBjaGFuZ2UgaW4gYWRk cmVzcywgYXMgYW4NCj4+IGF0dGFja2VyLCBJIGNhbiBleGhhdXN0IENHTkFUL1BDUCBzZXJ2ZXIg cmVzb3VyY2VzLCBieSBwaWNraW5nIG11bHRpcGxlDQo+PiBJUHY2IGFkZHJlc3NlcyB3aXRoIGlu IHRoZSBhc3NpZ25lZCBwcmVmaXggYXMgQjQgYW5kIGZha2luZyBQQ1ANCj4+cmVxdWVzdHMuDQo+ DQo+VGhhdCBhdHRhY2sgaXMgc3RpbGwgcG9zc2libGUgd2l0aCB5b3VyIGlkZWEuICBUaGUgbWl0 aWdhdGlvbiwgd2l0aCBvcg0KPndpdGhvdXQgeW91ciBpZGVhLCBpcyB0aGF0IHRoZSBBRlRSIGhh cyB0byBhcHBseSBpdHMgcG9ydCBxdW90YSB0byB0aGUNCj5lbnRpcmV0eSBvZiB0aGUgSVB2NiBw cmVmaXggYXNzaWduZWQgdG8gYSBCNCAtLSB0aGUgZW50aXJlICJzdWJzY3JpYmVyIiwNCj5pZiB5 b3Ugd2lsbCAtLSB0eXBpY2FsbHkgdGhlIGVudGlyZSAvNjQuICBUaGF0IHNlZW1zIGFuIGltcG9y dGFudCBwb2ludA0KPnRvIGluY2x1ZGUgaW4gZHJhZnQtaWV0Zi1wY3AtZHNsaXRlLg0KWWVzLCBy ZXNvdXJjZXMgaGF2ZSB0byBiZSBjb25maWd1cmVkIG9uIHBlciBwcmVmaXggYmFzaXMuIEluIGFk ZGl0aW9uIHRvDQp0aGF0LCBpZiB3ZSBhcmUgbm90IG1pZ3JhdGluZyBtYXBwaW5ncywgeW91IHdv dWxkIGJlIGVhdGluZyB1cCB0aGUgcXVvdGENCmJlY2F1c2Ugb2YgdGhlIHN0YWxlIG1hcHBpbmdz IHRoYXQgSSBtZW50aW9uZWQgYmVsb3cgcmlnaHQ/DQo+DQo+PiBJZiB3ZSBsaW1pdCB0aGUgcmVz b3VyY2VzIG9uIHBlciBwcmVmaXggYmFzZXMgb24gQ0dOQVQvUENQLCB0aGVuIGFzIGENCj4+IGdl bnVpbmUgdXNlciB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIGluIEI0IGFkZHJlc3MsIEkgd2lsbCBu b3QgYmUgYWJsZSB0bw0KPj4gY3JlYXRlIGFuZCB1c2UgYWxsIG15IHF1b3RhIG9mIG1hcHBpbmdz LCBhcyB0aGVyZSB3b3VsZCBiZSBzb21lIHN0YWxlDQo+PiBtYXBwaW5ncyBjcmVhdGVkIGJlZm9y ZSBteSBCNCBjaGFuZ2UgZWF0aW5nIG15IHF1b3RhLg0KPg0KPklnbm9yaW5nIFBDUCBmb3IgYSBt b21lbnQsIHRoYXQgcHJvYmxlbSBleGlzdHMgd2l0aCBpbXBsaWNpdCBtYXBwaW5ncyBpZg0KPnRo ZSBJU1AgcmVudW1iZXJzIGhvc3RzIGJlaGluZCB0aGUgQ0dOLiAgSSBhZG1pdCB0aGF0IFBDUCdz IGxvbmcNCj5saWZldGltZXMgY2FuIG1ha2UgdGhhdCBwcm9ibGVtIHdvcnNlLiAgT25lIGVhc3kg c29sdXRpb24gaXMgdG8gcmVkdWNlDQo+dGhlIG1heGltdW0gYXNzaWduZWQgUENQIGxpZmV0aW1l IG9uIHRoZSBDR04gcHJpb3IgdG8gYW4gYWRkcmVzcyBjaGFuZ2UNCj5ldmVudCAtLSBtdWNoIGxp a2Ugd2UgZG8gd2l0aCBsb3dlcmluZyBETlMgVFRMIHByaW9yIHRvIGNoYW5naW5nIEROUw0KPnJl Y29yZHMuICBCdXQgcGVyaGFwcyBpdCBpcyBvcGVyYXRpb25hbGx5IGRpZmZpY3VsdCB0byBrbm93 IHdoZW4gYW4NCj5hZGRyZXNzIGNoYW5nZSBpcyBnb2luZyB0byBvY2N1ci4gIEEgc2xpZ2h0bHkg bW9yZSBkaWZmaWN1bHQgc29sdXRpb24sDQo+d2hpY2ggd29ya3MgZXZlbiBpZiBhZGRyZXNzIGNo YW5nZXMgYXJlbid0IHBsYW5uZWQsIGlzIHRvIHNlbmQgYSBQQ1ANCj5USElSRF9QQVJUWSBkZWxl dGUgbWVzc2FnZSBmcm9tIHRoZSBJU1AncyBtYW5hZ2VtZW50IHN5c3RlbSB3aGVuIGFuDQo+YWRk cmVzcyBjaGFuZ2Ugb2NjdXJzLg0KWWVzLCB3aXRoIHJlbnVtYmVyaW5nIHRoaXMgaXNzdWUgYXJp c2VzLiBUaGF0IGlzIHdoeSB3ZSByZWNvbW1lbmQgbm8NCnJlbnVtYmVyaW5nIHJpZ2h0PyBJbiB0 aGlzIHNjZW5hcmlvLCBwcmVmaXggcmVudW1iZXJpbmcgaGFzIG5vdCBvY2N1cnJlZCwNCmFuZCBp dCBpcyB0aGUgSVB2NiBhZGRyZXNzIHRoYXQgY2hhbmdlZCB3aXRoIGluIHRoZSBwcmVmaXguIFll cywgc2hvcnRlcg0KbGlmZSB0aW1lIHdvcmtzLCBidXQgSSBmZWVsIHRoYXQgYWRkcyBzeXNsb2co Y2FwdHVyaW5nIG1hcHBpbmdzIHR1cGxlcykNCm92ZXIgaGVhZC4NCldoZW4gYWRkcmVzcy9wcmVm aXggcmVudW1iZXJpbmcgaGFwcGVucywgSSBhZ3JlZSBhIHRoaXJkIHBhcnR5IGRlbGV0ZSBtc2dz DQpvciBhIGNsZWFyIGNvbW1hbmQsIG1heSBiZSBpc3N1ZWQgYnkgYWRtaW4uDQpJIGZlZWwgaXQg aXMgYW4gb3ZlciBraWxsIHRvIHVzZSB0aGlzIHdoZW4gYW4gYWRkcmVzcyB3aXRoIGluIHRoZSBw cmVmaXgNCmNoYW5nZXMgYW5kIG5vIHN1YnNjcmliZXIgcmVudW1iZXJpbmcgb2YgcHJlZml4IGhh cHBlbmVkLg0KVGhpcyBpcyBiZWNhdXNlIHdoZW4gbWFwcGluZ3MgYXJlIGRlbGV0ZWQsIHRoZWly IGFzc29jaWF0ZSBzdGF0ZSBsaWtlDQpmbG93cyBoYXZlIHRvIGJlIGRlbGV0ZWQuDQpUaGlzIGNh biBjYXVzZSBsb3Qgb2YgY2h1cm4gd2hlbiBkZWxldGlvbiBoYXBwZW5zIGF0IHRoZSBzYW1lIHRp bWUgZm9yDQptdWx0aXBsZSBhZGRyZXNzZXMuDQoNCj4NCj4+IEFuZCB0aGUgdHJhZmZpYw0KPj4g ZGVzdGluZWQgdG8gdGhvc2UgbWFwcGluZ3MgZnJvbSBpbnRlcm5ldCB3b3VsZCBiZSBwcm9jZXNz ZWQgYnkgQ0dOQVQgYm94DQo+PiBvbmx5IHRvIGJlIGRyb3BwZWQgYXQgQ1BFIQ0KPg0KPkJ1dCB0 aGUgQ1BFIGRyb3BwaW5nIHRob3NlIHBhY2tldHMgaXMgbm90IGEgbmV3IG9yIHNpZ25pZmljYW50 IHByb2JsZW0NCj53aGVuIHRoZSBJU1AgcmVudW1iZXJlZCB0aGUgc3Vic2NyaWJlci4gIFN1Y2gg ZHJvcHBpbmcgb2YgcGFja2V0cyB3b3VsZA0KPmhhcHBlbiBvbiB0b2RheSdzIElQdjQgSW50ZXJu ZXQgaWYgdGhlIElTUCByZW51bWJlcmVkIHR3byBzdWJzY3JpYmVycyB0bw0KPnN1ZGRlbmx5IGhh dmUgZWFjaCBvdGhlcidzIElQIGFkZHJlc3NlcyAtLSBwYWNrZXRzIHdvdWxkIGJlIHJvdXRlZCB0 byB0aGUNCj53cm9uZyBob21lIGFuZCBnZXQgZHJvcHBlZCBieSBOQVRzIG9yIGhvc3QtYmFzZWQg ZmlyZXdhbGxzLCBvciAoaWYgdGhleQ0KPmFyZW4ndCBkcm9wcGVkKSB0aGUgcGFja2V0cyB3b3Vs ZCBiZSBwcm9jZXNzZWQgYnkgdGhlIGhvc3QgdG8gY29uZnVzZSBUQ1ANCj5zdGFja3Mgb3IgYXBw bGljYXRpb25zLg0KTm90ZSwgSVNQIGhhcyBub3QgcmVudW1iZXJlZCB0aGUgc3Vic2NyaWJlciB3 aGlsZSBhc3NpZ25pbmcgcHJlZml4LiBJdCBpcw0KdGhlIElQdjYgYWRkcmVzcyBkZXJpdmVkIG91 dCBvZiB0aGUgcHJlZml4IHRoYXQgY2hhbmdlZCBjYXVzaW5nIHRoaXMuIEFsbA0KSSBhbSBzdWdn ZXN0aW5nIGlzLCBqdXN0IGxpa2Ugd2hlbiBhZGRyZXNzIGlzIGFzc2lnbmVkLCB3aXRob3V0DQpy ZW51bWJlcmluZyBzdWJzY3JpYmVyLCB5b3UgY2Fycnkgb3ZlciBtYXBwaW5ncyBhY3Jvc3MgcmVi b290LiBTaW1pbGFybHkNCndoZW4gcHJlZml4IGlzIGFzc2lnbmVkIHdpdGhvdXQgcmVudW1iZXJp bmcgc3Vic2NyaWJlciwgZXZlbiBpZiBhZGRyZXNzZXMNCndpdGhpbiB0aGUgcHJlZml4IGNoYW5n ZSBJIGZlZWwgbWFwcGluZ3MgY2FuIGJlIGNhcnJpZWQgYWNyb3NzIGFkZHJlc3Nlcw0Kd2l0aGlu IHRoZSBwcmVmaXgsIGFuZCBpbiBhZGRpdGlvbiB3ZSBoYXZlIHRvIGhhdmUgcGVyIHByZWZpeCBs aW1pdHMsIGFzDQoic3Vic2NyaWJlciIgaXMgcmVwcmVzZW50ZWQgYnkgcHJlZml4IGFuZCBub3Qg SVB2NiBhZGRyZXNzLg0KDQpJIGZlZWwgd2hlbiB0aGVyZSBpcyBubyByZW51bWJlcmluZyBvZiBz dWJzY3JpYmVyIHdoaWxlIGFzc2lnbmluZyBwcmVmaXgsDQppdCBzaG91bGQgYmUgdHJlYXRlZCB0 aGUgc2FtZSBhcyB3aGVuIHRoZXJlIGlzIGFzIGFkZHJlc3MgYXNzaWdubWVudA0Kd2l0aG91dCBy ZW51bWJlcmluZyBvZiBzdWJzY3JpYmVyLiBUaGUgdmFsdWUgSSBzZWUgaGVyZSBpcywgaG9zdHMg YmVoaW5kDQpCNCwgY2FuIGRpcmVjdGx5IHVzZSB0aGUgbWFwcGluZ3MsIGFuZCByZXB1Ymxpc2hp bmcgb2YgdGhvc2UgbWFwcGluZ3MgdG8NCmV4dGVybmFsIHdvcmxkIGNhbiBiZSBhdm9pZGVkLCBl ZmZlY3RpdmUgdXRpbGl6YXRpb24gb2YgcG9ydCBsaW1pdCBxdW90YQ0KYW5kIG90aGVyIENHTkFU IHJlc291cmNlcy4gWWVzLCB3ZSBoYXZlIHRvIGRlYmF0ZSBpZiBpdCBpbnRyb2R1Y2VzIGFueQ0K aXNzdWVzLg0KPg0KPi1kDQo+DQo+PiANCj4+IFBsZWFzZSBjb21tZW50Lg0KPj4gDQo+PiBTdXJl c2gNCj4+IA0KPj4gDQo+PiBPbiA2LzIxLzEzIDc6MDggUE0sICJEYW4gV2luZyIgPGR3aW5nQGNp c2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+PiANCj4+PiBPbiBKdW4gMjEsIDIwMTMsIGF0IDY6MTYg UE0sICJSZWluYWxkbyBQZW5ubyAocmVwZW5ubykiDQo+Pj4gPHJlcGVubm9AY2lzY28uY29tPiB3 cm90ZToNCj4+PiANCj4+Pj4gSXQgc2VlbXMgeW91IGFyZSBzdWdnZXN0aW5nIGEgcGVyIHByZWZp eCBiaW5kaW5nLiBTbywgaW4geW91ciBleGFtcGxlDQo+Pj4+aWYNCj4+Pj4gaW50ZXJuYWwgaG9z dCAxMC4wLjAuMiBzZW5kcyBhIG5ldyBNQVAgcmVxdWVzdCB0aGF0IHVzZXMgMzAwMTpiIGFzDQo+ Pj4+IHNvdXJjZQ0KPj4+PiBhZGRyZXNzLCB0aGUgQUZUUiBzaG91bGQgdXBkYXRlIGFueSBleGlz dGluZyBtYXBwaW5ncyB0byB1c2UgdGhpcyBuZXcNCj4+Pj4gc291cmNlIElQdjYgdG8gcmVhY2gg dGhlIEI0IHdoaWxlIGV4dGVybmFsIHB1YmxpYyBJUDpwb3J0IHdvdWxkIGJlIHRoZQ0KPj4+PiBz YW1lLiBUaGVyZWZvcmUgbm8gbmVlZCB0byB1cGRhdGUgZHluRE5TIG9yIG90aGVyIHN0dWZmLg0K Pj4+PiANCj4+Pj4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0IHRoaXMgaXMgaW50ZXJl c3RpbmcuDQo+Pj4gDQo+Pj4gVGhhbmtzIGZvciBzdW1tYXJpemluZyAtIEkgdW5kZXJzdGFuZCB0 aGUgcHJvcG9zYWwgbm93LiAgSXQgc2VlbXMgdG8NCj4+PiByZXF1aXJlIHRoZSBCNCBhbmQgdGhl IEFGVFIga25vdyB0aGF0IHRoZSBzYW1lIElQdjQgbWFwcGluZyBpcw0KPj4+YXZhaWxhYmxlDQo+ Pj4gYWZ0ZXIgSVB2NiByZW51bWJlcmluZyAtLSBzcGVjaWZpY2FsbHkgdGhhdCB0aGUgc2FtZSBB RlRSIGlzIGJlaW5nIHVzZWQNCj4+PiBhbmQgaXQgd2lsbCBhc3NpZ24gdGhlIHNhbWUgSVB2NCBh ZGRyZXNzIHRvIHRoZSBCNC4gIFNlZW1zIGEgbG90IG9mDQo+Pj4gY29vcmRpbmF0aW9uIGJldHdl ZW4gdGhlIEI0IGFuZCBBRlRSIHRvIGF2b2lkIHVwZGF0aW5nIGEgcmVuZGV6dm91cw0KPj4+IHNl cnZlci4gIEhvd2V2ZXIsIHRoZSBob3N0IChhbmQgdGhlIEI0KSB3aWxsIGFsd2F5cyBuZWVkIHRv IGJlIGFibGUgdG8NCj4+PiBoYW5kbGUgbmV0d29yayByZW51bWJlcmluZyB3aGVyZSB0aGUgc2Ft ZSBJUHY0IG1hcHBpbmcgaXMgbm90DQo+Pj5hdmFpbGFibGUsDQo+Pj4gc28gdGhpcyBpbmNyZWFz ZXMgaW1wbGVtZW50YXRpb24gYW5kIHRlc3RpbmcgZWZmb3J0LiAgVGhlIGdhaW4sIGluIG15DQo+ Pj4gbWluZCwgaXMgcHJldHR5IHNtYWxsIGVzcGVjaWFsbHkgY29uc2lkZXJpbmcgdGhlIElQIHJl bnVtYmVyaW5nIGhhcyB0bw0KPj4+YmUNCj4+PiBpbmZyZXF1ZW50IChvciBlbHNlIFRDUCBzZXNz aW9ucyBhcmUgZGlzcnVwdGVkLCBub2JvZHkgbXVjaCBhcHByZWNpYXRlcw0KPj4+IHRoYXQpLg0K Pj4+IA0KPj4+IC1kDQo+Pj4gDQo+Pj4gDQo+Pj4+IA0KPj4+PiBPbiA2LzIxLzEzIDk6MzcgUE0s ICJTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhIg0KPj4+PiA8c3VyZXNoa0BqdW5pcGVy Lm5ldD4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gSGkgTW9oYW1lZC9EYW4sDQo+Pj4+PiANCj4+Pj4+ IFRoYW5rcyBmb3IgcG9pbnRpbmcgdG8gdGhlIGRyYWZ0cy4NCj4+Pj4+IEkgdW5kZXJzdGFuZCBm cm9tIHRoZSBkcmFmdHMgdGhhdCBpZiBhIENQRSBpcyBhc3NpZ25lZCBhIHNhbWUgSVANCj4+Pj4+ IGFkZHJlc3MNCj4+Pj4+IGFmdGVyIHJlYm9vdCwgaW4gY2FzZSBvZiBEUy1MaXRlLCBQQ1AgcHJv eHkgc2hvdWxkIHNlbmQgQU5OT1VOQ0UNCj4+Pj4+IHJlcXVlc3QNCj4+Pj4+IHRvIHRoZSBQQ1Ag Y2xpZW50cy4NCj4+Pj4+IFRoaXMgd2F5LCBQQ1AgY2xpZW50cyB3b3VsZCByZWZyZXNoIHRoZWly IG1hcHBpbmdzLg0KPj4+Pj4gDQo+Pj4+PiBTdXBwb3NlIHByZWZpeCBzYXkgMzAwMTo6LzU2IGlz IGFzc2lnbmVkIHRvIENQRSBhZnRlciByZWJvb3QgYW5kIGlzDQo+Pj4+PiBzYW1lDQo+Pj4+PiBh cyBiZWZvcmUgcmVib290Lg0KPj4+Pj4gU3VwcG9zZSBJUHY2IGFkZHJlc3MgYmVmb3JlIHJlYm9v dCBpcyAzMDAxOjphIGFuZCBjcmVhdGVkIHNvbWUNCj4+Pj4+IG1hcHBpbmdzLg0KPj4+Pj4gDQo+ Pj4+PiBIb3dldmVyLCBhZnRlciBhIHJlYm9vdCwgYSBuZXcgSVB2NiBhZGRyZXNzIG1heSBiZSB0 YWtlbiBhcyBCNCBzYXkNCj4+Pj4+IDMwMDE6OmIuIA0KPj4+Pj4gQXMgcGVyIHRoZSBjdXJyZW50 IGRyYWZ0cywgY2xpZW50cyB3aWxsIHRyeSB0byByZWZyZXNoIG1hcHBpbmdzIHdpdGgNCj4+Pj4+ IHRoZQ0KPj4+Pj4gbmV3bHkgYXNzaWduZWQgSVB2NiBhZGRyZXNzIGFzIHRoZSBCNCBhZGRyZXNz Lg0KPj4+Pj4gU2luY2UgdGhlIHJlcXVlc3RzIGFyZSBmcm9tIHRoZSBkaWZmZXJlbnQgSVB2NiBh ZGRyZXNzLCBDR05BVCB3aWxsDQo+Pj4+PnRyeQ0KPj4+Pj4gdG8NCj4+Pj4+IGNyZWF0ZSBuZXcg bWFwcGluZ3MgYW5kIHRoZSBvbGQgbWFwcGluZ3MgaGF2ZSB0byBhZ2Ugb3V0Lg0KPj4+Pj4gTm93 IGhvc3RzIHVzaW5nIHRoZXNlIG1hcHBpbmdzIGhhdmUgdG8gcHVibGlzaCB0aGVzZSBtYXBwaW5n cywgZm9yDQo+Pj4+PiBleHRlcm5hbCBob3N0cyB0byBjb25uZWN0IHJpZ2h0PyBUaGlzIGlzIGFu IG92ZXJoZWFkLg0KPj4+Pj4gDQo+Pj4+PiBNeSBwb2ludCBpcywgdGhpcyBvdmVyIGhlYWQgY2Fu IGJlIGVsaW1pbmF0ZWQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZQ0KPj4+Pj5pbg0KPj4+Pj4gYWRk cmVzcyBpbiB0aGUgcHJlZml4LCB3aHkgZG8gd2UgbmVlZCB0byBmb3JjZSBjcmVhdGlvbiBvZiBu ZXcNCj4+Pj4+bWFwcGluZ3MNCj4+Pj4+IGFuZCB0aW1lb3V0IG9mIG9sZCBtYXBwaW5ncz8NCj4+ Pj4+IEluc3RlYWQsIGNhbiB0aGUgbWFwcGluZ3MgYW5kIHRoZSBjb3JyZXNwb25kaW5nIHRyYWZm aWMgYmUgbWlncmF0ZWQNCj4+Pj4+dG8NCj4+Pj4+IG5ld2VyIEI0PyANCj4+Pj4+IElmIHRoZSBz YW1lIGFkZHJlc3MgaXMgYWNxdWlyZWQgYnkgdGhlIEI0IGFmdGVyIHJlYm9vdCwgQ0dOQVQgYm94 DQo+Pj4+PiBkb2Vzbid0DQo+Pj4+PiBkaWZmZXJlbnRpYXRlIHJpZ2h0PyBJIGFtIHN1Z2dlc3Rp bmcgY2FuIHRoaXMgYmUgZXh0ZW5kZWQgdG8gcHJlZml4LA0KPj4+Pj4gc3VjaA0KPj4+Pj4gdGhh dCBhbnkgbWFwcGluZ3MgY3JlYXRlZCBvdmVyIG9uZSBCNCBhZGRyZXNzIG9mIHRoZSBwcmVmaXgg YmUNCj4+Pj4+IG1pZ3JhdGVkIHRvDQo+Pj4+PiBhbm90aGVyIEI0IGFkZHJlc3Mgd2l0aGluIHRo ZSBzYW1lIHByZWZpeD8NCj4+Pj4+IA0KPj4+Pj4gSWYgdGhlcmUgaXMgYSBjaGFuZ2UgaW4gcHJl Zml4LCB0aGVyZSBpcyBubyBvcHRpb24gdG8gbWlncmF0ZSBhcw0KPj4+Pj4gbWVudGlvbmVkLCBu ZXcgbWFwcGluZ3MgaGF2ZSB0byBiZSBjcmVhdGVkIGFuZCBvbGQgbWFwcGluZ3MgaGF2ZSB0bw0K Pj4+Pj4gZXhwaXJlLiANCj4+Pj4+IEFkZHJlc3MgY2hhbmdlIHdpdGggaW4gYSBwcmVmaXggY2Fu IGJlIGhhbmRsZWQgbW9yZSBncmFjZWZ1bGx5IHJpZ2h0Pw0KPj4+Pj4gQW0gSQ0KPj4+Pj4gbWlz c2luZyBzb21ldGhpbmc/DQo+Pj4+PiANCj4+Pj4+IC1TdXJlc2gNCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiANCj4+Pj4+IE9uIDYvMjEvMTMgMzo1NSBQTSwgIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28u Y29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE9uIEp1biAyMSwgMjAxMywgYXQg MjowMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4+PiANCj4+ Pj4+Pj4gSGkgU3VyZXNoLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gSWYgYSBuZXcgYWRkcmVzcyBpcyBh c3NpZ25lZCB0byB0aGUgQjQsIHRoZSBjby1sb2NhdGVkIFBDUCBjbGllbnQNCj4+Pj4+Pj4gd2ls bA0KPj4+Pj4+PiBuZWVkIHRvIHJlLWluc3RhbGwgdGhlIG1hcHBpbmdzIGl0IG1hbmFnZXMuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gV2hlbiBhIG5ldyBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIHRoZSBCNCwg dGhlIEI0J3MgUENQIHNlcnZlciBzaG91bGQNCj4+Pj4+PiBmb2xsb3cgdGhlIHByb2NlZHVyZXMg aW4gIkFkZHJlc3MgQ2hhbmdlIEV2ZW50cyIsDQo+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjg4NyNzZWN0aW9uLTExLjUuICBUaGUgaG9zdCB3aGljaA0KPj4+Pj4+IGNyZWF0 ZWQNCj4+Pj4+PiB0aGUgbWFwcGluZ3MgKHRoZSBQQ1AgY2xpZW50KSBuZWVkcyB0byBiZSBhd2Fy ZSBvZiB0aGUgYWRkcmVzcw0KPj4+Pj4+Y2hhbmdlDQo+Pj4+Pj4gdG8NCj4+Pj4+PiB1cGRhdGUg dGhlIGluZm9ybWF0aW9uIGluIHRoZSByZW5kZXp2b3VzIHNlcnZlciAoRE5TLCBTSVAsIFhNUFAs DQo+Pj4+Pj4gd2hhdGV2ZXIpLCB3aGljaCBtZWFucyB0aGUgQjQncyBQQ1Agc2VydmVyIGlzbid0 IGhlbHBpbmcgdGhpbmdzIGJ5DQo+Pj4+Pj4gdXBkYXRpbmcgbWFwcGluZ3Mgb24gdGhlIENHTiBi eSBpdHNlbGYuDQo+Pj4+Pj4gDQo+Pj4+Pj4gLWQNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+Pj4g VGhpcyB3aWxsIGJlIHNlZW4gYnkgdGhlIFBDUCBzZXJ2ZXIgYXMgbmV3IHJlcXVlc3RzIGlmIHRo ZSBQQ1ANCj4+Pj4+Pj5DbGllbnQNCj4+Pj4+Pj4gSVAgQWRkcmVzcyBpcyBub3QgYWxyZWFkeSBp biB1c2UgaW4gdGFibGUgb3IgcmVmcmVzaCBtYXBwaW5ncw0KPj4+Pj4+PiBvdGhlcndpc2UuDQo+ Pj4+Pj4+IEluIGJvdGggY2FzZXMsIHRoZXJlIGlzIGEgZmFpbHVyZSByaXNrIGR1ZSB0byB0aGUg cHJlc2VuY2Ugb2Ygc3RhbGUNCj4+Pj4+Pj4gbWFwcGluZ3MuIFlvdSBjYW4gY2hlY2s6DQo+Pj4+ Pj4+IA0KPj4+Pj4+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1w Y3AtZmFpbHVyZS0wNiNzZWN0aW9uLTIuDQo+Pj4+Pj4+NA0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ2hl ZXJzLA0KPj4+Pj4+PiBNZWQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERlIDogU3VyZXNoIEt1bWFyIFZp bmFwYW11bGEgVmVua2F0YSBbbWFpbHRvOnN1cmVzaGtAanVuaXBlci5uZXRdDQo+Pj4+Pj4+IEVu dm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMgMTc6MDYNCj4+Pj4+Pj4gw4AgOiBCT1VDQURBSVIg TW9oYW1lZCBPTE5DL09MTg0KPj4+Pj4+PiBDYyA6IHBjcEBpZXRmLm9yZzsgbXJ3QHBhaW5sZXNz LXNlY3VyaXR5LmNvbTsgZmR1cG9udEBpc2Mub3JnDQo+Pj4+Pj4+IE9iamV0IDogUmU6IENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlDQo+Pj4+Pj4+IEhh bmRsaW5nKQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gSGkgTW9oYW1tZWQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gbWlzc2luZyBzb21lIHRoaW5nLiBIb3cgY2FuIENH TkFUIGtub3csDQo+Pj4+Pj4+IHdoZXRoZXIgdGhlIHJlcXVlc3QgaXMgdG8gcmVmcmVzaCBleGlz dGluZyBtYXBwaW5ncyBvciBmb3IgbmV3DQo+Pj4+Pj4+IG1hcHBpbmdzDQo+Pj4+Pj4+IHdoZW4g dGhlIENQRSBhZGRyZXNzIGNoYW5nZWQ/DQo+Pj4+Pj4+IEFkZHJlc3NlcyBiZWhpbmQgQjQgY2Fu IG92ZXJsYXAgcmlnaHQ/IFRoZXkgaGF2ZSB0byByZWx5IG9uIEI0DQo+Pj4+Pj4+IGFkZHJlc3MN Cj4+Pj4+Pj4gcmlnaHQ/DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBTdXJlc2gNCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IE9uIEp1biAyMCwgMjAxMywgYXQgNjoyNSBBTSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iDQo+Pj4+Pj4+IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IERlYXIgU3VyZXNoLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gRldJVywgeW91 IG1heSBmaW5kIHNvbWUgdGV4dCBkZXNjcmliaW5nIHRoaXMgZmFpbHVyZSBjYXNlDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiANCj4+Pj4+Pj5hdDpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i b3VjYWRhaXItcGNwLWZhaWx1cmUtMDYjc2VjdGlvbg0KPj4+Pj4+Pi0yDQo+Pj4+Pj4+IC41DQo+ Pj4+Pj4+IC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4gTWVkDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBEZSA6IHBjcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGNwLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQNCj4+Pj4+Pj5kZQ0KPj4+Pj4+PiBTdXJlc2ggS3VtYXIgVmlu YXBhbXVsYSBWZW5rYXRhDQo+Pj4+Pj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMgMDI6 MDANCj4+Pj4+Pj4gw4AgOiBwY3BAaWV0Zi5vcmcNCj4+Pj4+Pj4gQ2MgOiBtcndAcGFpbmxlc3Mt c2VjdXJpdHkuY29tOyBmZHVwb250QGlzYy5vcmcNCj4+Pj4+Pj4gT2JqZXQgOiBbcGNwXSBDb21t ZW50cyBvbiBkcmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIChQQ1AgRFMtTGl0ZQ0KPj4+Pj4+PiBI YW5kbGluZykNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBIaSwgDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiBBbiBleHRlcm5hbCBJUCBhZGRyZXNzIG9mIHRoZSBDUEUgZGV2aWNlIG1heSBjaGFuZ2Ug YXMgYW5kIHdoZW4NCj4+Pj4+Pj5ESENQDQo+Pj4+Pj4+IGxlYXNlIGV4cGlyZXMgb3Igd2hlbiB0 aGVyZSBpcyBhIHJlYm9vdCBvZiBDUEUgZm9yIGFueSByZWFzb24uDQo+Pj4+Pj4+IFRyYWZmaWMg ZGVzdGluZWQgZnJvbSBleHRlcm5hbCB3b3JsZCwgdG8gdGhlc2UgbWFwcGluZ3MsIG1heSBub3QN Cj4+Pj4+Pj4gcmVhY2gNCj4+Pj4+Pj4gaW50ZW5kZWQgQ1BFLCBhcyB0aGVyZSBpcyBjaGFuZ2Ug aW4gZXh0ZXJuYWwgYWRkcmVzcy4NCj4+Pj4+Pj4gUkZDIDY4ODcgcmVjb21tZW5kcyBubyBob3N0 IHJlbnVtYmVyaW5nIHRvIGhhbmRsZSBpdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEhvd2V2ZXIgdGhp cyBpcyBub3Qgc3VmZmljaWVudCBpbiB2NiBlbnZpcm9ubWVudCBlc3BlY2lhbGx5IHdpdGgNCj4+ Pj4+Pj4gRFMtTGl0ZSwgd2hlcmUgYSBDUEUgaXMgYXNzaWduZWQgYSB2NnByZWZpeCBhbmQgaXMg ZnJlZSB0byB1c2UgYW55DQo+Pj4+Pj4+IGFkZHJlc3Mgd2l0aCBpbiB0aGUgcHJlZml4LiBUaG91 Z2ggREhQQ3Y2IG1heSBhc3NpZ24gc2FtZSBwcmVmaXgNCj4+Pj4+Pj50byBhDQo+Pj4+Pj4+IENQ RSwgdGhlIGhvc3QgcG9ydGlvbiBpcyB0eXBpY2FsbHkgZmlsbGVkIGJ5IENQRSBhbmQgdHlwaWNh bGx5IHdpdGgNCj4+Pj4+Pj4gbWFjDQo+Pj4+Pj4+IGFkZHJlc3MsIHdoaWNoIGNoYW5nZXMgd2hl biB0aGVyZSBpcyBhIGNoYW5nZSBpbiBDUEUgZGV2aWNlIG9yIGZvcg0KPj4+Pj4+PiBzb21lDQo+ Pj4+Pj4+IHJlYXNvbi4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBTaW5jZSB0aGUgZW5kIHN5c3RlbXMg KEhvc3RzIGJlaGluZCBDUEUvQjQsIGFuZCB0aGUgQ0dOIGJveCkgaGFzDQo+Pj4+Pj4+bm90DQo+ Pj4+Pj4+IHJlYm9vdGVkLCB0aGUgbWFwcGluZ3MgdGhhdCB3ZXJlIGNyZWF0ZWQgYmVmb3JlIGFu ZCB0aGUgdHJhZmZpYw0KPj4+Pj4+PiBkZXN0aW5lZA0KPj4+Pj4+PiB0byB0aG9zZSBtYXBwaW5n cyBpZiB0dW5uZWxlZCBvdmVyIHRvIG9sZCBCNCBhZGRyZXNzIHdvdWxkIGJlDQo+Pj4+Pj4+IGRy b3BwZWQgYnkNCj4+Pj4+Pj4gdGhlIENQRSBkZXZpY2UuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGlz IGFsc28gY2F1c2VzIG90aGVyIGluY29udmVuaWVuY2UgYXMgdGhlc2UgbWFwcGluZ3MgaGFuZ3Mg YXJvdW5kDQo+Pj4+Pj4+IHRpbGwgdGhleSB0aW1lb3V0KHNjYWxpbmcgaW1wYWN0IGFuZCBub24g dXNhZ2Ugb2YgcG9ydHMgYW5kIG1lbW9yeSkNCj4+Pj4+Pj4gb3IsDQo+Pj4+Pj4+IHVubGVzcywg YSBwYWNrZXQgZmFrZWQgd2l0aCB0aGUgb2xkIEI0IGFkZHJlc3MgYXMgc291cmNlIGFuZCBhDQo+ Pj4+Pj4+ZGVsZXRlDQo+Pj4+Pj4+IHJlcXVlc3QgaXMgaXNzdWVkLiBFdmVuIGlmIHRob3NlIG1h cHBpbmdzIGFyZSBkZWxldGVkICBpbiBzb21ld2F5LA0KPj4+Pj4+PmENCj4+Pj4+Pj4gbmV3DQo+ Pj4+Pj4+IHNldCBvZiBtYXBwaW5ncyBoYXZlIHRvIGJlIGNyZWF0ZWQgYW5kIHB1Ymxpc2hlZCBm b3IgZXh0ZXJuYWwgd29ybGQNCj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4gY29ubmVjdCwgZXZlcnkgdGlt ZSwgd2hlbiBzdWNoIGFuIGV2ZW50IGhhcHBlbnMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGlzIGlz IGEgc2NlbmFyaW8sIHdoZXJlIGVuZCBzeXN0ZW1zKGhvc3RzIGJlaGluZCBCNCBhbmQgQ0dOQVQN Cj4+Pj4+Pj4gZGV2aWNlKQ0KPj4+Pj4+PiBhcmUgbm90IHJlYm9vdGVkLCBidXQgaW50ZXJtZWRp YXRlIENQRSBkZXZpY2UgaXMgcmVib290ZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBTaW5jZSB0aGUg ZW5kIHN5c3RlbXMgYXJlIG5vdCByZWJvb3RlZCwgY2FuIHRob3NlIG1hcHBpbmdzIGJlDQo+Pj4+ Pj4+IG1pZ3JhdGVkDQo+Pj4+Pj4+IG92ZXIgRFMtTGl0ZSB0dW5uZWxzPw0KPj4+Pj4+PiANCj4+ Pj4+Pj4gVGhlcmUgYXJlIHR3byBvcHRpb25zIGhlcmUsIHRvIHJldXNlIHRoZXNlIG1hcHBpbmdz Lg0KPj4+Pj4+PiAJ4oKsIFRoZSBvcHRpb24gaXMsIGNyZWF0ZSBtYXBwaW5ncyBhbmQgZmxvd3Mg b24gcGVyIHByZWZpeC4gVGhpcyB3YXkNCj4+Pj4+Pj4gbWFwcGluZ3MgYW5kIGZsb3dzIGFyZSBt aWdyYXRlZCB0byBhbnkgYWRkcmVzcyBpbiB0aGUgc2FtZSBwcmVmaXgNCj4+Pj4+Pj4gd2hlbg0K Pj4+Pj4+PiBldmVyIHRoZXJlIGlzIGNoYW5nZSBpbiBhZGRyZXNzLiBUaGUgZGVzdGluYXRpb24g YWRkcmVzcyB0byBiZSB1c2VkDQo+Pj4+Pj4+IGJ5DQo+Pj4+Pj4+IHRoZSBDR05BVCBib3gsIHRv IHR1bm5lbCBwYWNrZXRzIG92ZXIgdGhvc2UgbWFwcGluZ3MgdG8gdGhlIENQRQ0KPj4+Pj4+PiBz aG91bGQNCj4+Pj4+Pj4gYmUgdGhlIGFkZHJlc3MgbGFzdCBzZWVuIGJ5IHRoZSBDR05BVCBmcm9t IHRoZSBDUEUgb2YgdGhlIHByZWZpeC4NCj4+Pj4+Pj4gVGhpcw0KPj4+Pj4+PiB3YXksIHRyYWZm aWMgb3ZlciBtYXBwaW5ncyBhbmQgZmxvd3MgY3JlYXRlZCBvdmVyIG9sZCBCNCBhZGRyZXNzLA0K Pj4+Pj4+PmNhbg0KPj4+Pj4+PiBjb250aW51ZSB0byByZWFjaCBpbnRlbmRlZCBob3N0IG92ZXIg dGhlIG5ldyBEUy1MaXRlIHR1bm5lbC4NCj4+Pj4+Pj4gCeKCrCBDUEUgdG8gYWNjZXB0IHBhY2tl dHMgZGVzdGluZWQgdG8gYW55IGFkZHJlc3MgaW4gdGhhdCBwcmVmaXguDQo+Pj4+Pj4+VGhpcw0K Pj4+Pj4+PiBtYXkgYmUgYSBnZW5lcmljIHN0YWNrIGNoYW5nZSBhbmQgbWF5IG5vdCBiZSBkZXNp cmFibGUuDQo+Pj4+Pj4+IFRoaXMgaXMgbm90IGNvdmVyZWQgaW4NCj4+Pj4+Pj4gaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIENhbiB0aGlz DQo+Pj4+Pj4+YmUNCj4+Pj4+Pj4gaW5jbHVkZWQgZm9yIHRoZSBkaXNjdXNzaW9uPw0KPj4+Pj4+ PiANCj4+Pj4+Pj4gUGxlYXNlIGNvbW1lbnQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAtU3VyZXNoDQo+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+IHBjcCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gcGNwQGlldGYub3JnDQo+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gcGNwIG1haWxpbmcgbGlzdA0K Pj4+Pj4gcGNwQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BjcA0KPj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+IA0KPg0KPg0KPg0KDQo= From mohamed.boucadair@orange.com Sun Jun 23 23:54:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FBA21E80C5 for ; Sun, 23 Jun 2013 23:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcutYXDanfVh for ; Sun, 23 Jun 2013 23:54:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DFE5C21E80C0 for ; Sun, 23 Jun 2013 23:54:28 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8F03E26432B; Mon, 24 Jun 2013 08:54:25 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5D693238056; Mon, 24 Jun 2013 08:54:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 24 Jun 2013 08:54:25 +0200 From: To: Suresh Kumar Vinapamula Venkata , Dan Wing Date: Mon, 24 Jun 2013 08:54:23 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5w Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.24.33321 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 06:54:33 -0000 SGkgU3VyZXNoLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQpDaGVlcnMsDQpNZWQNCg0KPi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPkRlwqA6IFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZl bmthdGEgW21haWx0bzpzdXJlc2hrQGp1bmlwZXIubmV0XQ0KPkVudm95w6nCoDogc2FtZWRpIDIy IGp1aW4gMjAxMyAwMjozNw0KPsOAwqA6IERhbiBXaW5nOyBCT1VDQURBSVIgTW9oYW1lZCBPTE5D L09MTg0KPkNjwqA6IG1yd0BwYWlubGVzcy1zZWN1cml0eS5jb207IHBjcEBpZXRmLm9yZzsgZmR1 cG9udEBpc2Mub3JnDQo+T2JqZXTCoDogUmU6IFtwY3BdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt cGNwLWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlIEhhbmRsaW5nKQ0KPg0KPkhpIE1vaGFtZWQvRGFu LA0KPg0KPlRoYW5rcyBmb3IgcG9pbnRpbmcgdG8gdGhlIGRyYWZ0cy4NCj5JIHVuZGVyc3RhbmQg ZnJvbSB0aGUgZHJhZnRzIHRoYXQgaWYgYSBDUEUgaXMgYXNzaWduZWQgYSBzYW1lIElQIGFkZHJl c3MNCj5hZnRlciByZWJvb3QsIGluIGNhc2Ugb2YgRFMtTGl0ZSwgUENQIHByb3h5IHNob3VsZCBz ZW5kIEFOTk9VTkNFIHJlcXVlc3QNCj50byB0aGUgUENQIGNsaWVudHMuDQo+VGhpcyB3YXksIFBD UCBjbGllbnRzIHdvdWxkIHJlZnJlc2ggdGhlaXIgbWFwcGluZ3MuDQo+DQo+U3VwcG9zZSBwcmVm aXggc2F5IDMwMDE6Oi81NiBpcyBhc3NpZ25lZCB0byBDUEUgYWZ0ZXIgcmVib290IGFuZCBpcyBz YW1lDQo+YXMgYmVmb3JlIHJlYm9vdC4NCj5TdXBwb3NlIElQdjYgYWRkcmVzcyBiZWZvcmUgcmVi b290IGlzIDMwMDE6OmEgYW5kIGNyZWF0ZWQgc29tZSBtYXBwaW5ncy4NCj4NCj5Ib3dldmVyLCBh ZnRlciBhIHJlYm9vdCwgYSBuZXcgSVB2NiBhZGRyZXNzIG1heSBiZSB0YWtlbiBhcyBCNCBzYXkN Cj4zMDAxOjpiLg0KPkFzIHBlciB0aGUgY3VycmVudCBkcmFmdHMsIGNsaWVudHMgd2lsbCB0cnkg dG8gcmVmcmVzaCBtYXBwaW5ncyB3aXRoIHRoZQ0KPm5ld2x5IGFzc2lnbmVkIElQdjYgYWRkcmVz cyBhcyB0aGUgQjQgYWRkcmVzcy4NCj5TaW5jZSB0aGUgcmVxdWVzdHMgYXJlIGZyb20gdGhlIGRp ZmZlcmVudCBJUHY2IGFkZHJlc3MsIENHTkFUIHdpbGwgdHJ5IHRvDQo+Y3JlYXRlIG5ldyBtYXBw aW5ncyBhbmQgdGhlIG9sZCBtYXBwaW5ncyBoYXZlIHRvIGFnZSBvdXQuDQo+Tm93IGhvc3RzIHVz aW5nIHRoZXNlIG1hcHBpbmdzIGhhdmUgdG8gcHVibGlzaCB0aGVzZSBtYXBwaW5ncywgZm9yDQo+ ZXh0ZXJuYWwgaG9zdHMgdG8gY29ubmVjdCByaWdodD8gVGhpcyBpcyBhbiBvdmVyaGVhZC4NCj4N Cj5NeSBwb2ludCBpcywgdGhpcyBvdmVyIGhlYWQgY2FuIGJlIGVsaW1pbmF0ZWQgd2hlbiB0aGVy ZSBpcyBhIGNoYW5nZSBpbg0KPmFkZHJlc3MgaW4gdGhlIHByZWZpeCwgd2h5IGRvIHdlIG5lZWQg dG8gZm9yY2UgY3JlYXRpb24gb2YgbmV3IG1hcHBpbmdzDQo+YW5kIHRpbWVvdXQgb2Ygb2xkIG1h cHBpbmdzPw0KPkluc3RlYWQsIGNhbiB0aGUgbWFwcGluZ3MgYW5kIHRoZSBjb3JyZXNwb25kaW5n IHRyYWZmaWMgYmUgbWlncmF0ZWQgdG8NCj5uZXdlciBCND8NCj5JZiB0aGUgc2FtZSBhZGRyZXNz IGlzIGFjcXVpcmVkIGJ5IHRoZSBCNCBhZnRlciByZWJvb3QsIENHTkFUIGJveCBkb2Vzbid0DQo+ ZGlmZmVyZW50aWF0ZSByaWdodD8gSSBhbSBzdWdnZXN0aW5nIGNhbiB0aGlzIGJlIGV4dGVuZGVk IHRvIHByZWZpeCwgc3VjaA0KPnRoYXQgYW55IG1hcHBpbmdzIGNyZWF0ZWQgb3ZlciBvbmUgQjQg YWRkcmVzcyBvZiB0aGUgcHJlZml4IGJlIG1pZ3JhdGVkIHRvDQo+YW5vdGhlciBCNCBhZGRyZXNz IHdpdGhpbiB0aGUgc2FtZSBwcmVmaXg/DQoNCltNZWRdIFRoaXMgcHJvcG9zYWwgaXMgbm90IHBj cC1zcGVjaWZpYy4gSXQgY2FuIGJlIGFwcGxpZWQgZm9yIGFsbCB0aGUgdHJhZmZpYyBpbiBjYXNl IG9ubHkgb25lIEI0IGlzIGFzc3VtZWQgdG8gYmUgbW91bnRlZCBpbiB0aGUgY3VzdG9tZXIgc2lk ZSArIGEgbmV3IGFkZHJlc3MgdGhhdCBiZWxvbmdzIHRvIHRoZSBzYW1lIHByZWZpeCBpcyBhc3Np Z25lZCB0byBCNC4gDQoNCj4NCj5JZiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBwcmVmaXgsIHRoZXJl IGlzIG5vIG9wdGlvbiB0byBtaWdyYXRlIGFzDQo+bWVudGlvbmVkLCBuZXcgbWFwcGluZ3MgaGF2 ZSB0byBiZSBjcmVhdGVkIGFuZCBvbGQgbWFwcGluZ3MgaGF2ZSB0bw0KPmV4cGlyZS4NCltNZWRd IFllcy4NCg0KPkFkZHJlc3MgY2hhbmdlIHdpdGggaW4gYSBwcmVmaXggY2FuIGJlIGhhbmRsZWQg bW9yZSBncmFjZWZ1bGx5IHJpZ2h0PyBBbSBJDQo+bWlzc2luZyBzb21ldGhpbmc/DQo+DQo+LVN1 cmVzaA0KPg0KPg0KPg0KPk9uIDYvMjEvMTMgMzo1NSBQTSwgIkRhbiBXaW5nIiA8ZHdpbmdAY2lz Y28uY29tPiB3cm90ZToNCj4NCj4+DQo+Pk9uIEp1biAyMSwgMjAxMywgYXQgMjowMiBBTSwgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+DQo+Pj4gSGkgU3VyZXNoLA0KPj4+ DQo+Pj4gSWYgYSBuZXcgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byB0aGUgQjQsIHRoZSBjby1sb2Nh dGVkIFBDUCBjbGllbnQgd2lsbA0KPj4+bmVlZCB0byByZS1pbnN0YWxsIHRoZSBtYXBwaW5ncyBp dCBtYW5hZ2VzLg0KPj4NCj4+V2hlbiBhIG5ldyBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIHRoZSBC NCwgdGhlIEI0J3MgUENQIHNlcnZlciBzaG91bGQNCj4+Zm9sbG93IHRoZSBwcm9jZWR1cmVzIGlu ICJBZGRyZXNzIENoYW5nZSBFdmVudHMiLA0KPj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2ODg3I3NlY3Rpb24tMTEuNS4gIFRoZSBob3N0IHdoaWNoIGNyZWF0ZWQNCj4+dGhlIG1hcHBp bmdzICh0aGUgUENQIGNsaWVudCkgbmVlZHMgdG8gYmUgYXdhcmUgb2YgdGhlIGFkZHJlc3MgY2hh bmdlIHRvDQo+PnVwZGF0ZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIHJlbmRlenZvdXMgc2VydmVy IChETlMsIFNJUCwgWE1QUCwNCj4+d2hhdGV2ZXIpLCB3aGljaCBtZWFucyB0aGUgQjQncyBQQ1Ag c2VydmVyIGlzbid0IGhlbHBpbmcgdGhpbmdzIGJ5DQo+PnVwZGF0aW5nIG1hcHBpbmdzIG9uIHRo ZSBDR04gYnkgaXRzZWxmLg0KPj4NCj4+LWQNCj4+DQo+Pg0KPj4+IFRoaXMgd2lsbCBiZSBzZWVu IGJ5IHRoZSBQQ1Agc2VydmVyIGFzIG5ldyByZXF1ZXN0cyBpZiB0aGUgUENQIENsaWVudA0KPj4+ SVAgQWRkcmVzcyBpcyBub3QgYWxyZWFkeSBpbiB1c2UgaW4gdGFibGUgb3IgcmVmcmVzaCBtYXBw aW5ncyBvdGhlcndpc2UuDQo+Pj5JbiBib3RoIGNhc2VzLCB0aGVyZSBpcyBhIGZhaWx1cmUgcmlz ayBkdWUgdG8gdGhlIHByZXNlbmNlIG9mIHN0YWxlDQo+Pj5tYXBwaW5ncy4gWW91IGNhbiBjaGVj azoNCj4+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1wY3AtZmFp bHVyZS0wNiNzZWN0aW9uLTIuNA0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IE1lZA0KPj4+DQo+Pj4g RGUgOiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhIFttYWlsdG86c3VyZXNoa0BqdW5p cGVyLm5ldF0NCj4+PiBFbnZvecOpIDogamV1ZGkgMjAganVpbiAyMDEzIDE3OjA2DQo+Pj4gw4Ag OiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTg0KPj4+IENjIDogcGNwQGlldGYub3JnOyBtcndA cGFpbmxlc3Mtc2VjdXJpdHkuY29tOyBmZHVwb250QGlzYy5vcmcNCj4+PiBPYmpldCA6IFJlOiBD b21tZW50cyBvbiBkcmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIChQQ1AgRFMtTGl0ZSBIYW5kbGlu ZykNCj4+Pg0KPj4+IEhpIE1vaGFtbWVkDQo+Pj4NCj4+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJ IGFtIG1pc3Npbmcgc29tZSB0aGluZy4gSG93IGNhbiBDR05BVCBrbm93LA0KPj4+d2hldGhlciB0 aGUgcmVxdWVzdCBpcyB0byByZWZyZXNoIGV4aXN0aW5nIG1hcHBpbmdzIG9yIGZvciBuZXcgbWFw cGluZ3MNCj4+PndoZW4gdGhlIENQRSBhZGRyZXNzIGNoYW5nZWQ/DQo+Pj4gQWRkcmVzc2VzIGJl aGluZCBCNCBjYW4gb3ZlcmxhcCByaWdodD8gVGhleSBoYXZlIHRvIHJlbHkgb24gQjQgYWRkcmVz cw0KPj4+cmlnaHQ/DQo+Pj4NCj4+PiBTdXJlc2gNCj4+Pg0KPj4+IE9uIEp1biAyMCwgMjAxMywg YXQgNjoyNSBBTSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iDQo+Pj48bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBEZWFyIFN1cmVzaCwNCj4+Pg0K Pj4+IEZXSVcsIHlvdSBtYXkgZmluZCBzb21lIHRleHQgZGVzY3JpYmluZyB0aGlzIGZhaWx1cmUg Y2FzZQ0KPj4+YXQ6aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXBj cC1mYWlsdXJlLTA2I3NlY3Rpb24tMi41Lg0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IE1lZA0KPj4+ DQo+Pj4gRGUgOiBwY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlDQo+Pj5TdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhDQo+ Pj4gRW52b3nDqSA6IGpldWRpIDIwIGp1aW4gMjAxMyAwMjowMA0KPj4+IMOAIDogcGNwQGlldGYu b3JnDQo+Pj4gQ2MgOiBtcndAcGFpbmxlc3Mtc2VjdXJpdHkuY29tOyBmZHVwb250QGlzYy5vcmcN Cj4+PiBPYmpldCA6IFtwY3BdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4g KFBDUCBEUy1MaXRlDQo+Pj5IYW5kbGluZykNCj4+Pg0KPj4+DQo+Pj4gSGksDQo+Pj4NCj4+PiBB biBleHRlcm5hbCBJUCBhZGRyZXNzIG9mIHRoZSBDUEUgZGV2aWNlIG1heSBjaGFuZ2UgYXMgYW5k IHdoZW4gREhDUA0KPj4+bGVhc2UgZXhwaXJlcyBvciB3aGVuIHRoZXJlIGlzIGEgcmVib290IG9m IENQRSBmb3IgYW55IHJlYXNvbi4NCj4+PiBUcmFmZmljIGRlc3RpbmVkIGZyb20gZXh0ZXJuYWwg d29ybGQsIHRvIHRoZXNlIG1hcHBpbmdzLCBtYXkgbm90IHJlYWNoDQo+Pj5pbnRlbmRlZCBDUEUs IGFzIHRoZXJlIGlzIGNoYW5nZSBpbiBleHRlcm5hbCBhZGRyZXNzLg0KPj4+IFJGQyA2ODg3IHJl Y29tbWVuZHMgbm8gaG9zdCByZW51bWJlcmluZyB0byBoYW5kbGUgaXQuDQo+Pj4NCj4+PiBIb3dl dmVyIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQgaW4gdjYgZW52aXJvbm1lbnQgZXNwZWNpYWxseSB3 aXRoDQo+Pj5EUy1MaXRlLCB3aGVyZSBhIENQRSBpcyBhc3NpZ25lZCBhIHY2cHJlZml4IGFuZCBp cyBmcmVlIHRvIHVzZSBhbnkNCj4+PmFkZHJlc3Mgd2l0aCBpbiB0aGUgcHJlZml4LiBUaG91Z2gg REhQQ3Y2IG1heSBhc3NpZ24gc2FtZSBwcmVmaXggdG8gYQ0KPj4+Q1BFLCB0aGUgaG9zdCBwb3J0 aW9uIGlzIHR5cGljYWxseSBmaWxsZWQgYnkgQ1BFIGFuZCB0eXBpY2FsbHkgd2l0aCBtYWMNCj4+ PmFkZHJlc3MsIHdoaWNoIGNoYW5nZXMgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBDUEUgZGV2 aWNlIG9yIGZvciBzb21lDQo+Pj5yZWFzb24uDQo+Pj4NCj4+PiBTaW5jZSB0aGUgZW5kIHN5c3Rl bXMgKEhvc3RzIGJlaGluZCBDUEUvQjQsIGFuZCB0aGUgQ0dOIGJveCkgaGFzIG5vdA0KPj4+cmVi b290ZWQsIHRoZSBtYXBwaW5ncyB0aGF0IHdlcmUgY3JlYXRlZCBiZWZvcmUgYW5kIHRoZSB0cmFm ZmljIGRlc3RpbmVkDQo+Pj50byB0aG9zZSBtYXBwaW5ncyBpZiB0dW5uZWxlZCBvdmVyIHRvIG9s ZCBCNCBhZGRyZXNzIHdvdWxkIGJlIGRyb3BwZWQgYnkNCj4+PnRoZSBDUEUgZGV2aWNlLg0KPj4+ DQo+Pj4gVGhpcyBhbHNvIGNhdXNlcyBvdGhlciBpbmNvbnZlbmllbmNlIGFzIHRoZXNlIG1hcHBp bmdzIGhhbmdzIGFyb3VuZA0KPj4+dGlsbCB0aGV5IHRpbWVvdXQoc2NhbGluZyBpbXBhY3QgYW5k IG5vbiB1c2FnZSBvZiBwb3J0cyBhbmQgbWVtb3J5KSBvciwNCj4+PnVubGVzcywgYSBwYWNrZXQg ZmFrZWQgd2l0aCB0aGUgb2xkIEI0IGFkZHJlc3MgYXMgc291cmNlIGFuZCBhIGRlbGV0ZQ0KPj4+ cmVxdWVzdCBpcyBpc3N1ZWQuIEV2ZW4gaWYgdGhvc2UgbWFwcGluZ3MgYXJlIGRlbGV0ZWQgIGlu IHNvbWV3YXksIGEgbmV3DQo+Pj5zZXQgb2YgbWFwcGluZ3MgaGF2ZSB0byBiZSBjcmVhdGVkIGFu ZCBwdWJsaXNoZWQgZm9yIGV4dGVybmFsIHdvcmxkIHRvDQo+Pj5jb25uZWN0LCBldmVyeSB0aW1l LCB3aGVuIHN1Y2ggYW4gZXZlbnQgaGFwcGVucy4NCj4+Pg0KPj4+IFRoaXMgaXMgYSBzY2VuYXJp bywgd2hlcmUgZW5kIHN5c3RlbXMoaG9zdHMgYmVoaW5kIEI0IGFuZCBDR05BVCBkZXZpY2UpDQo+ Pj5hcmUgbm90IHJlYm9vdGVkLCBidXQgaW50ZXJtZWRpYXRlIENQRSBkZXZpY2UgaXMgcmVib290 ZWQuDQo+Pj4NCj4+PiBTaW5jZSB0aGUgZW5kIHN5c3RlbXMgYXJlIG5vdCByZWJvb3RlZCwgY2Fu IHRob3NlIG1hcHBpbmdzIGJlIG1pZ3JhdGVkDQo+Pj5vdmVyIERTLUxpdGUgdHVubmVscz8NCj4+ Pg0KPj4+IFRoZXJlIGFyZSB0d28gb3B0aW9ucyBoZXJlLCB0byByZXVzZSB0aGVzZSBtYXBwaW5n cy4NCj4+PiAJ4oKsIFRoZSBvcHRpb24gaXMsIGNyZWF0ZSBtYXBwaW5ncyBhbmQgZmxvd3Mgb24g cGVyIHByZWZpeC4gVGhpcyB3YXkNCj4+Pm1hcHBpbmdzIGFuZCBmbG93cyBhcmUgbWlncmF0ZWQg dG8gYW55IGFkZHJlc3MgaW4gdGhlIHNhbWUgcHJlZml4IHdoZW4NCj4+PmV2ZXIgdGhlcmUgaXMg Y2hhbmdlIGluIGFkZHJlc3MuIFRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIHRvIGJlIHVzZWQgYnkN Cj4+PnRoZSBDR05BVCBib3gsIHRvIHR1bm5lbCBwYWNrZXRzIG92ZXIgdGhvc2UgbWFwcGluZ3Mg dG8gdGhlIENQRSBzaG91bGQNCj4+PmJlIHRoZSBhZGRyZXNzIGxhc3Qgc2VlbiBieSB0aGUgQ0dO QVQgZnJvbSB0aGUgQ1BFIG9mIHRoZSBwcmVmaXguIFRoaXMNCj4+PndheSwgdHJhZmZpYyBvdmVy IG1hcHBpbmdzIGFuZCBmbG93cyBjcmVhdGVkIG92ZXIgb2xkIEI0IGFkZHJlc3MsIGNhbg0KPj4+ Y29udGludWUgdG8gcmVhY2ggaW50ZW5kZWQgaG9zdCBvdmVyIHRoZSBuZXcgRFMtTGl0ZSB0dW5u ZWwuDQo+Pj4gCeKCrCBDUEUgdG8gYWNjZXB0IHBhY2tldHMgZGVzdGluZWQgdG8gYW55IGFkZHJl c3MgaW4gdGhhdCBwcmVmaXguIFRoaXMNCj4+Pm1heSBiZSBhIGdlbmVyaWMgc3RhY2sgY2hhbmdl IGFuZCBtYXkgbm90IGJlIGRlc2lyYWJsZS4NCj4+PiBUaGlzIGlzIG5vdCBjb3ZlcmVkIGluDQo+ Pj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGNwLWRzbGl0ZS0w MC4gQ2FuIHRoaXMgYmUNCj4+PmluY2x1ZGVkIGZvciB0aGUgZGlzY3Vzc2lvbj8NCj4+Pg0KPj4+ IFBsZWFzZSBjb21tZW50Lg0KPj4+DQo+Pj4gLVN1cmVzaA0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcGNwIG1haWxpbmcgbGlzdA0KPj4+ IHBjcEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNwDQo+Pg0KPj4NCj4+DQo+DQo+DQoNCg== From sureshk@juniper.net Mon Jun 24 09:01:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2535F21F9385 for ; Mon, 24 Jun 2013 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIGJZnLOmPHY for ; Mon, 24 Jun 2013 09:01:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id DE48D11E8150 for ; Mon, 24 Jun 2013 09:01:41 -0700 (PDT) Received: from mail16-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 16:01:41 +0000 Received: from mail16-ch1 (localhost [127.0.0.1]) by mail16-ch1-R.bigfish.com (Postfix) with ESMTP id 3C8B22C0110 for ; Mon, 24 Jun 2013 16:01:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -77 X-BigFish: PS-77(zzbb2dI98dI9371Ic89bh148cI1432I15caKJ168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail16-ch1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=sureshk@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail16-ch1 (localhost.localdomain [127.0.0.1]) by mail16-ch1 (MessageSwitch) id 1372089698905251_20297; Mon, 24 Jun 2013 16:01:38 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail16-ch1.bigfish.com (Postfix) with ESMTP id CEC0DC004F for ; Mon, 24 Jun 2013 16:01:38 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 16:01:37 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 24 Jun 2013 09:01:36 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 24 Jun 2013 09:01:36 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 09:13:29 -0700 Received: from mail144-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 16:01:34 +0000 Received: from mail144-co1 (localhost [127.0.0.1]) by mail144-co1-R.bigfish.com (Postfix) with ESMTP id 645E6CA034D for ; Mon, 24 Jun 2013 16:01:34 +0000 (UTC) Received: from mail144-co1 (localhost.localdomain [127.0.0.1]) by mail144-co1 (MessageSwitch) id 1372089690725017_16249; Mon, 24 Jun 2013 16:01:30 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.241]) by mail144-co1.bigfish.com (Postfix) with ESMTP id ACABEC80050; Mon, 24 Jun 2013 16:01:30 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 24 Jun 2013 16:01:30 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 16:01:29 +0000 From: Suresh Kumar Vinapamula Venkata To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5wgACaorc= Date: Mon, 24 Jun 2013 16:01:29 +0000 Message-ID: <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net> References: , <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.136.207.230] Content-Type: text/plain; charset="Windows-1252" 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%ORANGE.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 X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 16:01:48 -0000 Hi Mohamed=20 Yes it can be extended to other traffic.=20 When it comes to flows, typically they are short lived and so they may expi= re even before they are migrated.=20 Pcp creates mappings that can be long lived, and there is an effort involve= d in publishing those mappings for connectivity from external world. Also t= here is a conservation of NAT resources, and so the discussion. Just curious, is there a reason why there would be more than one B4 on cust= omer end?=20 Suresh On Jun 23, 2013, at 11:54 PM, "mohamed.boucadair@orange.com" wrote: > Hi Suresh,=20 >=20 > Please see inline. > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >> Envoy=E9 : samedi 22 juin 2013 02:37 >> =C0 : Dan Wing; BOUCADAIR Mohamed OLNC/OLN >> Cc : mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org >> Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Han= dling) >>=20 >> Hi Mohamed/Dan, >>=20 >> Thanks for pointing to the drafts. >> I understand from the drafts that if a CPE is assigned a same IP address >> after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE request >> to the PCP clients. >> This way, PCP clients would refresh their mappings. >>=20 >> Suppose prefix say 3001::/56 is assigned to CPE after reboot and is same >> as before reboot. >> Suppose IPv6 address before reboot is 3001::a and created some mappings. >>=20 >> However, after a reboot, a new IPv6 address may be taken as B4 say >> 3001::b. >> As per the current drafts, clients will try to refresh mappings with the >> newly assigned IPv6 address as the B4 address. >> Since the requests are from the different IPv6 address, CGNAT will try t= o >> create new mappings and the old mappings have to age out. >> Now hosts using these mappings have to publish these mappings, for >> external hosts to connect right? This is an overhead. >>=20 >> My point is, this over head can be eliminated when there is a change in >> address in the prefix, why do we need to force creation of new mappings >> and timeout of old mappings? >> Instead, can the mappings and the corresponding traffic be migrated to >> newer B4? >> If the same address is acquired by the B4 after reboot, CGNAT box doesn'= t >> differentiate right? I am suggesting can this be extended to prefix, suc= h >> that any mappings created over one B4 address of the prefix be migrated = to >> another B4 address within the same prefix? >=20 > [Med] This proposal is not pcp-specific. It can be applied for all the tr= affic in case only one B4 is assumed to be mounted in the customer side + a= new address that belongs to the same prefix is assigned to B4.=20 >=20 >>=20 >> If there is a change in prefix, there is no option to migrate as >> mentioned, new mappings have to be created and old mappings have to >> expire. > [Med] Yes. >=20 >> Address change with in a prefix can be handled more gracefully right? Am= I >> missing something? >>=20 >> -Suresh >>=20 >>=20 >>=20 >> On 6/21/13 3:55 PM, "Dan Wing" wrote: >>=20 >>>=20 >>> On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: >>>=20 >>>> Hi Suresh, >>>>=20 >>>> If a new address is assigned to the B4, the co-located PCP client will >>>> need to re-install the mappings it manages. >>>=20 >>> When a new address is assigned to the B4, the B4's PCP server should >>> follow the procedures in "Address Change Events", >>> http://tools.ietf.org/html/rfc6887#section-11.5. The host which create= d >>> the mappings (the PCP client) needs to be aware of the address change t= o >>> update the information in the rendezvous server (DNS, SIP, XMPP, >>> whatever), which means the B4's PCP server isn't helping things by >>> updating mappings on the CGN by itself. >>>=20 >>> -d >>>=20 >>>=20 >>>> This will be seen by the PCP server as new requests if the PCP Client >>>> IP Address is not already in use in table or refresh mappings otherwis= e. >>>> In both cases, there is a failure risk due to the presence of stale >>>> mappings. You can check: >>>> http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.4 >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>>> Envoy=E9 : jeudi 20 juin 2013 17:06 >>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >>>> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handlin= g) >>>>=20 >>>> Hi Mohammed >>>>=20 >>>> Please correct me if I am missing some thing. How can CGNAT know, >>>> whether the request is to refresh existing mappings or for new mapping= s >>>> when the CPE address changed? >>>> Addresses behind B4 can overlap right? They have to rely on B4 address >>>> right? >>>>=20 >>>> Suresh >>>>=20 >>>> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >>>> wrote: >>>>=20 >>>> Dear Suresh, >>>>=20 >>>> FWIW, you may find some text describing this failure case >>>> at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2= .5. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >>>> Suresh Kumar Vinapamula Venkata >>>> Envoy=E9 : jeudi 20 juin 2013 02:00 >>>> =C0 : pcp@ietf.org >>>> Cc : mrw@painless-security.com; fdupont@isc.org >>>> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>> Handling) >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> An external IP address of the CPE device may change as and when DHCP >>>> lease expires or when there is a reboot of CPE for any reason. >>>> Traffic destined from external world, to these mappings, may not reach >>>> intended CPE, as there is change in external address. >>>> RFC 6887 recommends no host renumbering to handle it. >>>>=20 >>>> However this is not sufficient in v6 environment especially with >>>> DS-Lite, where a CPE is assigned a v6prefix and is free to use any >>>> address with in the prefix. Though DHPCv6 may assign same prefix to a >>>> CPE, the host portion is typically filled by CPE and typically with ma= c >>>> address, which changes when there is a change in CPE device or for som= e >>>> reason. >>>>=20 >>>> Since the end systems (Hosts behind CPE/B4, and the CGN box) has not >>>> rebooted, the mappings that were created before and the traffic destin= ed >>>> to those mappings if tunneled over to old B4 address would be dropped = by >>>> the CPE device. >>>>=20 >>>> This also causes other inconvenience as these mappings hangs around >>>> till they timeout(scaling impact and non usage of ports and memory) or= , >>>> unless, a packet faked with the old B4 address as source and a delete >>>> request is issued. Even if those mappings are deleted in someway, a n= ew >>>> set of mappings have to be created and published for external world to >>>> connect, every time, when such an event happens. >>>>=20 >>>> This is a scenario, where end systems(hosts behind B4 and CGNAT device= ) >>>> are not rebooted, but intermediate CPE device is rebooted. >>>>=20 >>>> Since the end systems are not rebooted, can those mappings be migrated >>>> over DS-Lite tunnels? >>>>=20 >>>> There are two options here, to reuse these mappings. >>>> =80 The option is, create mappings and flows on per prefix. This wa= y >>>> mappings and flows are migrated to any address in the same prefix when >>>> ever there is change in address. The destination address to be used by >>>> the CGNAT box, to tunnel packets over those mappings to the CPE should >>>> be the address last seen by the CGNAT from the CPE of the prefix. This >>>> way, traffic over mappings and flows created over old B4 address, can >>>> continue to reach intended host over the new DS-Lite tunnel. >>>> =80 CPE to accept packets destined to any address in that prefix. T= his >>>> may be a generic stack change and may not be desirable. >>>> This is not covered in >>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this be >>>> included for the discussion? >>>>=20 >>>> Please comment. >>>>=20 >>>> -Suresh >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >=20 From dwing@cisco.com Mon Jun 24 09:25:57 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EB21E811A for ; Mon, 24 Jun 2013 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.516 X-Spam-Level: X-Spam-Status: No, score=-109.516 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUI9rOD3CJmP for ; Mon, 24 Jun 2013 09:25:52 -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 D5AB321E810D for ; Mon, 24 Jun 2013 09:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17530; q=dns/txt; s=iport; t=1372091152; x=1373300752; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/nKhzAbLZMXsDCBr4opRlfiWEByBtvzPH8ECr1OORBg=; b=MxERWAD4sLpjAFAo1cuculSR0oXVGhhrrggQyDHngGriG1jjsUMcoPo5 td0dXtrswvkg+StSpbSnIsnR2GLJ1ZfP+QikpR8N/HyeHph0u1mCa8AVb 67EC7al1KhJ27rxkvJimFx3BUCNZwb6D34WpulpY8a/kxyWlLNKC+0nVM 4=; X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="81171784" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 24 Jun 2013 16:25:51 +0000 Received: from [10.32.240.195] ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5OGPopZ007737; Mon, 24 Jun 2013 16:25:50 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Mon, 24 Jun 2013 09:25:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Suresh Kumar Vinapamula Venkata X-Mailer: Apple Mail (2.1508) Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 16:25:57 -0000 On Jun 22, 2013, at 1:02 AM, Suresh Kumar Vinapamula Venkata = wrote: >=20 >=20 > On 6/21/13 10:06 PM, "Dan Wing" wrote: >=20 >>=20 >> On Jun 21, 2013, at 9:32 PM, Suresh Kumar Vinapamula Venkata >> wrote: >>=20 >>> Yes Reinaldo, that is correct. >>>=20 >>> Dan,=20 >>>=20 >>> Note, it is the CPE that rebooted or went bad and so changed. >>> End systems are not rebooted. >>>=20 >>> With no renumbering CPE is assigned same v6 prefix 3001::. >>> Depending on the algorithm to fill in the host portion forming a B4 >>> prefix, a new B4 address 3001::b can be picked which is different = from >>> old >>> B4 address 3001::a. >>>=20 >>> Since the end systems 10.0.0.2 haven't rebooted, they should be able = to >>> continue using those mappings. When hosts behind B4 sees ANNOUNCE, = and >>> sends refresh requests, it would not result in creating a new = mapping >>> but >>> use existing mapping. The benefit, hosts behind B4 don't need to = publish >>> to external world about the change, to receive traffic from external >>> world. >>=20 >> What are the security implications of 3001::b taking over 3001::a's >> mappings? Is there a way to ensure that doesn't happen maliciously? >=20 > Since Since they are from the same prefix, and the prefix len > configuration is under admin control, I am not thinking of any _new_ > malicious attacks. Nothing comes immediately to mind. When the details are written down it = will bear careful consideration. Separate from security implications, I remain skeptical of how often a = B4 element would forget its previous IPv6 address or the network would = refuse to give its old address back, yet the B4 is still able to = remember mappings (to re-validate the mappings with the AFTR). -d > If you think of any such scenarios, can you please point them? >=20 >>=20 >>=20 >>>=20 >>> Consider a case where an IPv6 address is assigned and not prefix to = the >>> CPE. >>> If the same IPv6 address assigned after reboot or change of CPE, = hosts >>> on >>> seeing PCP ANNOUNCE, when refreshes their mappings, PCP server = responses >>> back with the existing mapping, it is not going to create new set of >>> mappings and age out existing mappings right? >>>=20 >>> I am extending the same argument to prefixes, where CPEs are = assigned >>> with >>> prefixes and are free to use any v6 address in the prefix as B4 = address. >>> So, change in that address should not result in creating new = mappings >>> and >>> age out old mappings. >>>=20 >>> Suppose if we go with the approach defined in the drafts where new >>> mappings have to be created when there is change in address, as an >>> attacker, I can exhaust CGNAT/PCP server resources, by picking = multiple >>> IPv6 addresses with in the assigned prefix as B4 and faking PCP >>> requests. >>=20 >> That attack is still possible with your idea. The mitigation, with = or >> without your idea, is that the AFTR has to apply its port quota to = the >> entirety of the IPv6 prefix assigned to a B4 -- the entire = "subscriber", >> if you will -- typically the entire /64. That seems an important = point >> to include in draft-ietf-pcp-dslite. > Yes, resources have to be configured on per prefix basis. In addition = to > that, if we are not migrating mappings, you would be eating up the = quota > because of the stale mappings that I mentioned below right? >>=20 >>> If we limit the resources on per prefix bases on CGNAT/PCP, then as = a >>> genuine user when there is a change in B4 address, I will not be = able to >>> create and use all my quota of mappings, as there would be some = stale >>> mappings created before my B4 change eating my quota. >>=20 >> Ignoring PCP for a moment, that problem exists with implicit mappings = if >> the ISP renumbers hosts behind the CGN. I admit that PCP's long >> lifetimes can make that problem worse. One easy solution is to = reduce >> the maximum assigned PCP lifetime on the CGN prior to an address = change >> event -- much like we do with lowering DNS TTL prior to changing DNS >> records. But perhaps it is operationally difficult to know when an >> address change is going to occur. A slightly more difficult = solution, >> which works even if address changes aren't planned, is to send a PCP >> THIRD_PARTY delete message from the ISP's management system when an >> address change occurs. > Yes, with renumbering this issue arises. That is why we recommend no > renumbering right? In this scenario, prefix renumbering has not = occurred, > and it is the IPv6 address that changed with in the prefix. Yes, = shorter > life time works, but I feel that adds syslog(capturing mappings = tuples) > over head. > When address/prefix renumbering happens, I agree a third party delete = msgs > or a clear command, may be issued by admin. > I feel it is an over kill to use this when an address with in the = prefix > changes and no subscriber renumbering of prefix happened. > This is because when mappings are deleted, their associate state like > flows have to be deleted. > This can cause lot of churn when deletion happens at the same time for > multiple addresses. >=20 >>=20 >>> And the traffic >>> destined to those mappings from internet would be processed by CGNAT = box >>> only to be dropped at CPE! >>=20 >> But the CPE dropping those packets is not a new or significant = problem >> when the ISP renumbered the subscriber. Such dropping of packets = would >> happen on today's IPv4 Internet if the ISP renumbered two subscribers = to >> suddenly have each other's IP addresses -- packets would be routed to = the >> wrong home and get dropped by NATs or host-based firewalls, or (if = they >> aren't dropped) the packets would be processed by the host to confuse = TCP >> stacks or applications. > Note, ISP has not renumbered the subscriber while assigning prefix. It = is > the IPv6 address derived out of the prefix that changed causing this. = All > I am suggesting is, just like when address is assigned, without > renumbering subscriber, you carry over mappings across reboot. = Similarly > when prefix is assigned without renumbering subscriber, even if = addresses > within the prefix change I feel mappings can be carried across = addresses > within the prefix, and in addition we have to have per prefix limits, = as > "subscriber" is represented by prefix and not IPv6 address. >=20 > I feel when there is no renumbering of subscriber while assigning = prefix, > it should be treated the same as when there is as address assignment > without renumbering of subscriber. The value I see here is, hosts = behind > B4, can directly use the mappings, and republishing of those mappings = to > external world can be avoided, effective utilization of port limit = quota > and other CGNAT resources. Yes, we have to debate if it introduces any > issues. >>=20 >> -d >>=20 >>>=20 >>> Please comment. >>>=20 >>> Suresh >>>=20 >>>=20 >>> On 6/21/13 7:08 PM, "Dan Wing" wrote: >>>=20 >>>>=20 >>>> On Jun 21, 2013, at 6:16 PM, "Reinaldo Penno (repenno)" >>>> wrote: >>>>=20 >>>>> It seems you are suggesting a per prefix binding. So, in your = example >>>>> if >>>>> internal host 10.0.0.2 sends a new MAP request that uses 3001:b as >>>>> source >>>>> address, the AFTR should update any existing mappings to use this = new >>>>> source IPv6 to reach the B4 while external public IP:port would be = the >>>>> same. Therefore no need to update dynDNS or other stuff. >>>>>=20 >>>>> If my understanding is correct this is interesting. >>>>=20 >>>> Thanks for summarizing - I understand the proposal now. It seems = to >>>> require the B4 and the AFTR know that the same IPv4 mapping is >>>> available >>>> after IPv6 renumbering -- specifically that the same AFTR is being = used >>>> and it will assign the same IPv4 address to the B4. Seems a lot of >>>> coordination between the B4 and AFTR to avoid updating a rendezvous >>>> server. However, the host (and the B4) will always need to be able = to >>>> handle network renumbering where the same IPv4 mapping is not >>>> available, >>>> so this increases implementation and testing effort. The gain, in = my >>>> mind, is pretty small especially considering the IP renumbering has = to >>>> be >>>> infrequent (or else TCP sessions are disrupted, nobody much = appreciates >>>> that). >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>>=20 >>>>> On 6/21/13 9:37 PM, "Suresh Kumar Vinapamula Venkata" >>>>> wrote: >>>>>=20 >>>>>> Hi Mohamed/Dan, >>>>>>=20 >>>>>> Thanks for pointing to the drafts. >>>>>> I understand from the drafts that if a CPE is assigned a same IP >>>>>> address >>>>>> after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE >>>>>> request >>>>>> to the PCP clients. >>>>>> This way, PCP clients would refresh their mappings. >>>>>>=20 >>>>>> Suppose prefix say 3001::/56 is assigned to CPE after reboot and = is >>>>>> same >>>>>> as before reboot. >>>>>> Suppose IPv6 address before reboot is 3001::a and created some >>>>>> mappings. >>>>>>=20 >>>>>> However, after a reboot, a new IPv6 address may be taken as B4 = say >>>>>> 3001::b.=20 >>>>>> As per the current drafts, clients will try to refresh mappings = with >>>>>> the >>>>>> newly assigned IPv6 address as the B4 address. >>>>>> Since the requests are from the different IPv6 address, CGNAT = will >>>>>> try >>>>>> to >>>>>> create new mappings and the old mappings have to age out. >>>>>> Now hosts using these mappings have to publish these mappings, = for >>>>>> external hosts to connect right? This is an overhead. >>>>>>=20 >>>>>> My point is, this over head can be eliminated when there is a = change >>>>>> in >>>>>> address in the prefix, why do we need to force creation of new >>>>>> mappings >>>>>> and timeout of old mappings? >>>>>> Instead, can the mappings and the corresponding traffic be = migrated >>>>>> to >>>>>> newer B4?=20 >>>>>> If the same address is acquired by the B4 after reboot, CGNAT box >>>>>> doesn't >>>>>> differentiate right? I am suggesting can this be extended to = prefix, >>>>>> such >>>>>> that any mappings created over one B4 address of the prefix be >>>>>> migrated to >>>>>> another B4 address within the same prefix? >>>>>>=20 >>>>>> If there is a change in prefix, there is no option to migrate as >>>>>> mentioned, new mappings have to be created and old mappings have = to >>>>>> expire.=20 >>>>>> Address change with in a prefix can be handled more gracefully = right? >>>>>> Am I >>>>>> missing something? >>>>>>=20 >>>>>> -Suresh >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 6/21/13 3:55 PM, "Dan Wing" wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: >>>>>>>=20 >>>>>>>> Hi Suresh, >>>>>>>>=20 >>>>>>>> If a new address is assigned to the B4, the co-located PCP = client >>>>>>>> will >>>>>>>> need to re-install the mappings it manages. >>>>>>>=20 >>>>>>> When a new address is assigned to the B4, the B4's PCP server = should >>>>>>> follow the procedures in "Address Change Events", >>>>>>> http://tools.ietf.org/html/rfc6887#section-11.5. The host which >>>>>>> created >>>>>>> the mappings (the PCP client) needs to be aware of the address >>>>>>> change >>>>>>> to >>>>>>> update the information in the rendezvous server (DNS, SIP, XMPP, >>>>>>> whatever), which means the B4's PCP server isn't helping things = by >>>>>>> updating mappings on the CGN by itself. >>>>>>>=20 >>>>>>> -d >>>>>>>=20 >>>>>>>=20 >>>>>>>> This will be seen by the PCP server as new requests if the PCP >>>>>>>> Client >>>>>>>> IP Address is not already in use in table or refresh mappings >>>>>>>> otherwise. >>>>>>>> In both cases, there is a failure risk due to the presence of = stale >>>>>>>> mappings. You can check: >>>>>>>>=20 >>>>>>>> = http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2. >>>>>>>> 4 >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>> De : Suresh Kumar Vinapamula Venkata = [mailto:sureshk@juniper.net] >>>>>>>> Envoy=E9 : jeudi 20 juin 2013 17:06 >>>>>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>>>>>> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >>>>>>>> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>>>>>> Handling) >>>>>>>>=20 >>>>>>>> Hi Mohammed >>>>>>>>=20 >>>>>>>> Please correct me if I am missing some thing. How can CGNAT = know, >>>>>>>> whether the request is to refresh existing mappings or for new >>>>>>>> mappings >>>>>>>> when the CPE address changed? >>>>>>>> Addresses behind B4 can overlap right? They have to rely on B4 >>>>>>>> address >>>>>>>> right? >>>>>>>>=20 >>>>>>>> Suresh >>>>>>>>=20 >>>>>>>> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Dear Suresh, >>>>>>>>=20 >>>>>>>> FWIW, you may find some text describing this failure case >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section >>>>>>>> -2 >>>>>>>> .5 >>>>>>>> . >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la = part >>>>>>>> de >>>>>>>> Suresh Kumar Vinapamula Venkata >>>>>>>> Envoy=E9 : jeudi 20 juin 2013 02:00 >>>>>>>> =C0 : pcp@ietf.org >>>>>>>> Cc : mrw@painless-security.com; fdupont@isc.org >>>>>>>> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP = DS-Lite >>>>>>>> Handling) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi,=20 >>>>>>>>=20 >>>>>>>> An external IP address of the CPE device may change as and when >>>>>>>> DHCP >>>>>>>> lease expires or when there is a reboot of CPE for any reason. >>>>>>>> Traffic destined from external world, to these mappings, may = not >>>>>>>> reach >>>>>>>> intended CPE, as there is change in external address. >>>>>>>> RFC 6887 recommends no host renumbering to handle it. >>>>>>>>=20 >>>>>>>> However this is not sufficient in v6 environment especially = with >>>>>>>> DS-Lite, where a CPE is assigned a v6prefix and is free to use = any >>>>>>>> address with in the prefix. Though DHPCv6 may assign same = prefix >>>>>>>> to a >>>>>>>> CPE, the host portion is typically filled by CPE and typically = with >>>>>>>> mac >>>>>>>> address, which changes when there is a change in CPE device or = for >>>>>>>> some >>>>>>>> reason.=20 >>>>>>>>=20 >>>>>>>> Since the end systems (Hosts behind CPE/B4, and the CGN box) = has >>>>>>>> not >>>>>>>> rebooted, the mappings that were created before and the traffic >>>>>>>> destined >>>>>>>> to those mappings if tunneled over to old B4 address would be >>>>>>>> dropped by >>>>>>>> the CPE device. >>>>>>>>=20 >>>>>>>> This also causes other inconvenience as these mappings hangs = around >>>>>>>> till they timeout(scaling impact and non usage of ports and = memory) >>>>>>>> or, >>>>>>>> unless, a packet faked with the old B4 address as source and a >>>>>>>> delete >>>>>>>> request is issued. Even if those mappings are deleted in = someway, >>>>>>>> a >>>>>>>> new >>>>>>>> set of mappings have to be created and published for external = world >>>>>>>> to >>>>>>>> connect, every time, when such an event happens. >>>>>>>>=20 >>>>>>>> This is a scenario, where end systems(hosts behind B4 and CGNAT >>>>>>>> device) >>>>>>>> are not rebooted, but intermediate CPE device is rebooted. >>>>>>>>=20 >>>>>>>> Since the end systems are not rebooted, can those mappings be >>>>>>>> migrated >>>>>>>> over DS-Lite tunnels? >>>>>>>>=20 >>>>>>>> There are two options here, to reuse these mappings. >>>>>>>> =80 The option is, create mappings and flows on per = prefix. This way >>>>>>>> mappings and flows are migrated to any address in the same = prefix >>>>>>>> when >>>>>>>> ever there is change in address. The destination address to be = used >>>>>>>> by >>>>>>>> the CGNAT box, to tunnel packets over those mappings to the CPE >>>>>>>> should >>>>>>>> be the address last seen by the CGNAT from the CPE of the = prefix. >>>>>>>> This >>>>>>>> way, traffic over mappings and flows created over old B4 = address, >>>>>>>> can >>>>>>>> continue to reach intended host over the new DS-Lite tunnel. >>>>>>>> =80 CPE to accept packets destined to any address in = that prefix. >>>>>>>> This >>>>>>>> may be a generic stack change and may not be desirable. >>>>>>>> This is not covered in >>>>>>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can = this >>>>>>>> be >>>>>>>> included for the discussion? >>>>>>>>=20 >>>>>>>> Please comment. >>>>>>>>=20 >>>>>>>> -Suresh >>>>>>>> _______________________________________________ >>>>>>>> pcp mailing list >>>>>>>> pcp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pcp >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> pcp mailing list >>>>>> pcp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pcp >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 From sureshk@juniper.net Mon Jun 24 10:58:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2C21E8106 for ; Mon, 24 Jun 2013 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.623 X-Spam-Level: * X-Spam-Status: No, score=1.623 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, MIME_BASE64_BLANKS=0.041, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzaPAWHHjBUD for ; Mon, 24 Jun 2013 10:58:05 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 867CD21E811C for ; Mon, 24 Jun 2013 10:58:04 -0700 (PDT) Received: from mail168-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE039.bigfish.com (10.174.4.102) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 17:58:03 +0000 Received: from mail168-db8 (localhost [127.0.0.1]) by mail168-db8-R.bigfish.com (Postfix) with ESMTP id 77AEE8000E7 for ; Mon, 24 Jun 2013 17:58:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Ic89bh148cI1432I168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h683h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail168-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=sureshk@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail168-db8 (localhost.localdomain [127.0.0.1]) by mail168-db8 (MessageSwitch) id 1372096680367930_1945; Mon, 24 Jun 2013 17:58:00 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.235]) by mail168-db8.bigfish.com (Postfix) with ESMTP id 540562A0049 for ; Mon, 24 Jun 2013 17:58:00 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.52) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 17:57:57 +0000 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; Mon, 24 Jun 2013 10:57:55 -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; Mon, 24 Jun 2013 10:57:55 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 24 Jun 2013 11:01:12 -0700 Received: from mail71-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.23; Mon, 24 Jun 2013 17:57:50 +0000 Received: from mail71-db9 (localhost [127.0.0.1]) by mail71-db9-R.bigfish.com (Postfix) with ESMTP id 52D192EC0192 for ; Mon, 24 Jun 2013 17:57:50 +0000 (UTC) Received: from mail71-db9 (localhost.localdomain [127.0.0.1]) by mail71-db9 (MessageSwitch) id 1372096667863201_22534; Mon, 24 Jun 2013 17:57:47 +0000 (UTC) Received: from DB9EHSMHS013.bigfish.com (unknown [10.174.16.240]) by mail71-db9.bigfish.com (Postfix) with ESMTP id CE66435C0031; Mon, 24 Jun 2013 17:57:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS013.bigfish.com (10.174.14.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Jun 2013 17:57:47 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0324.000; Mon, 24 Jun 2013 17:57:41 +0000 From: Suresh Kumar Vinapamula Venkata To: Dan Wing Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAAgGEAgAAOhoD//7LFAIAAfuuA//+4moAAhTuJAP//pE6A Date: Mon, 24 Jun 2013 17:57:42 +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.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 17:58:11 -0000 DQoNCk9uIDYvMjQvMTMgOToyNSBBTSwgIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28uY29tPiB3cm90 ZToNCg0KPg0KPk9uIEp1biAyMiwgMjAxMywgYXQgMTowMiBBTSwgU3VyZXNoIEt1bWFyIFZpbmFw YW11bGEgVmVua2F0YQ0KPjxzdXJlc2hrQGp1bmlwZXIubmV0PiB3cm90ZToNCj4NCj4+IA0KPj4g DQo+PiBPbiA2LzIxLzEzIDEwOjA2IFBNLCAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5jb20+IHdy b3RlOg0KPj4gDQo+Pj4gDQo+Pj4gT24gSnVuIDIxLCAyMDEzLCBhdCA5OjMyIFBNLCBTdXJlc2gg S3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhDQo+Pj4gPHN1cmVzaGtAanVuaXBlci5uZXQ+IHdyb3Rl Og0KPj4+IA0KPj4+PiBZZXMgUmVpbmFsZG8sIHRoYXQgaXMgY29ycmVjdC4NCj4+Pj4gDQo+Pj4+ IERhbiwgDQo+Pj4+IA0KPj4+PiBOb3RlLCBpdCBpcyB0aGUgQ1BFIHRoYXQgcmVib290ZWQgb3Ig d2VudCBiYWQgYW5kIHNvIGNoYW5nZWQuDQo+Pj4+IEVuZCBzeXN0ZW1zIGFyZSBub3QgcmVib290 ZWQuDQo+Pj4+IA0KPj4+PiBXaXRoIG5vIHJlbnVtYmVyaW5nIENQRSBpcyBhc3NpZ25lZCBzYW1l IHY2IHByZWZpeCAzMDAxOjouDQo+Pj4+IERlcGVuZGluZyBvbiB0aGUgYWxnb3JpdGhtIHRvIGZp bGwgaW4gdGhlIGhvc3QgcG9ydGlvbiBmb3JtaW5nIGEgQjQNCj4+Pj4gcHJlZml4LCBhIG5ldyBC NCBhZGRyZXNzIDMwMDE6OmIgY2FuIGJlIHBpY2tlZCB3aGljaCBpcyBkaWZmZXJlbnQgZnJvbQ0K Pj4+PiBvbGQNCj4+Pj4gQjQgYWRkcmVzcyAzMDAxOjphLg0KPj4+PiANCj4+Pj4gU2luY2UgdGhl IGVuZCBzeXN0ZW1zIDEwLjAuMC4yIGhhdmVuJ3QgcmVib290ZWQsIHRoZXkgc2hvdWxkIGJlIGFi bGUNCj4+Pj50bw0KPj4+PiBjb250aW51ZSB1c2luZyB0aG9zZSBtYXBwaW5ncy4gV2hlbiBob3N0 cyBiZWhpbmQgQjQgc2VlcyBBTk5PVU5DRSwgYW5kDQo+Pj4+IHNlbmRzIHJlZnJlc2ggcmVxdWVz dHMsIGl0IHdvdWxkIG5vdCByZXN1bHQgaW4gY3JlYXRpbmcgYSBuZXcgbWFwcGluZw0KPj4+PiBi dXQNCj4+Pj4gdXNlIGV4aXN0aW5nIG1hcHBpbmcuIFRoZSBiZW5lZml0LCBob3N0cyBiZWhpbmQg QjQgZG9uJ3QgbmVlZCB0bw0KPj4+PnB1Ymxpc2gNCj4+Pj4gdG8gZXh0ZXJuYWwgd29ybGQgYWJv dXQgdGhlIGNoYW5nZSwgdG8gcmVjZWl2ZSB0cmFmZmljIGZyb20gZXh0ZXJuYWwNCj4+Pj4gd29y bGQuDQo+Pj4gDQo+Pj4gV2hhdCBhcmUgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiAzMDAx OjpiIHRha2luZyBvdmVyIDMwMDE6OmEncw0KPj4+IG1hcHBpbmdzPyAgSXMgdGhlcmUgYSB3YXkg dG8gZW5zdXJlIHRoYXQgZG9lc24ndCBoYXBwZW4gbWFsaWNpb3VzbHk/DQo+PiANCj4+IFNpbmNl IFNpbmNlIHRoZXkgYXJlIGZyb20gdGhlIHNhbWUgcHJlZml4LCBhbmQgdGhlIHByZWZpeCBsZW4N Cj4+IGNvbmZpZ3VyYXRpb24gaXMgdW5kZXIgYWRtaW4gY29udHJvbCwgSSBhbSBub3QgdGhpbmtp bmcgb2YgYW55IF9uZXdfDQo+PiBtYWxpY2lvdXMgYXR0YWNrcy4NCj4NCj5Ob3RoaW5nIGNvbWVz IGltbWVkaWF0ZWx5IHRvIG1pbmQuICBXaGVuIHRoZSBkZXRhaWxzIGFyZSB3cml0dGVuIGRvd24g aXQNCj53aWxsIGJlYXIgY2FyZWZ1bCBjb25zaWRlcmF0aW9uLg0KSSBhZ3JlZS4gSSB0aG91Z2h0 IGFib3V0IGl0IGFuZCBjb3VsZCBub3QgY29tZSB1cCB3aXRoIGFueSBfbmV3XyBtYWxpY2lvdXMN CmF0dGFja3MsIEkgdGhpbmsgbW9yZS4NCj4NCj4NCj5TZXBhcmF0ZSBmcm9tIHNlY3VyaXR5IGlt cGxpY2F0aW9ucywgSSByZW1haW4gc2tlcHRpY2FsIG9mIGhvdyBvZnRlbiBhIEI0DQo+ZWxlbWVu dCB3b3VsZCBmb3JnZXQgaXRzIHByZXZpb3VzIElQdjYgYWRkcmVzcyBvciB0aGUgbmV0d29yayB3 b3VsZA0KPnJlZnVzZSB0byBnaXZlIGl0cyBvbGQgYWRkcmVzcyBiYWNrLCB5ZXQgdGhlIEI0IGlz IHN0aWxsIGFibGUgdG8gcmVtZW1iZXINCj5tYXBwaW5ncyAodG8gcmUtdmFsaWRhdGUgdGhlIG1h cHBpbmdzIHdpdGggdGhlIEFGVFIpLg0KSXQgaXMgbm90IGZvciBCNCwgdGhlc2UgbWFwcGluZ3Mg YXJlIGNyZWF0ZWQuIEl0IGlzIGZvciB0aGUgaG9zdHMgYmVoaW5kDQpCNCB0aGF0IHRoZXNlIG1h cHBpbmdzIGFyZSBjcmVhdGVkLiBEb2VzIEI0IG5lZWQgdG8gYmUgc3RhdGVmdWwgZm9yIHRoZXNl DQptYXBwaW5ncz8NCg0KV2hlbiBldmVyIHByb3h5L0I0IHJlYm9vdHMgb3IgY2hhbmdlZCwgaXQg aXMgc3VwcG9zZWQgdG8gYnJvYWRjYXN0IGFuDQpBTk5PVU5DRSBpbiBpdHMgbmV0d29yaywgZm9y IHRoZSBob3N0cyBiZWhpbmQgaXQgdG8gcmVmcmVzaCB0aGVpcg0KbWFwcGluZ3MuIFRoaXMgaXMg c3VnZ2VzdGVkIGluIG11bHRpcGxlIGRyYWZ0cy4NCkFsbCBJIGFtIHRyeWluZyBzdWdnZXN0IGlz IHRvIGV4dGVuZCB0aGlzIHRvIHByZWZpeCBsZXZlbCwgd2hlcmUgYSBwcmVmaXgNCmlzIGFzc2ln bmVkIHRvIENQRS4gSG9zdHMgYmVoaW5kIEI0IG9uIHNlZWluZyBBTk5PVU5DRSwgaW5pdGlhdGUg bWFwcGluZw0KcmVmcmVzaCByZXF1ZXN0cywgQ0dOQVQgd2hlbiB0cmFja2VkIG1hcHBpbmdzIGF0 IHByZWZpeCBsZXZlbCwgd291bGQgYmUNCmFibGUgdG8gbWlncmF0ZSB0aGVzZSBtYXBwaW5ncyBl dmVuIHRvIG5ld2VyIEI0LiBUaGlzIHdpbGwgY29uc2VydmUNCnJlc291cmNlcyBhbmQsIGF2b2lk IG92ZXJoZWFkIHdoaWNoIHdlIGtub3cgd2hlbiB0aGVyZSBpcyBzdWJzY3JpYmVyDQpyZW51bWJl cmluZy4NCiANCklmIHRoaXMgaXMgbm90IGRvbmUsIGV2ZW4gaWYgYWRtaW4gZW5zdXJlcyBubyBz dWJzY3JpYmVyIHJlbnVtYmVyaW5nIG9mDQpwcmVmaXgsIGl0IGRvZXNuJ3QgZ3VhcmFudHkgdGhh dCBob3N0cyBjYW4gY29udGludWUgdXNpbmcgbWFwcGluZ3MgdGhleQ0KcHJldmlvdXNseSBjcmVh dGVkIGFzIEI0IGFkZHJlc3MgbWF5IGNoYW5nZS4NCg0KPg0KPi1kDQo+DQo+DQo+PiBJZiB5b3Ug dGhpbmsgb2YgYW55IHN1Y2ggc2NlbmFyaW9zLCBjYW4geW91IHBsZWFzZSBwb2ludCB0aGVtPw0K Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4+IA0KPj4+PiBDb25zaWRlciBhIGNhc2Ugd2hlcmUgYW4gSVB2 NiBhZGRyZXNzIGlzIGFzc2lnbmVkIGFuZCBub3QgcHJlZml4IHRvDQo+Pj4+dGhlDQo+Pj4+IENQ RS4NCj4+Pj4gSWYgdGhlIHNhbWUgSVB2NiBhZGRyZXNzIGFzc2lnbmVkIGFmdGVyIHJlYm9vdCBv ciBjaGFuZ2Ugb2YgQ1BFLCBob3N0cw0KPj4+PiBvbg0KPj4+PiBzZWVpbmcgUENQIEFOTk9VTkNF LCB3aGVuIHJlZnJlc2hlcyB0aGVpciBtYXBwaW5ncywgUENQIHNlcnZlcg0KPj4+PnJlc3BvbnNl cw0KPj4+PiBiYWNrIHdpdGggdGhlIGV4aXN0aW5nIG1hcHBpbmcsIGl0IGlzIG5vdCBnb2luZyB0 byBjcmVhdGUgbmV3IHNldCBvZg0KPj4+PiBtYXBwaW5ncyBhbmQgYWdlIG91dCBleGlzdGluZyBt YXBwaW5ncyByaWdodD8NCj4+Pj4gDQo+Pj4+IEkgYW0gZXh0ZW5kaW5nIHRoZSBzYW1lIGFyZ3Vt ZW50IHRvIHByZWZpeGVzLCB3aGVyZSBDUEVzIGFyZSBhc3NpZ25lZA0KPj4+PiB3aXRoDQo+Pj4+ IHByZWZpeGVzIGFuZCBhcmUgZnJlZSB0byB1c2UgYW55IHY2IGFkZHJlc3MgaW4gdGhlIHByZWZp eCBhcyBCNA0KPj4+PmFkZHJlc3MuDQo+Pj4+IFNvLCBjaGFuZ2UgaW4gdGhhdCBhZGRyZXNzIHNo b3VsZCBub3QgcmVzdWx0IGluIGNyZWF0aW5nIG5ldyBtYXBwaW5ncw0KPj4+PiBhbmQNCj4+Pj4g YWdlIG91dCBvbGQgbWFwcGluZ3MuDQo+Pj4+IA0KPj4+PiBTdXBwb3NlIGlmIHdlIGdvIHdpdGgg dGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gdGhlIGRyYWZ0cyB3aGVyZSBuZXcNCj4+Pj4gbWFwcGlu Z3MgaGF2ZSB0byBiZSBjcmVhdGVkIHdoZW4gdGhlcmUgaXMgY2hhbmdlIGluIGFkZHJlc3MsIGFz IGFuDQo+Pj4+IGF0dGFja2VyLCBJIGNhbiBleGhhdXN0IENHTkFUL1BDUCBzZXJ2ZXIgcmVzb3Vy Y2VzLCBieSBwaWNraW5nDQo+Pj4+bXVsdGlwbGUNCj4+Pj4gSVB2NiBhZGRyZXNzZXMgd2l0aCBp biB0aGUgYXNzaWduZWQgcHJlZml4IGFzIEI0IGFuZCBmYWtpbmcgUENQDQo+Pj4+IHJlcXVlc3Rz Lg0KPj4+IA0KPj4+IFRoYXQgYXR0YWNrIGlzIHN0aWxsIHBvc3NpYmxlIHdpdGggeW91ciBpZGVh LiAgVGhlIG1pdGlnYXRpb24sIHdpdGggb3INCj4+PiB3aXRob3V0IHlvdXIgaWRlYSwgaXMgdGhh dCB0aGUgQUZUUiBoYXMgdG8gYXBwbHkgaXRzIHBvcnQgcXVvdGEgdG8gdGhlDQo+Pj4gZW50aXJl dHkgb2YgdGhlIElQdjYgcHJlZml4IGFzc2lnbmVkIHRvIGEgQjQgLS0gdGhlIGVudGlyZQ0KPj4+ InN1YnNjcmliZXIiLA0KPj4+IGlmIHlvdSB3aWxsIC0tIHR5cGljYWxseSB0aGUgZW50aXJlIC82 NC4gIFRoYXQgc2VlbXMgYW4gaW1wb3J0YW50IHBvaW50DQo+Pj4gdG8gaW5jbHVkZSBpbiBkcmFm dC1pZXRmLXBjcC1kc2xpdGUuDQo+PiBZZXMsIHJlc291cmNlcyBoYXZlIHRvIGJlIGNvbmZpZ3Vy ZWQgb24gcGVyIHByZWZpeCBiYXNpcy4gSW4gYWRkaXRpb24gdG8NCj4+IHRoYXQsIGlmIHdlIGFy ZSBub3QgbWlncmF0aW5nIG1hcHBpbmdzLCB5b3Ugd291bGQgYmUgZWF0aW5nIHVwIHRoZSBxdW90 YQ0KPj4gYmVjYXVzZSBvZiB0aGUgc3RhbGUgbWFwcGluZ3MgdGhhdCBJIG1lbnRpb25lZCBiZWxv dyByaWdodD8NCj4+PiANCj4+Pj4gSWYgd2UgbGltaXQgdGhlIHJlc291cmNlcyBvbiBwZXIgcHJl Zml4IGJhc2VzIG9uIENHTkFUL1BDUCwgdGhlbiBhcyBhDQo+Pj4+IGdlbnVpbmUgdXNlciB3aGVu IHRoZXJlIGlzIGEgY2hhbmdlIGluIEI0IGFkZHJlc3MsIEkgd2lsbCBub3QgYmUgYWJsZQ0KPj4+ PnRvDQo+Pj4+IGNyZWF0ZSBhbmQgdXNlIGFsbCBteSBxdW90YSBvZiBtYXBwaW5ncywgYXMgdGhl cmUgd291bGQgYmUgc29tZSBzdGFsZQ0KPj4+PiBtYXBwaW5ncyBjcmVhdGVkIGJlZm9yZSBteSBC NCBjaGFuZ2UgZWF0aW5nIG15IHF1b3RhLg0KPj4+IA0KPj4+IElnbm9yaW5nIFBDUCBmb3IgYSBt b21lbnQsIHRoYXQgcHJvYmxlbSBleGlzdHMgd2l0aCBpbXBsaWNpdCBtYXBwaW5ncw0KPj4+aWYN Cj4+PiB0aGUgSVNQIHJlbnVtYmVycyBob3N0cyBiZWhpbmQgdGhlIENHTi4gIEkgYWRtaXQgdGhh dCBQQ1AncyBsb25nDQo+Pj4gbGlmZXRpbWVzIGNhbiBtYWtlIHRoYXQgcHJvYmxlbSB3b3JzZS4g IE9uZSBlYXN5IHNvbHV0aW9uIGlzIHRvIHJlZHVjZQ0KPj4+IHRoZSBtYXhpbXVtIGFzc2lnbmVk IFBDUCBsaWZldGltZSBvbiB0aGUgQ0dOIHByaW9yIHRvIGFuIGFkZHJlc3MgY2hhbmdlDQo+Pj4g ZXZlbnQgLS0gbXVjaCBsaWtlIHdlIGRvIHdpdGggbG93ZXJpbmcgRE5TIFRUTCBwcmlvciB0byBj aGFuZ2luZyBETlMNCj4+PiByZWNvcmRzLiAgQnV0IHBlcmhhcHMgaXQgaXMgb3BlcmF0aW9uYWxs eSBkaWZmaWN1bHQgdG8ga25vdyB3aGVuIGFuDQo+Pj4gYWRkcmVzcyBjaGFuZ2UgaXMgZ29pbmcg dG8gb2NjdXIuICBBIHNsaWdodGx5IG1vcmUgZGlmZmljdWx0IHNvbHV0aW9uLA0KPj4+IHdoaWNo IHdvcmtzIGV2ZW4gaWYgYWRkcmVzcyBjaGFuZ2VzIGFyZW4ndCBwbGFubmVkLCBpcyB0byBzZW5k IGEgUENQDQo+Pj4gVEhJUkRfUEFSVFkgZGVsZXRlIG1lc3NhZ2UgZnJvbSB0aGUgSVNQJ3MgbWFu YWdlbWVudCBzeXN0ZW0gd2hlbiBhbg0KPj4+IGFkZHJlc3MgY2hhbmdlIG9jY3Vycy4NCj4+IFll cywgd2l0aCByZW51bWJlcmluZyB0aGlzIGlzc3VlIGFyaXNlcy4gVGhhdCBpcyB3aHkgd2UgcmVj b21tZW5kIG5vDQo+PiByZW51bWJlcmluZyByaWdodD8gSW4gdGhpcyBzY2VuYXJpbywgcHJlZml4 IHJlbnVtYmVyaW5nIGhhcyBub3QNCj4+b2NjdXJyZWQsDQo+PiBhbmQgaXQgaXMgdGhlIElQdjYg YWRkcmVzcyB0aGF0IGNoYW5nZWQgd2l0aCBpbiB0aGUgcHJlZml4LiBZZXMsIHNob3J0ZXINCj4+ IGxpZmUgdGltZSB3b3JrcywgYnV0IEkgZmVlbCB0aGF0IGFkZHMgc3lzbG9nKGNhcHR1cmluZyBt YXBwaW5ncyB0dXBsZXMpDQo+PiBvdmVyIGhlYWQuDQo+PiBXaGVuIGFkZHJlc3MvcHJlZml4IHJl bnVtYmVyaW5nIGhhcHBlbnMsIEkgYWdyZWUgYSB0aGlyZCBwYXJ0eSBkZWxldGUNCj4+bXNncw0K Pj4gb3IgYSBjbGVhciBjb21tYW5kLCBtYXkgYmUgaXNzdWVkIGJ5IGFkbWluLg0KPj4gSSBmZWVs IGl0IGlzIGFuIG92ZXIga2lsbCB0byB1c2UgdGhpcyB3aGVuIGFuIGFkZHJlc3Mgd2l0aCBpbiB0 aGUgcHJlZml4DQo+PiBjaGFuZ2VzIGFuZCBubyBzdWJzY3JpYmVyIHJlbnVtYmVyaW5nIG9mIHBy ZWZpeCBoYXBwZW5lZC4NCj4+IFRoaXMgaXMgYmVjYXVzZSB3aGVuIG1hcHBpbmdzIGFyZSBkZWxl dGVkLCB0aGVpciBhc3NvY2lhdGUgc3RhdGUgbGlrZQ0KPj4gZmxvd3MgaGF2ZSB0byBiZSBkZWxl dGVkLg0KPj4gVGhpcyBjYW4gY2F1c2UgbG90IG9mIGNodXJuIHdoZW4gZGVsZXRpb24gaGFwcGVu cyBhdCB0aGUgc2FtZSB0aW1lIGZvcg0KPj4gbXVsdGlwbGUgYWRkcmVzc2VzLg0KPj4gDQo+Pj4g DQo+Pj4+IEFuZCB0aGUgdHJhZmZpYw0KPj4+PiBkZXN0aW5lZCB0byB0aG9zZSBtYXBwaW5ncyBm cm9tIGludGVybmV0IHdvdWxkIGJlIHByb2Nlc3NlZCBieSBDR05BVA0KPj4+PmJveA0KPj4+PiBv bmx5IHRvIGJlIGRyb3BwZWQgYXQgQ1BFIQ0KPj4+IA0KPj4+IEJ1dCB0aGUgQ1BFIGRyb3BwaW5n IHRob3NlIHBhY2tldHMgaXMgbm90IGEgbmV3IG9yIHNpZ25pZmljYW50IHByb2JsZW0NCj4+PiB3 aGVuIHRoZSBJU1AgcmVudW1iZXJlZCB0aGUgc3Vic2NyaWJlci4gIFN1Y2ggZHJvcHBpbmcgb2Yg cGFja2V0cyB3b3VsZA0KPj4+IGhhcHBlbiBvbiB0b2RheSdzIElQdjQgSW50ZXJuZXQgaWYgdGhl IElTUCByZW51bWJlcmVkIHR3byBzdWJzY3JpYmVycw0KPj4+dG8NCj4+PiBzdWRkZW5seSBoYXZl IGVhY2ggb3RoZXIncyBJUCBhZGRyZXNzZXMgLS0gcGFja2V0cyB3b3VsZCBiZSByb3V0ZWQgdG8N Cj4+PnRoZQ0KPj4+IHdyb25nIGhvbWUgYW5kIGdldCBkcm9wcGVkIGJ5IE5BVHMgb3IgaG9zdC1i YXNlZCBmaXJld2FsbHMsIG9yIChpZiB0aGV5DQo+Pj4gYXJlbid0IGRyb3BwZWQpIHRoZSBwYWNr ZXRzIHdvdWxkIGJlIHByb2Nlc3NlZCBieSB0aGUgaG9zdCB0byBjb25mdXNlDQo+Pj5UQ1ANCj4+ PiBzdGFja3Mgb3IgYXBwbGljYXRpb25zLg0KPj4gTm90ZSwgSVNQIGhhcyBub3QgcmVudW1iZXJl ZCB0aGUgc3Vic2NyaWJlciB3aGlsZSBhc3NpZ25pbmcgcHJlZml4LiBJdA0KPj5pcw0KPj4gdGhl IElQdjYgYWRkcmVzcyBkZXJpdmVkIG91dCBvZiB0aGUgcHJlZml4IHRoYXQgY2hhbmdlZCBjYXVz aW5nIHRoaXMuDQo+PkFsbA0KPj4gSSBhbSBzdWdnZXN0aW5nIGlzLCBqdXN0IGxpa2Ugd2hlbiBh ZGRyZXNzIGlzIGFzc2lnbmVkLCB3aXRob3V0DQo+PiByZW51bWJlcmluZyBzdWJzY3JpYmVyLCB5 b3UgY2Fycnkgb3ZlciBtYXBwaW5ncyBhY3Jvc3MgcmVib290LiBTaW1pbGFybHkNCj4+IHdoZW4g cHJlZml4IGlzIGFzc2lnbmVkIHdpdGhvdXQgcmVudW1iZXJpbmcgc3Vic2NyaWJlciwgZXZlbiBp Zg0KPj5hZGRyZXNzZXMNCj4+IHdpdGhpbiB0aGUgcHJlZml4IGNoYW5nZSBJIGZlZWwgbWFwcGlu Z3MgY2FuIGJlIGNhcnJpZWQgYWNyb3NzIGFkZHJlc3Nlcw0KPj4gd2l0aGluIHRoZSBwcmVmaXgs IGFuZCBpbiBhZGRpdGlvbiB3ZSBoYXZlIHRvIGhhdmUgcGVyIHByZWZpeCBsaW1pdHMsIGFzDQo+ PiAic3Vic2NyaWJlciIgaXMgcmVwcmVzZW50ZWQgYnkgcHJlZml4IGFuZCBub3QgSVB2NiBhZGRy ZXNzLg0KPj4gDQo+PiBJIGZlZWwgd2hlbiB0aGVyZSBpcyBubyByZW51bWJlcmluZyBvZiBzdWJz Y3JpYmVyIHdoaWxlIGFzc2lnbmluZw0KPj5wcmVmaXgsDQo+PiBpdCBzaG91bGQgYmUgdHJlYXRl ZCB0aGUgc2FtZSBhcyB3aGVuIHRoZXJlIGlzIGFzIGFkZHJlc3MgYXNzaWdubWVudA0KPj4gd2l0 aG91dCByZW51bWJlcmluZyBvZiBzdWJzY3JpYmVyLiBUaGUgdmFsdWUgSSBzZWUgaGVyZSBpcywg aG9zdHMgYmVoaW5kDQo+PiBCNCwgY2FuIGRpcmVjdGx5IHVzZSB0aGUgbWFwcGluZ3MsIGFuZCBy ZXB1Ymxpc2hpbmcgb2YgdGhvc2UgbWFwcGluZ3MgdG8NCj4+IGV4dGVybmFsIHdvcmxkIGNhbiBi ZSBhdm9pZGVkLCBlZmZlY3RpdmUgdXRpbGl6YXRpb24gb2YgcG9ydCBsaW1pdCBxdW90YQ0KPj4g YW5kIG90aGVyIENHTkFUIHJlc291cmNlcy4gWWVzLCB3ZSBoYXZlIHRvIGRlYmF0ZSBpZiBpdCBp bnRyb2R1Y2VzIGFueQ0KPj4gaXNzdWVzLg0KPj4+IA0KPj4+IC1kDQo+Pj4gDQo+Pj4+IA0KPj4+ PiBQbGVhc2UgY29tbWVudC4NCj4+Pj4gDQo+Pj4+IFN1cmVzaA0KPj4+PiANCj4+Pj4gDQo+Pj4+ IE9uIDYvMjEvMTMgNzowOCBQTSwgIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28uY29tPiB3cm90ZToN Cj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIEp1biAyMSwgMjAxMywgYXQgNjoxNiBQTSwgIlJlaW5h bGRvIFBlbm5vIChyZXBlbm5vKSINCj4+Pj4+IDxyZXBlbm5vQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4+PiANCj4+Pj4+PiBJdCBzZWVtcyB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBwZXIgcHJlZml4IGJp bmRpbmcuIFNvLCBpbiB5b3VyDQo+Pj4+Pj5leGFtcGxlDQo+Pj4+Pj4gaWYNCj4+Pj4+PiBpbnRl cm5hbCBob3N0IDEwLjAuMC4yIHNlbmRzIGEgbmV3IE1BUCByZXF1ZXN0IHRoYXQgdXNlcyAzMDAx OmIgYXMNCj4+Pj4+PiBzb3VyY2UNCj4+Pj4+PiBhZGRyZXNzLCB0aGUgQUZUUiBzaG91bGQgdXBk YXRlIGFueSBleGlzdGluZyBtYXBwaW5ncyB0byB1c2UgdGhpcw0KPj4+Pj4+bmV3DQo+Pj4+Pj4g c291cmNlIElQdjYgdG8gcmVhY2ggdGhlIEI0IHdoaWxlIGV4dGVybmFsIHB1YmxpYyBJUDpwb3J0 IHdvdWxkIGJlDQo+Pj4+Pj50aGUNCj4+Pj4+PiBzYW1lLiBUaGVyZWZvcmUgbm8gbmVlZCB0byB1 cGRhdGUgZHluRE5TIG9yIG90aGVyIHN0dWZmLg0KPj4+Pj4+IA0KPj4+Pj4+IElmIG15IHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdCB0aGlzIGlzIGludGVyZXN0aW5nLg0KPj4+Pj4gDQo+Pj4+PiBU aGFua3MgZm9yIHN1bW1hcml6aW5nIC0gSSB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbCBub3cuICBJ dCBzZWVtcyB0bw0KPj4+Pj4gcmVxdWlyZSB0aGUgQjQgYW5kIHRoZSBBRlRSIGtub3cgdGhhdCB0 aGUgc2FtZSBJUHY0IG1hcHBpbmcgaXMNCj4+Pj4+IGF2YWlsYWJsZQ0KPj4+Pj4gYWZ0ZXIgSVB2 NiByZW51bWJlcmluZyAtLSBzcGVjaWZpY2FsbHkgdGhhdCB0aGUgc2FtZSBBRlRSIGlzIGJlaW5n DQo+Pj4+PnVzZWQNCj4+Pj4+IGFuZCBpdCB3aWxsIGFzc2lnbiB0aGUgc2FtZSBJUHY0IGFkZHJl c3MgdG8gdGhlIEI0LiAgU2VlbXMgYSBsb3Qgb2YNCj4+Pj4+IGNvb3JkaW5hdGlvbiBiZXR3ZWVu IHRoZSBCNCBhbmQgQUZUUiB0byBhdm9pZCB1cGRhdGluZyBhIHJlbmRlenZvdXMNCj4+Pj4+IHNl cnZlci4gIEhvd2V2ZXIsIHRoZSBob3N0IChhbmQgdGhlIEI0KSB3aWxsIGFsd2F5cyBuZWVkIHRv IGJlIGFibGUNCj4+Pj4+dG8NCj4+Pj4+IGhhbmRsZSBuZXR3b3JrIHJlbnVtYmVyaW5nIHdoZXJl IHRoZSBzYW1lIElQdjQgbWFwcGluZyBpcyBub3QNCj4+Pj4+IGF2YWlsYWJsZSwNCj4+Pj4+IHNv IHRoaXMgaW5jcmVhc2VzIGltcGxlbWVudGF0aW9uIGFuZCB0ZXN0aW5nIGVmZm9ydC4gIFRoZSBn YWluLCBpbiBteQ0KPj4+Pj4gbWluZCwgaXMgcHJldHR5IHNtYWxsIGVzcGVjaWFsbHkgY29uc2lk ZXJpbmcgdGhlIElQIHJlbnVtYmVyaW5nIGhhcw0KPj4+Pj50bw0KPj4+Pj4gYmUNCj4+Pj4+IGlu ZnJlcXVlbnQgKG9yIGVsc2UgVENQIHNlc3Npb25zIGFyZSBkaXNydXB0ZWQsIG5vYm9keSBtdWNo DQo+Pj4+PmFwcHJlY2lhdGVzDQo+Pj4+PiB0aGF0KS4NCj4+Pj4+IA0KPj4+Pj4gLWQNCj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gNi8yMS8xMyA5OjM3IFBNLCAiU3VyZXNoIEt1 bWFyIFZpbmFwYW11bGEgVmVua2F0YSINCj4+Pj4+PiA8c3VyZXNoa0BqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IEhpIE1vaGFtZWQvRGFuLA0KPj4+Pj4+PiANCj4+Pj4+Pj4g VGhhbmtzIGZvciBwb2ludGluZyB0byB0aGUgZHJhZnRzLg0KPj4+Pj4+PiBJIHVuZGVyc3RhbmQg ZnJvbSB0aGUgZHJhZnRzIHRoYXQgaWYgYSBDUEUgaXMgYXNzaWduZWQgYSBzYW1lIElQDQo+Pj4+ Pj4+IGFkZHJlc3MNCj4+Pj4+Pj4gYWZ0ZXIgcmVib290LCBpbiBjYXNlIG9mIERTLUxpdGUsIFBD UCBwcm94eSBzaG91bGQgc2VuZCBBTk5PVU5DRQ0KPj4+Pj4+PiByZXF1ZXN0DQo+Pj4+Pj4+IHRv IHRoZSBQQ1AgY2xpZW50cy4NCj4+Pj4+Pj4gVGhpcyB3YXksIFBDUCBjbGllbnRzIHdvdWxkIHJl ZnJlc2ggdGhlaXIgbWFwcGluZ3MuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBTdXBwb3NlIHByZWZpeCBz YXkgMzAwMTo6LzU2IGlzIGFzc2lnbmVkIHRvIENQRSBhZnRlciByZWJvb3QgYW5kIGlzDQo+Pj4+ Pj4+IHNhbWUNCj4+Pj4+Pj4gYXMgYmVmb3JlIHJlYm9vdC4NCj4+Pj4+Pj4gU3VwcG9zZSBJUHY2 IGFkZHJlc3MgYmVmb3JlIHJlYm9vdCBpcyAzMDAxOjphIGFuZCBjcmVhdGVkIHNvbWUNCj4+Pj4+ Pj4gbWFwcGluZ3MuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBIb3dldmVyLCBhZnRlciBhIHJlYm9vdCwg YSBuZXcgSVB2NiBhZGRyZXNzIG1heSBiZSB0YWtlbiBhcyBCNCBzYXkNCj4+Pj4+Pj4gMzAwMTo6 Yi4gDQo+Pj4+Pj4+IEFzIHBlciB0aGUgY3VycmVudCBkcmFmdHMsIGNsaWVudHMgd2lsbCB0cnkg dG8gcmVmcmVzaCBtYXBwaW5ncw0KPj4+Pj4+PndpdGgNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+IG5l d2x5IGFzc2lnbmVkIElQdjYgYWRkcmVzcyBhcyB0aGUgQjQgYWRkcmVzcy4NCj4+Pj4+Pj4gU2lu Y2UgdGhlIHJlcXVlc3RzIGFyZSBmcm9tIHRoZSBkaWZmZXJlbnQgSVB2NiBhZGRyZXNzLCBDR05B VCB3aWxsDQo+Pj4+Pj4+IHRyeQ0KPj4+Pj4+PiB0bw0KPj4+Pj4+PiBjcmVhdGUgbmV3IG1hcHBp bmdzIGFuZCB0aGUgb2xkIG1hcHBpbmdzIGhhdmUgdG8gYWdlIG91dC4NCj4+Pj4+Pj4gTm93IGhv c3RzIHVzaW5nIHRoZXNlIG1hcHBpbmdzIGhhdmUgdG8gcHVibGlzaCB0aGVzZSBtYXBwaW5ncywg Zm9yDQo+Pj4+Pj4+IGV4dGVybmFsIGhvc3RzIHRvIGNvbm5lY3QgcmlnaHQ/IFRoaXMgaXMgYW4g b3ZlcmhlYWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBNeSBwb2ludCBpcywgdGhpcyBvdmVyIGhlYWQg Y2FuIGJlIGVsaW1pbmF0ZWQgd2hlbiB0aGVyZSBpcyBhDQo+Pj4+Pj4+Y2hhbmdlDQo+Pj4+Pj4+ IGluDQo+Pj4+Pj4+IGFkZHJlc3MgaW4gdGhlIHByZWZpeCwgd2h5IGRvIHdlIG5lZWQgdG8gZm9y Y2UgY3JlYXRpb24gb2YgbmV3DQo+Pj4+Pj4+IG1hcHBpbmdzDQo+Pj4+Pj4+IGFuZCB0aW1lb3V0 IG9mIG9sZCBtYXBwaW5ncz8NCj4+Pj4+Pj4gSW5zdGVhZCwgY2FuIHRoZSBtYXBwaW5ncyBhbmQg dGhlIGNvcnJlc3BvbmRpbmcgdHJhZmZpYyBiZSBtaWdyYXRlZA0KPj4+Pj4+PiB0bw0KPj4+Pj4+ PiBuZXdlciBCND8gDQo+Pj4+Pj4+IElmIHRoZSBzYW1lIGFkZHJlc3MgaXMgYWNxdWlyZWQgYnkg dGhlIEI0IGFmdGVyIHJlYm9vdCwgQ0dOQVQgYm94DQo+Pj4+Pj4+IGRvZXNuJ3QNCj4+Pj4+Pj4g ZGlmZmVyZW50aWF0ZSByaWdodD8gSSBhbSBzdWdnZXN0aW5nIGNhbiB0aGlzIGJlIGV4dGVuZGVk IHRvDQo+Pj4+Pj4+cHJlZml4LA0KPj4+Pj4+PiBzdWNoDQo+Pj4+Pj4+IHRoYXQgYW55IG1hcHBp bmdzIGNyZWF0ZWQgb3ZlciBvbmUgQjQgYWRkcmVzcyBvZiB0aGUgcHJlZml4IGJlDQo+Pj4+Pj4+ IG1pZ3JhdGVkIHRvDQo+Pj4+Pj4+IGFub3RoZXIgQjQgYWRkcmVzcyB3aXRoaW4gdGhlIHNhbWUg cHJlZml4Pw0KPj4+Pj4+PiANCj4+Pj4+Pj4gSWYgdGhlcmUgaXMgYSBjaGFuZ2UgaW4gcHJlZml4 LCB0aGVyZSBpcyBubyBvcHRpb24gdG8gbWlncmF0ZSBhcw0KPj4+Pj4+PiBtZW50aW9uZWQsIG5l dyBtYXBwaW5ncyBoYXZlIHRvIGJlIGNyZWF0ZWQgYW5kIG9sZCBtYXBwaW5ncyBoYXZlIHRvDQo+ Pj4+Pj4+IGV4cGlyZS4gDQo+Pj4+Pj4+IEFkZHJlc3MgY2hhbmdlIHdpdGggaW4gYSBwcmVmaXgg Y2FuIGJlIGhhbmRsZWQgbW9yZSBncmFjZWZ1bGx5DQo+Pj4+Pj4+cmlnaHQ/DQo+Pj4+Pj4+IEFt IEkNCj4+Pj4+Pj4gbWlzc2luZyBzb21ldGhpbmc/DQo+Pj4+Pj4+IA0KPj4+Pj4+PiAtU3VyZXNo DQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIDYvMjEvMTMgMzo1NSBQ TSwgIkRhbiBXaW5nIiA8ZHdpbmdAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IE9uIEp1biAyMSwgMjAxMywgYXQgMjowMiBBTSwgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhpIFN1cmVzaCwNCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJZiBhIG5ldyBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIHRoZSBC NCwgdGhlIGNvLWxvY2F0ZWQgUENQIGNsaWVudA0KPj4+Pj4+Pj4+IHdpbGwNCj4+Pj4+Pj4+PiBu ZWVkIHRvIHJlLWluc3RhbGwgdGhlIG1hcHBpbmdzIGl0IG1hbmFnZXMuDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IFdoZW4gYSBuZXcgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byB0aGUgQjQsIHRoZSBCNCdz IFBDUCBzZXJ2ZXINCj4+Pj4+Pj4+c2hvdWxkDQo+Pj4+Pj4+PiBmb2xsb3cgdGhlIHByb2NlZHVy ZXMgaW4gIkFkZHJlc3MgQ2hhbmdlIEV2ZW50cyIsDQo+Pj4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2ODg3I3NlY3Rpb24tMTEuNS4gIFRoZSBob3N0IHdoaWNoDQo+Pj4+Pj4+ PiBjcmVhdGVkDQo+Pj4+Pj4+PiB0aGUgbWFwcGluZ3MgKHRoZSBQQ1AgY2xpZW50KSBuZWVkcyB0 byBiZSBhd2FyZSBvZiB0aGUgYWRkcmVzcw0KPj4+Pj4+Pj4gY2hhbmdlDQo+Pj4+Pj4+PiB0bw0K Pj4+Pj4+Pj4gdXBkYXRlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVuZGV6dm91cyBzZXJ2ZXIg KEROUywgU0lQLCBYTVBQLA0KPj4+Pj4+Pj4gd2hhdGV2ZXIpLCB3aGljaCBtZWFucyB0aGUgQjQn cyBQQ1Agc2VydmVyIGlzbid0IGhlbHBpbmcgdGhpbmdzIGJ5DQo+Pj4+Pj4+PiB1cGRhdGluZyBt YXBwaW5ncyBvbiB0aGUgQ0dOIGJ5IGl0c2VsZi4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLWQNCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhpcyB3aWxsIGJlIHNlZW4gYnkgdGhlIFBD UCBzZXJ2ZXIgYXMgbmV3IHJlcXVlc3RzIGlmIHRoZSBQQ1ANCj4+Pj4+Pj4+PiBDbGllbnQNCj4+ Pj4+Pj4+PiBJUCBBZGRyZXNzIGlzIG5vdCBhbHJlYWR5IGluIHVzZSBpbiB0YWJsZSBvciByZWZy ZXNoIG1hcHBpbmdzDQo+Pj4+Pj4+Pj4gb3RoZXJ3aXNlLg0KPj4+Pj4+Pj4+IEluIGJvdGggY2Fz ZXMsIHRoZXJlIGlzIGEgZmFpbHVyZSByaXNrIGR1ZSB0byB0aGUgcHJlc2VuY2Ugb2YNCj4+Pj4+ Pj4+PnN0YWxlDQo+Pj4+Pj4+Pj4gbWFwcGluZ3MuIFlvdSBjYW4gY2hlY2s6DQo+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i b3VjYWRhaXItcGNwLWZhaWx1cmUtMDYjc2VjdGlvbi0NCj4+Pj4+Pj4+PjIuDQo+Pj4+Pj4+Pj4g NA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+PiBNZWQNCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiBEZSA6IFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGEgW21haWx0 bzpzdXJlc2hrQGp1bmlwZXIubmV0XQ0KPj4+Pj4+Pj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWlu IDIwMTMgMTc6MDYNCj4+Pj4+Pj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xODQo+ Pj4+Pj4+Pj4gQ2MgOiBwY3BAaWV0Zi5vcmc7IG1yd0BwYWlubGVzcy1zZWN1cml0eS5jb207IGZk dXBvbnRAaXNjLm9yZw0KPj4+Pj4+Pj4+IE9iamV0IDogUmU6IENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtcGNwLWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlDQo+Pj4+Pj4+Pj4gSGFuZGxpbmcpDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSGkgTW9oYW1tZWQNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBQbGVh c2UgY29ycmVjdCBtZSBpZiBJIGFtIG1pc3Npbmcgc29tZSB0aGluZy4gSG93IGNhbiBDR05BVCBr bm93LA0KPj4+Pj4+Pj4+IHdoZXRoZXIgdGhlIHJlcXVlc3QgaXMgdG8gcmVmcmVzaCBleGlzdGlu ZyBtYXBwaW5ncyBvciBmb3IgbmV3DQo+Pj4+Pj4+Pj4gbWFwcGluZ3MNCj4+Pj4+Pj4+PiB3aGVu IHRoZSBDUEUgYWRkcmVzcyBjaGFuZ2VkPw0KPj4+Pj4+Pj4+IEFkZHJlc3NlcyBiZWhpbmQgQjQg Y2FuIG92ZXJsYXAgcmlnaHQ/IFRoZXkgaGF2ZSB0byByZWx5IG9uIEI0DQo+Pj4+Pj4+Pj4gYWRk cmVzcw0KPj4+Pj4+Pj4+IHJpZ2h0Pw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFN1cmVzaA0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIEp1biAyMCwgMjAxMywgYXQgNjoyNSBBTSwgIm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iDQo+Pj4+Pj4+Pj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IERlYXIgU3VyZXNoLA0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IEZXSVcsIHlvdSBtYXkgZmluZCBzb21lIHRleHQgZGVzY3JpYmluZyB0 aGlzIGZhaWx1cmUgY2FzZQ0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+YXQ6aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXBjcC1m YWlsdXJlLTA2I3NlY3RpDQo+Pj4+Pj4+Pj5vbg0KPj4+Pj4+Pj4+IC0yDQo+Pj4+Pj4+Pj4gLjUN Cj4+Pj4+Pj4+PiAuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+IE1l ZA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IERlIDogcGNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwY3AtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGENCj4+Pj4+Pj4+PnBhcnQNCj4+Pj4+Pj4+PiBk ZQ0KPj4+Pj4+Pj4+IFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGENCj4+Pj4+Pj4+PiBF bnZvecOpIDogamV1ZGkgMjAganVpbiAyMDEzIDAyOjAwDQo+Pj4+Pj4+Pj4gw4AgOiBwY3BAaWV0 Zi5vcmcNCj4+Pj4+Pj4+PiBDYyA6IG1yd0BwYWlubGVzcy1zZWN1cml0eS5jb207IGZkdXBvbnRA aXNjLm9yZw0KPj4+Pj4+Pj4+IE9iamV0IDogW3BjcF0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1w Y3AtZHNsaXRlLTAwLiAoUENQIERTLUxpdGUNCj4+Pj4+Pj4+PiBIYW5kbGluZykNCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBIaSwgDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQW4g ZXh0ZXJuYWwgSVAgYWRkcmVzcyBvZiB0aGUgQ1BFIGRldmljZSBtYXkgY2hhbmdlIGFzIGFuZCB3 aGVuDQo+Pj4+Pj4+Pj4gREhDUA0KPj4+Pj4+Pj4+IGxlYXNlIGV4cGlyZXMgb3Igd2hlbiB0aGVy ZSBpcyBhIHJlYm9vdCBvZiBDUEUgZm9yIGFueSByZWFzb24uDQo+Pj4+Pj4+Pj4gVHJhZmZpYyBk ZXN0aW5lZCBmcm9tIGV4dGVybmFsIHdvcmxkLCB0byB0aGVzZSBtYXBwaW5ncywgbWF5IG5vdA0K Pj4+Pj4+Pj4+IHJlYWNoDQo+Pj4+Pj4+Pj4gaW50ZW5kZWQgQ1BFLCBhcyB0aGVyZSBpcyBjaGFu Z2UgaW4gZXh0ZXJuYWwgYWRkcmVzcy4NCj4+Pj4+Pj4+PiBSRkMgNjg4NyByZWNvbW1lbmRzIG5v IGhvc3QgcmVudW1iZXJpbmcgdG8gaGFuZGxlIGl0Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhv d2V2ZXIgdGhpcyBpcyBub3Qgc3VmZmljaWVudCBpbiB2NiBlbnZpcm9ubWVudCBlc3BlY2lhbGx5 IHdpdGgNCj4+Pj4+Pj4+PiBEUy1MaXRlLCB3aGVyZSBhIENQRSBpcyBhc3NpZ25lZCBhIHY2cHJl Zml4IGFuZCBpcyBmcmVlIHRvIHVzZQ0KPj4+Pj4+Pj4+YW55DQo+Pj4+Pj4+Pj4gYWRkcmVzcyB3 aXRoIGluIHRoZSBwcmVmaXguIFRob3VnaCBESFBDdjYgbWF5IGFzc2lnbiBzYW1lIHByZWZpeA0K Pj4+Pj4+Pj4+IHRvIGENCj4+Pj4+Pj4+PiBDUEUsIHRoZSBob3N0IHBvcnRpb24gaXMgdHlwaWNh bGx5IGZpbGxlZCBieSBDUEUgYW5kIHR5cGljYWxseQ0KPj4+Pj4+Pj4+d2l0aA0KPj4+Pj4+Pj4+ IG1hYw0KPj4+Pj4+Pj4+IGFkZHJlc3MsIHdoaWNoIGNoYW5nZXMgd2hlbiB0aGVyZSBpcyBhIGNo YW5nZSBpbiBDUEUgZGV2aWNlIG9yDQo+Pj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+PiBzb21lDQo+Pj4+ Pj4+Pj4gcmVhc29uLiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBTaW5jZSB0aGUgZW5kIHN5c3Rl bXMgKEhvc3RzIGJlaGluZCBDUEUvQjQsIGFuZCB0aGUgQ0dOIGJveCkgaGFzDQo+Pj4+Pj4+Pj4g bm90DQo+Pj4+Pj4+Pj4gcmVib290ZWQsIHRoZSBtYXBwaW5ncyB0aGF0IHdlcmUgY3JlYXRlZCBi ZWZvcmUgYW5kIHRoZSB0cmFmZmljDQo+Pj4+Pj4+Pj4gZGVzdGluZWQNCj4+Pj4+Pj4+PiB0byB0 aG9zZSBtYXBwaW5ncyBpZiB0dW5uZWxlZCBvdmVyIHRvIG9sZCBCNCBhZGRyZXNzIHdvdWxkIGJl DQo+Pj4+Pj4+Pj4gZHJvcHBlZCBieQ0KPj4+Pj4+Pj4+IHRoZSBDUEUgZGV2aWNlLg0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IFRoaXMgYWxzbyBjYXVzZXMgb3RoZXIgaW5jb252ZW5pZW5jZSBhcyB0 aGVzZSBtYXBwaW5ncyBoYW5ncw0KPj4+Pj4+Pj4+YXJvdW5kDQo+Pj4+Pj4+Pj4gdGlsbCB0aGV5 IHRpbWVvdXQoc2NhbGluZyBpbXBhY3QgYW5kIG5vbiB1c2FnZSBvZiBwb3J0cyBhbmQNCj4+Pj4+ Pj4+Pm1lbW9yeSkNCj4+Pj4+Pj4+PiBvciwNCj4+Pj4+Pj4+PiB1bmxlc3MsIGEgcGFja2V0IGZh a2VkIHdpdGggdGhlIG9sZCBCNCBhZGRyZXNzIGFzIHNvdXJjZSBhbmQgYQ0KPj4+Pj4+Pj4+IGRl bGV0ZQ0KPj4+Pj4+Pj4+IHJlcXVlc3QgaXMgaXNzdWVkLiBFdmVuIGlmIHRob3NlIG1hcHBpbmdz IGFyZSBkZWxldGVkICBpbg0KPj4+Pj4+Pj4+c29tZXdheSwNCj4+Pj4+Pj4+PiBhDQo+Pj4+Pj4+ Pj4gbmV3DQo+Pj4+Pj4+Pj4gc2V0IG9mIG1hcHBpbmdzIGhhdmUgdG8gYmUgY3JlYXRlZCBhbmQg cHVibGlzaGVkIGZvciBleHRlcm5hbA0KPj4+Pj4+Pj4+d29ybGQNCj4+Pj4+Pj4+PiB0bw0KPj4+ Pj4+Pj4+IGNvbm5lY3QsIGV2ZXJ5IHRpbWUsIHdoZW4gc3VjaCBhbiBldmVudCBoYXBwZW5zLg0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoaXMgaXMgYSBzY2VuYXJpbywgd2hlcmUgZW5kIHN5c3Rl bXMoaG9zdHMgYmVoaW5kIEI0IGFuZCBDR05BVA0KPj4+Pj4+Pj4+IGRldmljZSkNCj4+Pj4+Pj4+ PiBhcmUgbm90IHJlYm9vdGVkLCBidXQgaW50ZXJtZWRpYXRlIENQRSBkZXZpY2UgaXMgcmVib290 ZWQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gU2luY2UgdGhlIGVuZCBzeXN0ZW1zIGFyZSBub3Qg cmVib290ZWQsIGNhbiB0aG9zZSBtYXBwaW5ncyBiZQ0KPj4+Pj4+Pj4+IG1pZ3JhdGVkDQo+Pj4+ Pj4+Pj4gb3ZlciBEUy1MaXRlIHR1bm5lbHM/DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhlcmUg YXJlIHR3byBvcHRpb25zIGhlcmUsIHRvIHJldXNlIHRoZXNlIG1hcHBpbmdzLg0KPj4+Pj4+Pj4+ IAnigqwgVGhlIG9wdGlvbiBpcywgY3JlYXRlIG1hcHBpbmdzIGFuZCBmbG93cyBvbiBwZXIgcHJl Zml4LiBUaGlzDQo+Pj4+Pj4+Pj53YXkNCj4+Pj4+Pj4+PiBtYXBwaW5ncyBhbmQgZmxvd3MgYXJl IG1pZ3JhdGVkIHRvIGFueSBhZGRyZXNzIGluIHRoZSBzYW1lIHByZWZpeA0KPj4+Pj4+Pj4+IHdo ZW4NCj4+Pj4+Pj4+PiBldmVyIHRoZXJlIGlzIGNoYW5nZSBpbiBhZGRyZXNzLiBUaGUgZGVzdGlu YXRpb24gYWRkcmVzcyB0byBiZQ0KPj4+Pj4+Pj4+dXNlZA0KPj4+Pj4+Pj4+IGJ5DQo+Pj4+Pj4+ Pj4gdGhlIENHTkFUIGJveCwgdG8gdHVubmVsIHBhY2tldHMgb3ZlciB0aG9zZSBtYXBwaW5ncyB0 byB0aGUgQ1BFDQo+Pj4+Pj4+Pj4gc2hvdWxkDQo+Pj4+Pj4+Pj4gYmUgdGhlIGFkZHJlc3MgbGFz dCBzZWVuIGJ5IHRoZSBDR05BVCBmcm9tIHRoZSBDUEUgb2YgdGhlIHByZWZpeC4NCj4+Pj4+Pj4+ PiBUaGlzDQo+Pj4+Pj4+Pj4gd2F5LCB0cmFmZmljIG92ZXIgbWFwcGluZ3MgYW5kIGZsb3dzIGNy ZWF0ZWQgb3ZlciBvbGQgQjQgYWRkcmVzcywNCj4+Pj4+Pj4+PiBjYW4NCj4+Pj4+Pj4+PiBjb250 aW51ZSB0byByZWFjaCBpbnRlbmRlZCBob3N0IG92ZXIgdGhlIG5ldyBEUy1MaXRlIHR1bm5lbC4N Cj4+Pj4+Pj4+PiAJ4oKsIENQRSB0byBhY2NlcHQgcGFja2V0cyBkZXN0aW5lZCB0byBhbnkgYWRk cmVzcyBpbiB0aGF0IHByZWZpeC4NCj4+Pj4+Pj4+PiBUaGlzDQo+Pj4+Pj4+Pj4gbWF5IGJlIGEg Z2VuZXJpYyBzdGFjayBjaGFuZ2UgYW5kIG1heSBub3QgYmUgZGVzaXJhYmxlLg0KPj4+Pj4+Pj4+ IFRoaXMgaXMgbm90IGNvdmVyZWQgaW4NCj4+Pj4+Pj4+PiBodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4gQ2FuDQo+Pj4+Pj4+Pj50aGlzDQo+ Pj4+Pj4+Pj4gYmUNCj4+Pj4+Pj4+PiBpbmNsdWRlZCBmb3IgdGhlIGRpc2N1c3Npb24/DQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gUGxlYXNlIGNvbW1lbnQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g LVN1cmVzaA0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+Pj4gcGNwIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IHBjcEBpZXRm Lm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNw DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4+IHBjcCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gcGNwQGlldGYub3JnDQo+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo+Pj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+ DQo+DQo+DQoNCg== From repenno@cisco.com Mon Jun 24 11:37:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDED21F9A00 for ; Mon, 24 Jun 2013 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.549 X-Spam-Level: X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWUGe2Etfd0v for ; Mon, 24 Jun 2013 11:37:05 -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 0CD3C21F99BC for ; Mon, 24 Jun 2013 11:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27140; q=dns/txt; s=iport; t=1372099025; x=1373308625; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pJUT+Lc+MYmjmZQsCoCVG9rw0DlTPO9NV27ar8/2C5w=; b=Hw9NV5eg2GzoBhZAdduGVVwt9b3U5JZWzsCF9BzhIH/OiqBq/bVW5VOG c9fM3H5EFTXop8502ZigA8uRLFK9URZVJiUMat9n28YQG4nvUMdMInnHH Gn4dLxTwkP7c8FkSJQTy6PADAtm8k8v4XmaGjAYK5hkXcjCYWQpj76O30 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEKQyFGtJXHB/2dsb2JhbABbgwkxSYMFvD4NehZ0giMBAQEEAQEBIBEzBQIIAxIBCBgCAgYdAwIEJQsUARACBAENBQgRAodzDKk8kTqBJoxlDQd/MQeCTzNhA5hskBuDEIFoAQEFGQYa X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="226776236" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jun 2013 18:37:04 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5OIb4R2020971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 18:37:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 13:37:03 -0500 From: "Reinaldo Penno (repenno)" To: Suresh Kumar Vinapamula Venkata , "Dan Wing (dwing)" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObuC65vAiBS138kWSwhBqkqKfOJlBEBEAgABA04CAACgigIAACY6AgAAxDACAA7FqAIAAGasA///YsYA= Date: Mon, 24 Jun 2013 18:37:03 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090B93F3@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.245.241] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 24 Jun 2013 18:37:10 -0000 DQoNCk9uIDYvMjQvMTMgMjo1NyBQTSwgIlN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGEi DQo8c3VyZXNoa0BqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4NCj4NCj5PbiA2LzI0LzEzIDk6MjUg QU0sICJEYW4gV2luZyIgPGR3aW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+Pg0KPj5PbiBKdW4g MjIsIDIwMTMsIGF0IDE6MDIgQU0sIFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGENCj4+ PHN1cmVzaGtAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4NCj4+PiANCj4+PiANCj4+PiBPbiA2LzIx LzEzIDEwOjA2IFBNLCAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5jb20+IHdyb3RlOg0KPj4+IA0K Pj4+PiANCj4+Pj4gT24gSnVuIDIxLCAyMDEzLCBhdCA5OjMyIFBNLCBTdXJlc2ggS3VtYXIgVmlu YXBhbXVsYSBWZW5rYXRhDQo+Pj4+IDxzdXJlc2hrQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4g DQo+Pj4+PiBZZXMgUmVpbmFsZG8sIHRoYXQgaXMgY29ycmVjdC4NCj4+Pj4+IA0KPj4+Pj4gRGFu LCANCj4+Pj4+IA0KPj4+Pj4gTm90ZSwgaXQgaXMgdGhlIENQRSB0aGF0IHJlYm9vdGVkIG9yIHdl bnQgYmFkIGFuZCBzbyBjaGFuZ2VkLg0KPj4+Pj4gRW5kIHN5c3RlbXMgYXJlIG5vdCByZWJvb3Rl ZC4NCj4+Pj4+IA0KPj4+Pj4gV2l0aCBubyByZW51bWJlcmluZyBDUEUgaXMgYXNzaWduZWQgc2Ft ZSB2NiBwcmVmaXggMzAwMTo6Lg0KPj4+Pj4gRGVwZW5kaW5nIG9uIHRoZSBhbGdvcml0aG0gdG8g ZmlsbCBpbiB0aGUgaG9zdCBwb3J0aW9uIGZvcm1pbmcgYSBCNA0KPj4+Pj4gcHJlZml4LCBhIG5l dyBCNCBhZGRyZXNzIDMwMDE6OmIgY2FuIGJlIHBpY2tlZCB3aGljaCBpcyBkaWZmZXJlbnQNCj4+ Pj4+ZnJvbQ0KPj4+Pj4gb2xkDQo+Pj4+PiBCNCBhZGRyZXNzIDMwMDE6OmEuDQo+Pj4+PiANCj4+ Pj4+IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyAxMC4wLjAuMiBoYXZlbid0IHJlYm9vdGVkLCB0aGV5 IHNob3VsZCBiZSBhYmxlDQo+Pj4+PnRvDQo+Pj4+PiBjb250aW51ZSB1c2luZyB0aG9zZSBtYXBw aW5ncy4gV2hlbiBob3N0cyBiZWhpbmQgQjQgc2VlcyBBTk5PVU5DRSwNCj4+Pj4+YW5kDQo+Pj4+ PiBzZW5kcyByZWZyZXNoIHJlcXVlc3RzLCBpdCB3b3VsZCBub3QgcmVzdWx0IGluIGNyZWF0aW5n IGEgbmV3IG1hcHBpbmcNCj4+Pj4+IGJ1dA0KPj4+Pj4gdXNlIGV4aXN0aW5nIG1hcHBpbmcuIFRo ZSBiZW5lZml0LCBob3N0cyBiZWhpbmQgQjQgZG9uJ3QgbmVlZCB0bw0KPj4+Pj5wdWJsaXNoDQo+ Pj4+PiB0byBleHRlcm5hbCB3b3JsZCBhYm91dCB0aGUgY2hhbmdlLCB0byByZWNlaXZlIHRyYWZm aWMgZnJvbSBleHRlcm5hbA0KPj4+Pj4gd29ybGQuDQo+Pj4+IA0KPj4+PiBXaGF0IGFyZSB0aGUg c2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIDMwMDE6OmIgdGFraW5nIG92ZXIgMzAwMTo6YSdzDQo+ Pj4+IG1hcHBpbmdzPyAgSXMgdGhlcmUgYSB3YXkgdG8gZW5zdXJlIHRoYXQgZG9lc24ndCBoYXBw ZW4gbWFsaWNpb3VzbHk/DQo+Pj4gDQo+Pj4gU2luY2UgU2luY2UgdGhleSBhcmUgZnJvbSB0aGUg c2FtZSBwcmVmaXgsIGFuZCB0aGUgcHJlZml4IGxlbg0KPj4+IGNvbmZpZ3VyYXRpb24gaXMgdW5k ZXIgYWRtaW4gY29udHJvbCwgSSBhbSBub3QgdGhpbmtpbmcgb2YgYW55IF9uZXdfDQo+Pj4gbWFs aWNpb3VzIGF0dGFja3MuDQo+Pg0KPj5Ob3RoaW5nIGNvbWVzIGltbWVkaWF0ZWx5IHRvIG1pbmQu ICBXaGVuIHRoZSBkZXRhaWxzIGFyZSB3cml0dGVuIGRvd24gaXQNCj4+d2lsbCBiZWFyIGNhcmVm dWwgY29uc2lkZXJhdGlvbi4NCj5JIGFncmVlLiBJIHRob3VnaHQgYWJvdXQgaXQgYW5kIGNvdWxk IG5vdCBjb21lIHVwIHdpdGggYW55IF9uZXdfIG1hbGljaW91cw0KPmF0dGFja3MsIEkgdGhpbmsg bW9yZS4NCj4+DQo+Pg0KPj5TZXBhcmF0ZSBmcm9tIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgSSBy ZW1haW4gc2tlcHRpY2FsIG9mIGhvdyBvZnRlbiBhIEI0DQo+PmVsZW1lbnQgd291bGQgZm9yZ2V0 IGl0cyBwcmV2aW91cyBJUHY2IGFkZHJlc3Mgb3IgdGhlIG5ldHdvcmsgd291bGQNCj4+cmVmdXNl IHRvIGdpdmUgaXRzIG9sZCBhZGRyZXNzIGJhY2ssIHlldCB0aGUgQjQgaXMgc3RpbGwgYWJsZSB0 byByZW1lbWJlcg0KPj5tYXBwaW5ncyAodG8gcmUtdmFsaWRhdGUgdGhlIG1hcHBpbmdzIHdpdGgg dGhlIEFGVFIpLg0KPkl0IGlzIG5vdCBmb3IgQjQsIHRoZXNlIG1hcHBpbmdzIGFyZSBjcmVhdGVk LiBJdCBpcyBmb3IgdGhlIGhvc3RzIGJlaGluZA0KPkI0IHRoYXQgdGhlc2UgbWFwcGluZ3MgYXJl IGNyZWF0ZWQuIERvZXMgQjQgbmVlZCB0byBiZSBzdGF0ZWZ1bCBmb3IgdGhlc2UNCj5tYXBwaW5n cz8NCg0KSSB3YXMgYXNzdW1pbmcgUENQIFByb3h5IGRvZXMgbm90IG5lZWQgdG8ga2VlcCBhbnkg c3RhdGUgYXJvdW5kLiBUaGF0J3MNCndoeSAoYXBhcnQgZnJvbSBEYW4ncyBjb25jZXJucykgdGhl IHNjZW5hcmlvIHdhcyB2ZXJ5IGNyaXNwIGluIG15IG1pbmQuDQoNCg0KPg0KPldoZW4gZXZlciBw cm94eS9CNCByZWJvb3RzIG9yIGNoYW5nZWQsIGl0IGlzIHN1cHBvc2VkIHRvIGJyb2FkY2FzdCBh bg0KPkFOTk9VTkNFIGluIGl0cyBuZXR3b3JrLCBmb3IgdGhlIGhvc3RzIGJlaGluZCBpdCB0byBy ZWZyZXNoIHRoZWlyDQo+bWFwcGluZ3MuIFRoaXMgaXMgc3VnZ2VzdGVkIGluIG11bHRpcGxlIGRy YWZ0cy4NCj5BbGwgSSBhbSB0cnlpbmcgc3VnZ2VzdCBpcyB0byBleHRlbmQgdGhpcyB0byBwcmVm aXggbGV2ZWwsIHdoZXJlIGEgcHJlZml4DQo+aXMgYXNzaWduZWQgdG8gQ1BFLiBIb3N0cyBiZWhp bmQgQjQgb24gc2VlaW5nIEFOTk9VTkNFLCBpbml0aWF0ZSBtYXBwaW5nDQo+cmVmcmVzaCByZXF1 ZXN0cywgQ0dOQVQgd2hlbiB0cmFja2VkIG1hcHBpbmdzIGF0IHByZWZpeCBsZXZlbCwgd291bGQg YmUNCj5hYmxlIHRvIG1pZ3JhdGUgdGhlc2UgbWFwcGluZ3MgZXZlbiB0byBuZXdlciBCNC4gVGhp cyB3aWxsIGNvbnNlcnZlDQo+cmVzb3VyY2VzIGFuZCwgYXZvaWQgb3ZlcmhlYWQgd2hpY2ggd2Ug a25vdyB3aGVuIHRoZXJlIGlzIHN1YnNjcmliZXINCj5yZW51bWJlcmluZy4NCj4gDQo+SWYgdGhp cyBpcyBub3QgZG9uZSwgZXZlbiBpZiBhZG1pbiBlbnN1cmVzIG5vIHN1YnNjcmliZXIgcmVudW1i ZXJpbmcgb2YNCj5wcmVmaXgsIGl0IGRvZXNuJ3QgZ3VhcmFudHkgdGhhdCBob3N0cyBjYW4gY29u dGludWUgdXNpbmcgbWFwcGluZ3MgdGhleQ0KPnByZXZpb3VzbHkgY3JlYXRlZCBhcyBCNCBhZGRy ZXNzIG1heSBjaGFuZ2UuDQo+DQo+Pg0KPj4tZA0KPj4NCj4+DQo+Pj4gSWYgeW91IHRoaW5rIG9m IGFueSBzdWNoIHNjZW5hcmlvcywgY2FuIHlvdSBwbGVhc2UgcG9pbnQgdGhlbT8NCj4+PiANCj4+ Pj4gDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBDb25zaWRlciBhIGNhc2Ugd2hlcmUgYW4gSVB2NiBh ZGRyZXNzIGlzIGFzc2lnbmVkIGFuZCBub3QgcHJlZml4IHRvDQo+Pj4+PnRoZQ0KPj4+Pj4gQ1BF Lg0KPj4+Pj4gSWYgdGhlIHNhbWUgSVB2NiBhZGRyZXNzIGFzc2lnbmVkIGFmdGVyIHJlYm9vdCBv ciBjaGFuZ2Ugb2YgQ1BFLA0KPj4+Pj5ob3N0cw0KPj4+Pj4gb24NCj4+Pj4+IHNlZWluZyBQQ1Ag QU5OT1VOQ0UsIHdoZW4gcmVmcmVzaGVzIHRoZWlyIG1hcHBpbmdzLCBQQ1Agc2VydmVyDQo+Pj4+ PnJlc3BvbnNlcw0KPj4+Pj4gYmFjayB3aXRoIHRoZSBleGlzdGluZyBtYXBwaW5nLCBpdCBpcyBu b3QgZ29pbmcgdG8gY3JlYXRlIG5ldyBzZXQgb2YNCj4+Pj4+IG1hcHBpbmdzIGFuZCBhZ2Ugb3V0 IGV4aXN0aW5nIG1hcHBpbmdzIHJpZ2h0Pw0KPj4+Pj4gDQo+Pj4+PiBJIGFtIGV4dGVuZGluZyB0 aGUgc2FtZSBhcmd1bWVudCB0byBwcmVmaXhlcywgd2hlcmUgQ1BFcyBhcmUgYXNzaWduZWQNCj4+ Pj4+IHdpdGgNCj4+Pj4+IHByZWZpeGVzIGFuZCBhcmUgZnJlZSB0byB1c2UgYW55IHY2IGFkZHJl c3MgaW4gdGhlIHByZWZpeCBhcyBCNA0KPj4+Pj5hZGRyZXNzLg0KPj4+Pj4gU28sIGNoYW5nZSBp biB0aGF0IGFkZHJlc3Mgc2hvdWxkIG5vdCByZXN1bHQgaW4gY3JlYXRpbmcgbmV3IG1hcHBpbmdz DQo+Pj4+PiBhbmQNCj4+Pj4+IGFnZSBvdXQgb2xkIG1hcHBpbmdzLg0KPj4+Pj4gDQo+Pj4+PiBT dXBwb3NlIGlmIHdlIGdvIHdpdGggdGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gdGhlIGRyYWZ0cyB3 aGVyZSBuZXcNCj4+Pj4+IG1hcHBpbmdzIGhhdmUgdG8gYmUgY3JlYXRlZCB3aGVuIHRoZXJlIGlz IGNoYW5nZSBpbiBhZGRyZXNzLCBhcyBhbg0KPj4+Pj4gYXR0YWNrZXIsIEkgY2FuIGV4aGF1c3Qg Q0dOQVQvUENQIHNlcnZlciByZXNvdXJjZXMsIGJ5IHBpY2tpbmcNCj4+Pj4+bXVsdGlwbGUNCj4+ Pj4+IElQdjYgYWRkcmVzc2VzIHdpdGggaW4gdGhlIGFzc2lnbmVkIHByZWZpeCBhcyBCNCBhbmQg ZmFraW5nIFBDUA0KPj4+Pj4gcmVxdWVzdHMuDQo+Pj4+IA0KPj4+PiBUaGF0IGF0dGFjayBpcyBz dGlsbCBwb3NzaWJsZSB3aXRoIHlvdXIgaWRlYS4gIFRoZSBtaXRpZ2F0aW9uLCB3aXRoIG9yDQo+ Pj4+IHdpdGhvdXQgeW91ciBpZGVhLCBpcyB0aGF0IHRoZSBBRlRSIGhhcyB0byBhcHBseSBpdHMg cG9ydCBxdW90YSB0byB0aGUNCj4+Pj4gZW50aXJldHkgb2YgdGhlIElQdjYgcHJlZml4IGFzc2ln bmVkIHRvIGEgQjQgLS0gdGhlIGVudGlyZQ0KPj4+PiJzdWJzY3JpYmVyIiwNCj4+Pj4gaWYgeW91 IHdpbGwgLS0gdHlwaWNhbGx5IHRoZSBlbnRpcmUgLzY0LiAgVGhhdCBzZWVtcyBhbiBpbXBvcnRh bnQNCj4+Pj5wb2ludA0KPj4+PiB0byBpbmNsdWRlIGluIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZS4N Cj4+PiBZZXMsIHJlc291cmNlcyBoYXZlIHRvIGJlIGNvbmZpZ3VyZWQgb24gcGVyIHByZWZpeCBi YXNpcy4gSW4gYWRkaXRpb24NCj4+PnRvDQo+Pj4gdGhhdCwgaWYgd2UgYXJlIG5vdCBtaWdyYXRp bmcgbWFwcGluZ3MsIHlvdSB3b3VsZCBiZSBlYXRpbmcgdXAgdGhlDQo+Pj5xdW90YQ0KPj4+IGJl Y2F1c2Ugb2YgdGhlIHN0YWxlIG1hcHBpbmdzIHRoYXQgSSBtZW50aW9uZWQgYmVsb3cgcmlnaHQ/ DQo+Pj4+IA0KPj4+Pj4gSWYgd2UgbGltaXQgdGhlIHJlc291cmNlcyBvbiBwZXIgcHJlZml4IGJh c2VzIG9uIENHTkFUL1BDUCwgdGhlbiBhcyBhDQo+Pj4+PiBnZW51aW5lIHVzZXIgd2hlbiB0aGVy ZSBpcyBhIGNoYW5nZSBpbiBCNCBhZGRyZXNzLCBJIHdpbGwgbm90IGJlIGFibGUNCj4+Pj4+dG8N Cj4+Pj4+IGNyZWF0ZSBhbmQgdXNlIGFsbCBteSBxdW90YSBvZiBtYXBwaW5ncywgYXMgdGhlcmUg d291bGQgYmUgc29tZSBzdGFsZQ0KPj4+Pj4gbWFwcGluZ3MgY3JlYXRlZCBiZWZvcmUgbXkgQjQg Y2hhbmdlIGVhdGluZyBteSBxdW90YS4NCj4+Pj4gDQo+Pj4+IElnbm9yaW5nIFBDUCBmb3IgYSBt b21lbnQsIHRoYXQgcHJvYmxlbSBleGlzdHMgd2l0aCBpbXBsaWNpdCBtYXBwaW5ncw0KPj4+Pmlm DQo+Pj4+IHRoZSBJU1AgcmVudW1iZXJzIGhvc3RzIGJlaGluZCB0aGUgQ0dOLiAgSSBhZG1pdCB0 aGF0IFBDUCdzIGxvbmcNCj4+Pj4gbGlmZXRpbWVzIGNhbiBtYWtlIHRoYXQgcHJvYmxlbSB3b3Jz ZS4gIE9uZSBlYXN5IHNvbHV0aW9uIGlzIHRvIHJlZHVjZQ0KPj4+PiB0aGUgbWF4aW11bSBhc3Np Z25lZCBQQ1AgbGlmZXRpbWUgb24gdGhlIENHTiBwcmlvciB0byBhbiBhZGRyZXNzDQo+Pj4+Y2hh bmdlDQo+Pj4+IGV2ZW50IC0tIG11Y2ggbGlrZSB3ZSBkbyB3aXRoIGxvd2VyaW5nIEROUyBUVEwg cHJpb3IgdG8gY2hhbmdpbmcgRE5TDQo+Pj4+IHJlY29yZHMuICBCdXQgcGVyaGFwcyBpdCBpcyBv cGVyYXRpb25hbGx5IGRpZmZpY3VsdCB0byBrbm93IHdoZW4gYW4NCj4+Pj4gYWRkcmVzcyBjaGFu Z2UgaXMgZ29pbmcgdG8gb2NjdXIuICBBIHNsaWdodGx5IG1vcmUgZGlmZmljdWx0IHNvbHV0aW9u LA0KPj4+PiB3aGljaCB3b3JrcyBldmVuIGlmIGFkZHJlc3MgY2hhbmdlcyBhcmVuJ3QgcGxhbm5l ZCwgaXMgdG8gc2VuZCBhIFBDUA0KPj4+PiBUSElSRF9QQVJUWSBkZWxldGUgbWVzc2FnZSBmcm9t IHRoZSBJU1AncyBtYW5hZ2VtZW50IHN5c3RlbSB3aGVuIGFuDQo+Pj4+IGFkZHJlc3MgY2hhbmdl IG9jY3Vycy4NCj4+PiBZZXMsIHdpdGggcmVudW1iZXJpbmcgdGhpcyBpc3N1ZSBhcmlzZXMuIFRo YXQgaXMgd2h5IHdlIHJlY29tbWVuZCBubw0KPj4+IHJlbnVtYmVyaW5nIHJpZ2h0PyBJbiB0aGlz IHNjZW5hcmlvLCBwcmVmaXggcmVudW1iZXJpbmcgaGFzIG5vdA0KPj4+b2NjdXJyZWQsDQo+Pj4g YW5kIGl0IGlzIHRoZSBJUHY2IGFkZHJlc3MgdGhhdCBjaGFuZ2VkIHdpdGggaW4gdGhlIHByZWZp eC4gWWVzLA0KPj4+c2hvcnRlcg0KPj4+IGxpZmUgdGltZSB3b3JrcywgYnV0IEkgZmVlbCB0aGF0 IGFkZHMgc3lzbG9nKGNhcHR1cmluZyBtYXBwaW5ncyB0dXBsZXMpDQo+Pj4gb3ZlciBoZWFkLg0K Pj4+IFdoZW4gYWRkcmVzcy9wcmVmaXggcmVudW1iZXJpbmcgaGFwcGVucywgSSBhZ3JlZSBhIHRo aXJkIHBhcnR5IGRlbGV0ZQ0KPj4+bXNncw0KPj4+IG9yIGEgY2xlYXIgY29tbWFuZCwgbWF5IGJl IGlzc3VlZCBieSBhZG1pbi4NCj4+PiBJIGZlZWwgaXQgaXMgYW4gb3ZlciBraWxsIHRvIHVzZSB0 aGlzIHdoZW4gYW4gYWRkcmVzcyB3aXRoIGluIHRoZQ0KPj4+cHJlZml4DQo+Pj4gY2hhbmdlcyBh bmQgbm8gc3Vic2NyaWJlciByZW51bWJlcmluZyBvZiBwcmVmaXggaGFwcGVuZWQuDQo+Pj4gVGhp cyBpcyBiZWNhdXNlIHdoZW4gbWFwcGluZ3MgYXJlIGRlbGV0ZWQsIHRoZWlyIGFzc29jaWF0ZSBz dGF0ZSBsaWtlDQo+Pj4gZmxvd3MgaGF2ZSB0byBiZSBkZWxldGVkLg0KPj4+IFRoaXMgY2FuIGNh dXNlIGxvdCBvZiBjaHVybiB3aGVuIGRlbGV0aW9uIGhhcHBlbnMgYXQgdGhlIHNhbWUgdGltZSBm b3INCj4+PiBtdWx0aXBsZSBhZGRyZXNzZXMuDQo+Pj4gDQo+Pj4+IA0KPj4+Pj4gQW5kIHRoZSB0 cmFmZmljDQo+Pj4+PiBkZXN0aW5lZCB0byB0aG9zZSBtYXBwaW5ncyBmcm9tIGludGVybmV0IHdv dWxkIGJlIHByb2Nlc3NlZCBieSBDR05BVA0KPj4+Pj5ib3gNCj4+Pj4+IG9ubHkgdG8gYmUgZHJv cHBlZCBhdCBDUEUhDQo+Pj4+IA0KPj4+PiBCdXQgdGhlIENQRSBkcm9wcGluZyB0aG9zZSBwYWNr ZXRzIGlzIG5vdCBhIG5ldyBvciBzaWduaWZpY2FudCBwcm9ibGVtDQo+Pj4+IHdoZW4gdGhlIElT UCByZW51bWJlcmVkIHRoZSBzdWJzY3JpYmVyLiAgU3VjaCBkcm9wcGluZyBvZiBwYWNrZXRzDQo+ Pj4+d291bGQNCj4+Pj4gaGFwcGVuIG9uIHRvZGF5J3MgSVB2NCBJbnRlcm5ldCBpZiB0aGUgSVNQ IHJlbnVtYmVyZWQgdHdvIHN1YnNjcmliZXJzDQo+Pj4+dG8NCj4+Pj4gc3VkZGVubHkgaGF2ZSBl YWNoIG90aGVyJ3MgSVAgYWRkcmVzc2VzIC0tIHBhY2tldHMgd291bGQgYmUgcm91dGVkIHRvDQo+ Pj4+dGhlDQo+Pj4+IHdyb25nIGhvbWUgYW5kIGdldCBkcm9wcGVkIGJ5IE5BVHMgb3IgaG9zdC1i YXNlZCBmaXJld2FsbHMsIG9yIChpZg0KPj4+PnRoZXkNCj4+Pj4gYXJlbid0IGRyb3BwZWQpIHRo ZSBwYWNrZXRzIHdvdWxkIGJlIHByb2Nlc3NlZCBieSB0aGUgaG9zdCB0byBjb25mdXNlDQo+Pj4+ VENQDQo+Pj4+IHN0YWNrcyBvciBhcHBsaWNhdGlvbnMuDQo+Pj4gTm90ZSwgSVNQIGhhcyBub3Qg cmVudW1iZXJlZCB0aGUgc3Vic2NyaWJlciB3aGlsZSBhc3NpZ25pbmcgcHJlZml4LiBJdA0KPj4+ aXMNCj4+PiB0aGUgSVB2NiBhZGRyZXNzIGRlcml2ZWQgb3V0IG9mIHRoZSBwcmVmaXggdGhhdCBj aGFuZ2VkIGNhdXNpbmcgdGhpcy4NCj4+PkFsbA0KPj4+IEkgYW0gc3VnZ2VzdGluZyBpcywganVz dCBsaWtlIHdoZW4gYWRkcmVzcyBpcyBhc3NpZ25lZCwgd2l0aG91dA0KPj4+IHJlbnVtYmVyaW5n IHN1YnNjcmliZXIsIHlvdSBjYXJyeSBvdmVyIG1hcHBpbmdzIGFjcm9zcyByZWJvb3QuDQo+Pj5T aW1pbGFybHkNCj4+PiB3aGVuIHByZWZpeCBpcyBhc3NpZ25lZCB3aXRob3V0IHJlbnVtYmVyaW5n IHN1YnNjcmliZXIsIGV2ZW4gaWYNCj4+PmFkZHJlc3Nlcw0KPj4+IHdpdGhpbiB0aGUgcHJlZml4 IGNoYW5nZSBJIGZlZWwgbWFwcGluZ3MgY2FuIGJlIGNhcnJpZWQgYWNyb3NzDQo+Pj5hZGRyZXNz ZXMNCj4+PiB3aXRoaW4gdGhlIHByZWZpeCwgYW5kIGluIGFkZGl0aW9uIHdlIGhhdmUgdG8gaGF2 ZSBwZXIgcHJlZml4IGxpbWl0cywNCj4+PmFzDQo+Pj4gInN1YnNjcmliZXIiIGlzIHJlcHJlc2Vu dGVkIGJ5IHByZWZpeCBhbmQgbm90IElQdjYgYWRkcmVzcy4NCj4+PiANCj4+PiBJIGZlZWwgd2hl biB0aGVyZSBpcyBubyByZW51bWJlcmluZyBvZiBzdWJzY3JpYmVyIHdoaWxlIGFzc2lnbmluZw0K Pj4+cHJlZml4LA0KPj4+IGl0IHNob3VsZCBiZSB0cmVhdGVkIHRoZSBzYW1lIGFzIHdoZW4gdGhl cmUgaXMgYXMgYWRkcmVzcyBhc3NpZ25tZW50DQo+Pj4gd2l0aG91dCByZW51bWJlcmluZyBvZiBz dWJzY3JpYmVyLiBUaGUgdmFsdWUgSSBzZWUgaGVyZSBpcywgaG9zdHMNCj4+PmJlaGluZA0KPj4+ IEI0LCBjYW4gZGlyZWN0bHkgdXNlIHRoZSBtYXBwaW5ncywgYW5kIHJlcHVibGlzaGluZyBvZiB0 aG9zZSBtYXBwaW5ncw0KPj4+dG8NCj4+PiBleHRlcm5hbCB3b3JsZCBjYW4gYmUgYXZvaWRlZCwg ZWZmZWN0aXZlIHV0aWxpemF0aW9uIG9mIHBvcnQgbGltaXQNCj4+PnF1b3RhDQo+Pj4gYW5kIG90 aGVyIENHTkFUIHJlc291cmNlcy4gWWVzLCB3ZSBoYXZlIHRvIGRlYmF0ZSBpZiBpdCBpbnRyb2R1 Y2VzIGFueQ0KPj4+IGlzc3Vlcy4NCj4+Pj4gDQo+Pj4+IC1kDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiBQbGVhc2UgY29tbWVudC4NCj4+Pj4+IA0KPj4+Pj4gU3VyZXNoDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gT24gNi8yMS8xMyA3OjA4IFBNLCAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5jb20+IHdy b3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gSnVuIDIxLCAyMDEzLCBhdCA2OjE2IFBN LCAiUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIg0KPj4+Pj4+IDxyZXBlbm5vQGNpc2NvLmNvbT4g d3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IEl0IHNlZW1zIHlvdSBhcmUgc3VnZ2VzdGluZyBhIHBl ciBwcmVmaXggYmluZGluZy4gU28sIGluIHlvdXINCj4+Pj4+Pj5leGFtcGxlDQo+Pj4+Pj4+IGlm DQo+Pj4+Pj4+IGludGVybmFsIGhvc3QgMTAuMC4wLjIgc2VuZHMgYSBuZXcgTUFQIHJlcXVlc3Qg dGhhdCB1c2VzIDMwMDE6YiBhcw0KPj4+Pj4+PiBzb3VyY2UNCj4+Pj4+Pj4gYWRkcmVzcywgdGhl IEFGVFIgc2hvdWxkIHVwZGF0ZSBhbnkgZXhpc3RpbmcgbWFwcGluZ3MgdG8gdXNlIHRoaXMNCj4+ Pj4+Pj5uZXcNCj4+Pj4+Pj4gc291cmNlIElQdjYgdG8gcmVhY2ggdGhlIEI0IHdoaWxlIGV4dGVy bmFsIHB1YmxpYyBJUDpwb3J0IHdvdWxkIGJlDQo+Pj4+Pj4+dGhlDQo+Pj4+Pj4+IHNhbWUuIFRo ZXJlZm9yZSBubyBuZWVkIHRvIHVwZGF0ZSBkeW5ETlMgb3Igb3RoZXIgc3R1ZmYuDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QgdGhpcyBpcyBpbnRlcmVz dGluZy4NCj4+Pj4+PiANCj4+Pj4+PiBUaGFua3MgZm9yIHN1bW1hcml6aW5nIC0gSSB1bmRlcnN0 YW5kIHRoZSBwcm9wb3NhbCBub3cuICBJdCBzZWVtcyB0bw0KPj4+Pj4+IHJlcXVpcmUgdGhlIEI0 IGFuZCB0aGUgQUZUUiBrbm93IHRoYXQgdGhlIHNhbWUgSVB2NCBtYXBwaW5nIGlzDQo+Pj4+Pj4g YXZhaWxhYmxlDQo+Pj4+Pj4gYWZ0ZXIgSVB2NiByZW51bWJlcmluZyAtLSBzcGVjaWZpY2FsbHkg dGhhdCB0aGUgc2FtZSBBRlRSIGlzIGJlaW5nDQo+Pj4+Pj51c2VkDQo+Pj4+Pj4gYW5kIGl0IHdp bGwgYXNzaWduIHRoZSBzYW1lIElQdjQgYWRkcmVzcyB0byB0aGUgQjQuICBTZWVtcyBhIGxvdCBv Zg0KPj4+Pj4+IGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSBCNCBhbmQgQUZUUiB0byBhdm9pZCB1 cGRhdGluZyBhIHJlbmRlenZvdXMNCj4+Pj4+PiBzZXJ2ZXIuICBIb3dldmVyLCB0aGUgaG9zdCAo YW5kIHRoZSBCNCkgd2lsbCBhbHdheXMgbmVlZCB0byBiZSBhYmxlDQo+Pj4+Pj50bw0KPj4+Pj4+ IGhhbmRsZSBuZXR3b3JrIHJlbnVtYmVyaW5nIHdoZXJlIHRoZSBzYW1lIElQdjQgbWFwcGluZyBp cyBub3QNCj4+Pj4+PiBhdmFpbGFibGUsDQo+Pj4+Pj4gc28gdGhpcyBpbmNyZWFzZXMgaW1wbGVt ZW50YXRpb24gYW5kIHRlc3RpbmcgZWZmb3J0LiAgVGhlIGdhaW4sIGluDQo+Pj4+Pj5teQ0KPj4+ Pj4+IG1pbmQsIGlzIHByZXR0eSBzbWFsbCBlc3BlY2lhbGx5IGNvbnNpZGVyaW5nIHRoZSBJUCBy ZW51bWJlcmluZyBoYXMNCj4+Pj4+PnRvDQo+Pj4+Pj4gYmUNCj4+Pj4+PiBpbmZyZXF1ZW50IChv ciBlbHNlIFRDUCBzZXNzaW9ucyBhcmUgZGlzcnVwdGVkLCBub2JvZHkgbXVjaA0KPj4+Pj4+YXBw cmVjaWF0ZXMNCj4+Pj4+PiB0aGF0KS4NCj4+Pj4+PiANCj4+Pj4+PiAtZA0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gNi8yMS8xMyA5OjM3IFBNLCAiU3VyZXNoIEt1bWFy IFZpbmFwYW11bGEgVmVua2F0YSINCj4+Pj4+Pj4gPHN1cmVzaGtAanVuaXBlci5uZXQ+IHdyb3Rl Og0KPj4+Pj4+PiANCj4+Pj4+Pj4+IEhpIE1vaGFtZWQvRGFuLA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBUaGFua3MgZm9yIHBvaW50aW5nIHRvIHRoZSBkcmFmdHMuDQo+Pj4+Pj4+PiBJIHVuZGVyc3Rh bmQgZnJvbSB0aGUgZHJhZnRzIHRoYXQgaWYgYSBDUEUgaXMgYXNzaWduZWQgYSBzYW1lIElQDQo+ Pj4+Pj4+PiBhZGRyZXNzDQo+Pj4+Pj4+PiBhZnRlciByZWJvb3QsIGluIGNhc2Ugb2YgRFMtTGl0 ZSwgUENQIHByb3h5IHNob3VsZCBzZW5kIEFOTk9VTkNFDQo+Pj4+Pj4+PiByZXF1ZXN0DQo+Pj4+ Pj4+PiB0byB0aGUgUENQIGNsaWVudHMuDQo+Pj4+Pj4+PiBUaGlzIHdheSwgUENQIGNsaWVudHMg d291bGQgcmVmcmVzaCB0aGVpciBtYXBwaW5ncy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gU3VwcG9z ZSBwcmVmaXggc2F5IDMwMDE6Oi81NiBpcyBhc3NpZ25lZCB0byBDUEUgYWZ0ZXIgcmVib290IGFu ZA0KPj4+Pj4+Pj5pcw0KPj4+Pj4+Pj4gc2FtZQ0KPj4+Pj4+Pj4gYXMgYmVmb3JlIHJlYm9vdC4N Cj4+Pj4+Pj4+IFN1cHBvc2UgSVB2NiBhZGRyZXNzIGJlZm9yZSByZWJvb3QgaXMgMzAwMTo6YSBh bmQgY3JlYXRlZCBzb21lDQo+Pj4+Pj4+PiBtYXBwaW5ncy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g SG93ZXZlciwgYWZ0ZXIgYSByZWJvb3QsIGEgbmV3IElQdjYgYWRkcmVzcyBtYXkgYmUgdGFrZW4g YXMgQjQgc2F5DQo+Pj4+Pj4+PiAzMDAxOjpiLiANCj4+Pj4+Pj4+IEFzIHBlciB0aGUgY3VycmVu dCBkcmFmdHMsIGNsaWVudHMgd2lsbCB0cnkgdG8gcmVmcmVzaCBtYXBwaW5ncw0KPj4+Pj4+Pj53 aXRoDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+IG5ld2x5IGFzc2lnbmVkIElQdjYgYWRkcmVzcyBh cyB0aGUgQjQgYWRkcmVzcy4NCj4+Pj4+Pj4+IFNpbmNlIHRoZSByZXF1ZXN0cyBhcmUgZnJvbSB0 aGUgZGlmZmVyZW50IElQdjYgYWRkcmVzcywgQ0dOQVQgd2lsbA0KPj4+Pj4+Pj4gdHJ5DQo+Pj4+ Pj4+PiB0bw0KPj4+Pj4+Pj4gY3JlYXRlIG5ldyBtYXBwaW5ncyBhbmQgdGhlIG9sZCBtYXBwaW5n cyBoYXZlIHRvIGFnZSBvdXQuDQo+Pj4+Pj4+PiBOb3cgaG9zdHMgdXNpbmcgdGhlc2UgbWFwcGlu Z3MgaGF2ZSB0byBwdWJsaXNoIHRoZXNlIG1hcHBpbmdzLCBmb3INCj4+Pj4+Pj4+IGV4dGVybmFs IGhvc3RzIHRvIGNvbm5lY3QgcmlnaHQ/IFRoaXMgaXMgYW4gb3ZlcmhlYWQuDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IE15IHBvaW50IGlzLCB0aGlzIG92ZXIgaGVhZCBjYW4gYmUgZWxpbWluYXRlZCB3 aGVuIHRoZXJlIGlzIGENCj4+Pj4+Pj4+Y2hhbmdlDQo+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4gYWRk cmVzcyBpbiB0aGUgcHJlZml4LCB3aHkgZG8gd2UgbmVlZCB0byBmb3JjZSBjcmVhdGlvbiBvZiBu ZXcNCj4+Pj4+Pj4+IG1hcHBpbmdzDQo+Pj4+Pj4+PiBhbmQgdGltZW91dCBvZiBvbGQgbWFwcGlu Z3M/DQo+Pj4+Pj4+PiBJbnN0ZWFkLCBjYW4gdGhlIG1hcHBpbmdzIGFuZCB0aGUgY29ycmVzcG9u ZGluZyB0cmFmZmljIGJlDQo+Pj4+Pj4+Pm1pZ3JhdGVkDQo+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4g bmV3ZXIgQjQ/IA0KPj4+Pj4+Pj4gSWYgdGhlIHNhbWUgYWRkcmVzcyBpcyBhY3F1aXJlZCBieSB0 aGUgQjQgYWZ0ZXIgcmVib290LCBDR05BVCBib3gNCj4+Pj4+Pj4+IGRvZXNuJ3QNCj4+Pj4+Pj4+ IGRpZmZlcmVudGlhdGUgcmlnaHQ/IEkgYW0gc3VnZ2VzdGluZyBjYW4gdGhpcyBiZSBleHRlbmRl ZCB0bw0KPj4+Pj4+Pj5wcmVmaXgsDQo+Pj4+Pj4+PiBzdWNoDQo+Pj4+Pj4+PiB0aGF0IGFueSBt YXBwaW5ncyBjcmVhdGVkIG92ZXIgb25lIEI0IGFkZHJlc3Mgb2YgdGhlIHByZWZpeCBiZQ0KPj4+ Pj4+Pj4gbWlncmF0ZWQgdG8NCj4+Pj4+Pj4+IGFub3RoZXIgQjQgYWRkcmVzcyB3aXRoaW4gdGhl IHNhbWUgcHJlZml4Pw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJZiB0aGVyZSBpcyBhIGNoYW5nZSBp biBwcmVmaXgsIHRoZXJlIGlzIG5vIG9wdGlvbiB0byBtaWdyYXRlIGFzDQo+Pj4+Pj4+PiBtZW50 aW9uZWQsIG5ldyBtYXBwaW5ncyBoYXZlIHRvIGJlIGNyZWF0ZWQgYW5kIG9sZCBtYXBwaW5ncyBo YXZlDQo+Pj4+Pj4+PnRvDQo+Pj4+Pj4+PiBleHBpcmUuIA0KPj4+Pj4+Pj4gQWRkcmVzcyBjaGFu Z2Ugd2l0aCBpbiBhIHByZWZpeCBjYW4gYmUgaGFuZGxlZCBtb3JlIGdyYWNlZnVsbHkNCj4+Pj4+ Pj4+cmlnaHQ/DQo+Pj4+Pj4+PiBBbSBJDQo+Pj4+Pj4+PiBtaXNzaW5nIHNvbWV0aGluZz8NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gLVN1cmVzaA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gT24gNi8yMS8xMyAzOjU1IFBNLCAiRGFuIFdpbmciIDxkd2luZ0BjaXNjby5j b20+IHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gT24gSnVuIDIxLCAy MDEzLCBhdCAyOjAyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIaSBTdXJlc2gsDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBJ ZiBhIG5ldyBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIHRoZSBCNCwgdGhlIGNvLWxvY2F0ZWQgUENQ DQo+Pj4+Pj4+Pj4+Y2xpZW50DQo+Pj4+Pj4+Pj4+IHdpbGwNCj4+Pj4+Pj4+Pj4gbmVlZCB0byBy ZS1pbnN0YWxsIHRoZSBtYXBwaW5ncyBpdCBtYW5hZ2VzLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IFdoZW4gYSBuZXcgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byB0aGUgQjQsIHRoZSBCNCdzIFBDUCBz ZXJ2ZXINCj4+Pj4+Pj4+PnNob3VsZA0KPj4+Pj4+Pj4+IGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBp biAiQWRkcmVzcyBDaGFuZ2UgRXZlbnRzIiwNCj4+Pj4+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2ODg3I3NlY3Rpb24tMTEuNS4gIFRoZSBob3N0IHdoaWNoDQo+Pj4+Pj4+Pj4g Y3JlYXRlZA0KPj4+Pj4+Pj4+IHRoZSBtYXBwaW5ncyAodGhlIFBDUCBjbGllbnQpIG5lZWRzIHRv IGJlIGF3YXJlIG9mIHRoZSBhZGRyZXNzDQo+Pj4+Pj4+Pj4gY2hhbmdlDQo+Pj4+Pj4+Pj4gdG8N Cj4+Pj4+Pj4+PiB1cGRhdGUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSByZW5kZXp2b3VzIHNlcnZl ciAoRE5TLCBTSVAsIFhNUFAsDQo+Pj4+Pj4+Pj4gd2hhdGV2ZXIpLCB3aGljaCBtZWFucyB0aGUg QjQncyBQQ1Agc2VydmVyIGlzbid0IGhlbHBpbmcgdGhpbmdzDQo+Pj4+Pj4+Pj5ieQ0KPj4+Pj4+ Pj4+IHVwZGF0aW5nIG1hcHBpbmdzIG9uIHRoZSBDR04gYnkgaXRzZWxmLg0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+IC1kDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoaXMgd2ls bCBiZSBzZWVuIGJ5IHRoZSBQQ1Agc2VydmVyIGFzIG5ldyByZXF1ZXN0cyBpZiB0aGUgUENQDQo+ Pj4+Pj4+Pj4+IENsaWVudA0KPj4+Pj4+Pj4+PiBJUCBBZGRyZXNzIGlzIG5vdCBhbHJlYWR5IGlu IHVzZSBpbiB0YWJsZSBvciByZWZyZXNoIG1hcHBpbmdzDQo+Pj4+Pj4+Pj4+IG90aGVyd2lzZS4N Cj4+Pj4+Pj4+Pj4gSW4gYm90aCBjYXNlcywgdGhlcmUgaXMgYSBmYWlsdXJlIHJpc2sgZHVlIHRv IHRoZSBwcmVzZW5jZSBvZg0KPj4+Pj4+Pj4+PnN0YWxlDQo+Pj4+Pj4+Pj4+IG1hcHBpbmdzLiBZ b3UgY2FuIGNoZWNrOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXBjcC1mYWlsdXJlLTA2I3NlY3Rp b24NCj4+Pj4+Pj4+Pj4tDQo+Pj4+Pj4+Pj4+Mi4NCj4+Pj4+Pj4+Pj4gNA0KPj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+PiBNZWQNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+IERlIDogU3VyZXNoIEt1bWFyIFZpbmFwYW11bGEgVmVua2F0YQ0KPj4+Pj4+Pj4+PlttYWls dG86c3VyZXNoa0BqdW5pcGVyLm5ldF0NCj4+Pj4+Pj4+Pj4gRW52b3nDqSA6IGpldWRpIDIwIGp1 aW4gMjAxMyAxNzowNg0KPj4+Pj4+Pj4+PiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIE9MTkMvT0xO DQo+Pj4+Pj4+Pj4+IENjIDogcGNwQGlldGYub3JnOyBtcndAcGFpbmxlc3Mtc2VjdXJpdHkuY29t OyBmZHVwb250QGlzYy5vcmcNCj4+Pj4+Pj4+Pj4gT2JqZXQgOiBSZTogQ29tbWVudHMgb24gZHJh ZnQtaWV0Zi1wY3AtZHNsaXRlLTAwLiAoUENQIERTLUxpdGUNCj4+Pj4+Pj4+Pj4gSGFuZGxpbmcp DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIaSBNb2hhbW1lZA0KPj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSBtaXNzaW5nIHNvbWUgdGhpbmcuIEhvdyBj YW4gQ0dOQVQNCj4+Pj4+Pj4+Pj5rbm93LA0KPj4+Pj4+Pj4+PiB3aGV0aGVyIHRoZSByZXF1ZXN0 IGlzIHRvIHJlZnJlc2ggZXhpc3RpbmcgbWFwcGluZ3Mgb3IgZm9yIG5ldw0KPj4+Pj4+Pj4+PiBt YXBwaW5ncw0KPj4+Pj4+Pj4+PiB3aGVuIHRoZSBDUEUgYWRkcmVzcyBjaGFuZ2VkPw0KPj4+Pj4+ Pj4+PiBBZGRyZXNzZXMgYmVoaW5kIEI0IGNhbiBvdmVybGFwIHJpZ2h0PyBUaGV5IGhhdmUgdG8g cmVseSBvbiBCNA0KPj4+Pj4+Pj4+PiBhZGRyZXNzDQo+Pj4+Pj4+Pj4+IHJpZ2h0Pw0KPj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4gU3VyZXNoDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBPbiBKdW4g MjAsIDIwMTMsIGF0IDY6MjUgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPj4+ Pj4+Pj4+PiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+PiBEZWFyIFN1cmVzaCwNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEZXSVcs IHlvdSBtYXkgZmluZCBzb21lIHRleHQgZGVzY3JpYmluZyB0aGlzIGZhaWx1cmUgY2FzZQ0KPj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PmF0Omh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1wY3AtZmFpbHVyZS0wNiNzZWN0DQo+ Pj4+Pj4+Pj4+aQ0KPj4+Pj4+Pj4+Pm9uDQo+Pj4+Pj4+Pj4+IC0yDQo+Pj4+Pj4+Pj4+IC41DQo+ Pj4+Pj4+Pj4+IC4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4g TWVkDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBEZSA6IHBjcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGNwLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhDQo+Pj4+Pj4+Pj4+cGFydA0KPj4+Pj4+ Pj4+PiBkZQ0KPj4+Pj4+Pj4+PiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhDQo+Pj4+ Pj4+Pj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMgMDI6MDANCj4+Pj4+Pj4+Pj4gw4Ag OiBwY3BAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gQ2MgOiBtcndAcGFpbmxlc3Mtc2VjdXJpdHkuY29t OyBmZHVwb250QGlzYy5vcmcNCj4+Pj4+Pj4+Pj4gT2JqZXQgOiBbcGNwXSBDb21tZW50cyBvbiBk cmFmdC1pZXRmLXBjcC1kc2xpdGUtMDAuIChQQ1AgRFMtTGl0ZQ0KPj4+Pj4+Pj4+PiBIYW5kbGlu ZykNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIaSwgDQo+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+PiBBbiBleHRlcm5hbCBJUCBhZGRyZXNzIG9mIHRoZSBDUEUgZGV2aWNlIG1h eSBjaGFuZ2UgYXMgYW5kIHdoZW4NCj4+Pj4+Pj4+Pj4gREhDUA0KPj4+Pj4+Pj4+PiBsZWFzZSBl eHBpcmVzIG9yIHdoZW4gdGhlcmUgaXMgYSByZWJvb3Qgb2YgQ1BFIGZvciBhbnkgcmVhc29uLg0K Pj4+Pj4+Pj4+PiBUcmFmZmljIGRlc3RpbmVkIGZyb20gZXh0ZXJuYWwgd29ybGQsIHRvIHRoZXNl IG1hcHBpbmdzLCBtYXkgbm90DQo+Pj4+Pj4+Pj4+IHJlYWNoDQo+Pj4+Pj4+Pj4+IGludGVuZGVk IENQRSwgYXMgdGhlcmUgaXMgY2hhbmdlIGluIGV4dGVybmFsIGFkZHJlc3MuDQo+Pj4+Pj4+Pj4+ IFJGQyA2ODg3IHJlY29tbWVuZHMgbm8gaG9zdCByZW51bWJlcmluZyB0byBoYW5kbGUgaXQuDQo+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIb3dldmVyIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQgaW4g djYgZW52aXJvbm1lbnQgZXNwZWNpYWxseSB3aXRoDQo+Pj4+Pj4+Pj4+IERTLUxpdGUsIHdoZXJl IGEgQ1BFIGlzIGFzc2lnbmVkIGEgdjZwcmVmaXggYW5kIGlzIGZyZWUgdG8gdXNlDQo+Pj4+Pj4+ Pj4+YW55DQo+Pj4+Pj4+Pj4+IGFkZHJlc3Mgd2l0aCBpbiB0aGUgcHJlZml4LiBUaG91Z2ggREhQ Q3Y2IG1heSBhc3NpZ24gc2FtZSBwcmVmaXgNCj4+Pj4+Pj4+Pj4gdG8gYQ0KPj4+Pj4+Pj4+PiBD UEUsIHRoZSBob3N0IHBvcnRpb24gaXMgdHlwaWNhbGx5IGZpbGxlZCBieSBDUEUgYW5kIHR5cGlj YWxseQ0KPj4+Pj4+Pj4+PndpdGgNCj4+Pj4+Pj4+Pj4gbWFjDQo+Pj4+Pj4+Pj4+IGFkZHJlc3Ms IHdoaWNoIGNoYW5nZXMgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBDUEUgZGV2aWNlIG9yDQo+ Pj4+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+Pj4+IHNvbWUNCj4+Pj4+Pj4+Pj4gcmVhc29uLiANCj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyAoSG9zdHMgYmVoaW5kIENQ RS9CNCwgYW5kIHRoZSBDR04gYm94KSBoYXMNCj4+Pj4+Pj4+Pj4gbm90DQo+Pj4+Pj4+Pj4+IHJl Ym9vdGVkLCB0aGUgbWFwcGluZ3MgdGhhdCB3ZXJlIGNyZWF0ZWQgYmVmb3JlIGFuZCB0aGUgdHJh ZmZpYw0KPj4+Pj4+Pj4+PiBkZXN0aW5lZA0KPj4+Pj4+Pj4+PiB0byB0aG9zZSBtYXBwaW5ncyBp ZiB0dW5uZWxlZCBvdmVyIHRvIG9sZCBCNCBhZGRyZXNzIHdvdWxkIGJlDQo+Pj4+Pj4+Pj4+IGRy b3BwZWQgYnkNCj4+Pj4+Pj4+Pj4gdGhlIENQRSBkZXZpY2UuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+PiBUaGlzIGFsc28gY2F1c2VzIG90aGVyIGluY29udmVuaWVuY2UgYXMgdGhlc2UgbWFwcGlu Z3MgaGFuZ3MNCj4+Pj4+Pj4+Pj5hcm91bmQNCj4+Pj4+Pj4+Pj4gdGlsbCB0aGV5IHRpbWVvdXQo c2NhbGluZyBpbXBhY3QgYW5kIG5vbiB1c2FnZSBvZiBwb3J0cyBhbmQNCj4+Pj4+Pj4+Pj5tZW1v cnkpDQo+Pj4+Pj4+Pj4+IG9yLA0KPj4+Pj4+Pj4+PiB1bmxlc3MsIGEgcGFja2V0IGZha2VkIHdp dGggdGhlIG9sZCBCNCBhZGRyZXNzIGFzIHNvdXJjZSBhbmQgYQ0KPj4+Pj4+Pj4+PiBkZWxldGUN Cj4+Pj4+Pj4+Pj4gcmVxdWVzdCBpcyBpc3N1ZWQuIEV2ZW4gaWYgdGhvc2UgbWFwcGluZ3MgYXJl IGRlbGV0ZWQgIGluDQo+Pj4+Pj4+Pj4+c29tZXdheSwNCj4+Pj4+Pj4+Pj4gYQ0KPj4+Pj4+Pj4+ PiBuZXcNCj4+Pj4+Pj4+Pj4gc2V0IG9mIG1hcHBpbmdzIGhhdmUgdG8gYmUgY3JlYXRlZCBhbmQg cHVibGlzaGVkIGZvciBleHRlcm5hbA0KPj4+Pj4+Pj4+PndvcmxkDQo+Pj4+Pj4+Pj4+IHRvDQo+ Pj4+Pj4+Pj4+IGNvbm5lY3QsIGV2ZXJ5IHRpbWUsIHdoZW4gc3VjaCBhbiBldmVudCBoYXBwZW5z Lg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHNjZW5hcmlvLCB3aGVyZSBlbmQg c3lzdGVtcyhob3N0cyBiZWhpbmQgQjQgYW5kIENHTkFUDQo+Pj4+Pj4+Pj4+IGRldmljZSkNCj4+ Pj4+Pj4+Pj4gYXJlIG5vdCByZWJvb3RlZCwgYnV0IGludGVybWVkaWF0ZSBDUEUgZGV2aWNlIGlz IHJlYm9vdGVkLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gU2luY2UgdGhlIGVuZCBzeXN0ZW1z IGFyZSBub3QgcmVib290ZWQsIGNhbiB0aG9zZSBtYXBwaW5ncyBiZQ0KPj4+Pj4+Pj4+PiBtaWdy YXRlZA0KPj4+Pj4+Pj4+PiBvdmVyIERTLUxpdGUgdHVubmVscz8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+IFRoZXJlIGFyZSB0d28gb3B0aW9ucyBoZXJlLCB0byByZXVzZSB0aGVzZSBtYXBwaW5n cy4NCj4+Pj4+Pj4+Pj4gCeKCrCBUaGUgb3B0aW9uIGlzLCBjcmVhdGUgbWFwcGluZ3MgYW5kIGZs b3dzIG9uIHBlciBwcmVmaXguIFRoaXMNCj4+Pj4+Pj4+Pj53YXkNCj4+Pj4+Pj4+Pj4gbWFwcGlu Z3MgYW5kIGZsb3dzIGFyZSBtaWdyYXRlZCB0byBhbnkgYWRkcmVzcyBpbiB0aGUgc2FtZQ0KPj4+ Pj4+Pj4+PnByZWZpeA0KPj4+Pj4+Pj4+PiB3aGVuDQo+Pj4+Pj4+Pj4+IGV2ZXIgdGhlcmUgaXMg Y2hhbmdlIGluIGFkZHJlc3MuIFRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIHRvIGJlDQo+Pj4+Pj4+ Pj4+dXNlZA0KPj4+Pj4+Pj4+PiBieQ0KPj4+Pj4+Pj4+PiB0aGUgQ0dOQVQgYm94LCB0byB0dW5u ZWwgcGFja2V0cyBvdmVyIHRob3NlIG1hcHBpbmdzIHRvIHRoZSBDUEUNCj4+Pj4+Pj4+Pj4gc2hv dWxkDQo+Pj4+Pj4+Pj4+IGJlIHRoZSBhZGRyZXNzIGxhc3Qgc2VlbiBieSB0aGUgQ0dOQVQgZnJv bSB0aGUgQ1BFIG9mIHRoZQ0KPj4+Pj4+Pj4+PnByZWZpeC4NCj4+Pj4+Pj4+Pj4gVGhpcw0KPj4+ Pj4+Pj4+PiB3YXksIHRyYWZmaWMgb3ZlciBtYXBwaW5ncyBhbmQgZmxvd3MgY3JlYXRlZCBvdmVy IG9sZCBCNA0KPj4+Pj4+Pj4+PmFkZHJlc3MsDQo+Pj4+Pj4+Pj4+IGNhbg0KPj4+Pj4+Pj4+PiBj b250aW51ZSB0byByZWFjaCBpbnRlbmRlZCBob3N0IG92ZXIgdGhlIG5ldyBEUy1MaXRlIHR1bm5l bC4NCj4+Pj4+Pj4+Pj4gCeKCrCBDUEUgdG8gYWNjZXB0IHBhY2tldHMgZGVzdGluZWQgdG8gYW55 IGFkZHJlc3MgaW4gdGhhdCBwcmVmaXguDQo+Pj4+Pj4+Pj4+IFRoaXMNCj4+Pj4+Pj4+Pj4gbWF5 IGJlIGEgZ2VuZXJpYyBzdGFjayBjaGFuZ2UgYW5kIG1heSBub3QgYmUgZGVzaXJhYmxlLg0KPj4+ Pj4+Pj4+PiBUaGlzIGlzIG5vdCBjb3ZlcmVkIGluDQo+Pj4+Pj4+Pj4+IGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY3AtZHNsaXRlLTAwLiBDYW4NCj4+Pj4+Pj4+ Pj50aGlzDQo+Pj4+Pj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4+IGluY2x1ZGVkIGZvciB0aGUgZGlzY3Vz c2lvbj8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFBsZWFzZSBjb21tZW50Lg0KPj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4gLVN1cmVzaA0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+PiBwY3AgbWFpbGluZyBsaXN0DQo+ Pj4+Pj4+Pj4+IHBjcEBpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BjcA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IHBjcCBtYWlsaW5nIGxp c3QNCj4+Pj4+Pj4+IHBjcEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wY3ANCj4+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+DQo+Pg0KPj4NCj4NCg0K From mohamed.boucadair@orange.com Mon Jun 24 23:05:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3C21E804B for ; Mon, 24 Jun 2013 23:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJva3e-CWOrZ for ; Mon, 24 Jun 2013 23:05:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5A21E8086 for ; Mon, 24 Jun 2013 23:05:10 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8CBB73B4E4A; Tue, 25 Jun 2013 08:05:05 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6DFDC4C06D; Tue, 25 Jun 2013 08:05:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 25 Jun 2013 08:05:05 +0200 From: To: Suresh Kumar Vinapamula Venkata Date: Tue, 25 Jun 2013 08:05:04 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5wgACaoreAAOmyUA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C7B20@PUEXCB1B.nanterre.francetelecom.fr> References: , <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net> In-Reply-To: <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.25.53623 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 06:05:17 -0000 SGkgU3VyZXNoLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCkNoZWVycywNCk1lZA0KDQo+LS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogU3VyZXNoIEt1bWFyIFZpbmFwYW11bGEgVmVu a2F0YSBbbWFpbHRvOnN1cmVzaGtAanVuaXBlci5uZXRdDQo+RW52b3nDqcKgOiBsdW5kaSAyNCBq dWluIDIwMTMgMTg6MDENCj7DgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTg0KPkNjwqA6 IERhbiBXaW5nOyBtcndAcGFpbmxlc3Mtc2VjdXJpdHkuY29tOyBwY3BAaWV0Zi5vcmc7IGZkdXBv bnRAaXNjLm9yZw0KPk9iamV0wqA6IFJlOiBbcGNwXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBj cC1kc2xpdGUtMDAuIChQQ1AgRFMtTGl0ZQ0KPkhhbmRsaW5nKQ0KPg0KPkhpIE1vaGFtZWQNCj4N Cj5ZZXMgaXQgY2FuIGJlIGV4dGVuZGVkIHRvIG90aGVyIHRyYWZmaWMuDQo+DQo+V2hlbiBpdCBj b21lcyB0byBmbG93cywgdHlwaWNhbGx5IHRoZXkgYXJlIHNob3J0IGxpdmVkIGFuZCBzbyB0aGV5 IG1heQ0KPmV4cGlyZSBldmVuIGJlZm9yZSB0aGV5IGFyZSBtaWdyYXRlZC4NCj4NCj5QY3AgY3Jl YXRlcyBtYXBwaW5ncyB0aGF0IGNhbiBiZSBsb25nIGxpdmVkLCBhbmQgdGhlcmUgaXMgYW4gZWZm b3J0DQo+aW52b2x2ZWQgaW4gcHVibGlzaGluZyB0aG9zZSBtYXBwaW5ncyBmb3IgY29ubmVjdGl2 aXR5IGZyb20gZXh0ZXJuYWwgd29ybGQuDQpbTWVkXSBGV0lXLCB5b3UgY2FuIGNoZWNrIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRlbmctcGNwLWRkbnMtMDIgDQoNCj5BbHNvIHRo ZXJlIGlzIGEgY29uc2VydmF0aW9uIG9mIE5BVCByZXNvdXJjZXMsIGFuZCBzbyB0aGUgZGlzY3Vz c2lvbi4NCltNZWRdIEkgZG8gdW5kZXJzdGFuZCB0aGlzIGFuZCBJJ20gc3VwcG9ydGl2ZSB0byB3 b3JrIG9uIHRob3NlIGlzc3Vlcy4gDQoNCj4NCj5KdXN0IGN1cmlvdXMsIGlzIHRoZXJlIGEgcmVh c29uIHdoeSB0aGVyZSB3b3VsZCBiZSBtb3JlIHRoYW4gb25lIEI0IG9uDQo+Y3VzdG9tZXIgZW5k Pw0KW01lZF0gV2UgaGF2ZSByZXF1ZXN0ZWQgdGhpcyBmZWF0dXJlIG1haW5seSBmb3IgZGltZW5z aW9uaW5nIGNvbnNpZGVyYXRpb25zIG9uIHRoZSBBRlRSIHNpZGUuIEZvciBwb3J0IHF1b3RhIGNo ZWNrcyAoYW5kIG90aGVyIGNvbnRyb2xzKSwgd2UgcmVseSBvbiB0aGUgcHJlZml4IG1hc2sgdG8g ZW5mb3JjZSBwb2xpY2llcy4NCg0KPg0KPlN1cmVzaA0KPg0KPk9uIEp1biAyMywgMjAxMywgYXQg MTE6NTQgUE0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPjxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4NCj4+IEhpIFN1cmVzaCwNCj4+DQo+PiBQbGVhc2Ug c2VlIGlubGluZS4NCj4+IENoZWVycywNCj4+IE1lZA0KPj4NCj4+PiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4+PiBEZSA6IFN1cmVzaCBLdW1hciBWaW5hcGFtdWxhIFZlbmthdGEgW21h aWx0bzpzdXJlc2hrQGp1bmlwZXIubmV0XQ0KPj4+IEVudm95w6kgOiBzYW1lZGkgMjIganVpbiAy MDEzIDAyOjM3DQo+Pj4gw4AgOiBEYW4gV2luZzsgQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE4N Cj4+PiBDYyA6IG1yd0BwYWlubGVzcy1zZWN1cml0eS5jb207IHBjcEBpZXRmLm9yZzsgZmR1cG9u dEBpc2Mub3JnDQo+Pj4gT2JqZXQgOiBSZTogW3BjcF0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1w Y3AtZHNsaXRlLTAwLiAoUENQIERTLUxpdGUNCj5IYW5kbGluZykNCj4+Pg0KPj4+IEhpIE1vaGFt ZWQvRGFuLA0KPj4+DQo+Pj4gVGhhbmtzIGZvciBwb2ludGluZyB0byB0aGUgZHJhZnRzLg0KPj4+ IEkgdW5kZXJzdGFuZCBmcm9tIHRoZSBkcmFmdHMgdGhhdCBpZiBhIENQRSBpcyBhc3NpZ25lZCBh IHNhbWUgSVAgYWRkcmVzcw0KPj4+IGFmdGVyIHJlYm9vdCwgaW4gY2FzZSBvZiBEUy1MaXRlLCBQ Q1AgcHJveHkgc2hvdWxkIHNlbmQgQU5OT1VOQ0UgcmVxdWVzdA0KPj4+IHRvIHRoZSBQQ1AgY2xp ZW50cy4NCj4+PiBUaGlzIHdheSwgUENQIGNsaWVudHMgd291bGQgcmVmcmVzaCB0aGVpciBtYXBw aW5ncy4NCj4+Pg0KPj4+IFN1cHBvc2UgcHJlZml4IHNheSAzMDAxOjovNTYgaXMgYXNzaWduZWQg dG8gQ1BFIGFmdGVyIHJlYm9vdCBhbmQgaXMgc2FtZQ0KPj4+IGFzIGJlZm9yZSByZWJvb3QuDQo+ Pj4gU3VwcG9zZSBJUHY2IGFkZHJlc3MgYmVmb3JlIHJlYm9vdCBpcyAzMDAxOjphIGFuZCBjcmVh dGVkIHNvbWUgbWFwcGluZ3MuDQo+Pj4NCj4+PiBIb3dldmVyLCBhZnRlciBhIHJlYm9vdCwgYSBu ZXcgSVB2NiBhZGRyZXNzIG1heSBiZSB0YWtlbiBhcyBCNCBzYXkNCj4+PiAzMDAxOjpiLg0KPj4+ IEFzIHBlciB0aGUgY3VycmVudCBkcmFmdHMsIGNsaWVudHMgd2lsbCB0cnkgdG8gcmVmcmVzaCBt YXBwaW5ncyB3aXRoIHRoZQ0KPj4+IG5ld2x5IGFzc2lnbmVkIElQdjYgYWRkcmVzcyBhcyB0aGUg QjQgYWRkcmVzcy4NCj4+PiBTaW5jZSB0aGUgcmVxdWVzdHMgYXJlIGZyb20gdGhlIGRpZmZlcmVu dCBJUHY2IGFkZHJlc3MsIENHTkFUIHdpbGwgdHJ5DQo+dG8NCj4+PiBjcmVhdGUgbmV3IG1hcHBp bmdzIGFuZCB0aGUgb2xkIG1hcHBpbmdzIGhhdmUgdG8gYWdlIG91dC4NCj4+PiBOb3cgaG9zdHMg dXNpbmcgdGhlc2UgbWFwcGluZ3MgaGF2ZSB0byBwdWJsaXNoIHRoZXNlIG1hcHBpbmdzLCBmb3IN Cj4+PiBleHRlcm5hbCBob3N0cyB0byBjb25uZWN0IHJpZ2h0PyBUaGlzIGlzIGFuIG92ZXJoZWFk Lg0KPj4+DQo+Pj4gTXkgcG9pbnQgaXMsIHRoaXMgb3ZlciBoZWFkIGNhbiBiZSBlbGltaW5hdGVk IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgaW4NCj4+PiBhZGRyZXNzIGluIHRoZSBwcmVmaXgsIHdo eSBkbyB3ZSBuZWVkIHRvIGZvcmNlIGNyZWF0aW9uIG9mIG5ldyBtYXBwaW5ncw0KPj4+IGFuZCB0 aW1lb3V0IG9mIG9sZCBtYXBwaW5ncz8NCj4+PiBJbnN0ZWFkLCBjYW4gdGhlIG1hcHBpbmdzIGFu ZCB0aGUgY29ycmVzcG9uZGluZyB0cmFmZmljIGJlIG1pZ3JhdGVkIHRvDQo+Pj4gbmV3ZXIgQjQ/ DQo+Pj4gSWYgdGhlIHNhbWUgYWRkcmVzcyBpcyBhY3F1aXJlZCBieSB0aGUgQjQgYWZ0ZXIgcmVi b290LCBDR05BVCBib3gNCj5kb2Vzbid0DQo+Pj4gZGlmZmVyZW50aWF0ZSByaWdodD8gSSBhbSBz dWdnZXN0aW5nIGNhbiB0aGlzIGJlIGV4dGVuZGVkIHRvIHByZWZpeCwNCj5zdWNoDQo+Pj4gdGhh dCBhbnkgbWFwcGluZ3MgY3JlYXRlZCBvdmVyIG9uZSBCNCBhZGRyZXNzIG9mIHRoZSBwcmVmaXgg YmUgbWlncmF0ZWQNCj50bw0KPj4+IGFub3RoZXIgQjQgYWRkcmVzcyB3aXRoaW4gdGhlIHNhbWUg cHJlZml4Pw0KPj4NCj4+IFtNZWRdIFRoaXMgcHJvcG9zYWwgaXMgbm90IHBjcC1zcGVjaWZpYy4g SXQgY2FuIGJlIGFwcGxpZWQgZm9yIGFsbCB0aGUNCj50cmFmZmljIGluIGNhc2Ugb25seSBvbmUg QjQgaXMgYXNzdW1lZCB0byBiZSBtb3VudGVkIGluIHRoZSBjdXN0b21lciBzaWRlICsNCj5hIG5l dyBhZGRyZXNzIHRoYXQgYmVsb25ncyB0byB0aGUgc2FtZSBwcmVmaXggaXMgYXNzaWduZWQgdG8g QjQuDQo+Pg0KPj4+DQo+Pj4gSWYgdGhlcmUgaXMgYSBjaGFuZ2UgaW4gcHJlZml4LCB0aGVyZSBp cyBubyBvcHRpb24gdG8gbWlncmF0ZSBhcw0KPj4+IG1lbnRpb25lZCwgbmV3IG1hcHBpbmdzIGhh dmUgdG8gYmUgY3JlYXRlZCBhbmQgb2xkIG1hcHBpbmdzIGhhdmUgdG8NCj4+PiBleHBpcmUuDQo+ PiBbTWVkXSBZZXMuDQo+Pg0KPj4+IEFkZHJlc3MgY2hhbmdlIHdpdGggaW4gYSBwcmVmaXggY2Fu IGJlIGhhbmRsZWQgbW9yZSBncmFjZWZ1bGx5IHJpZ2h0PyBBbQ0KPkkNCj4+PiBtaXNzaW5nIHNv bWV0aGluZz8NCj4+Pg0KPj4+IC1TdXJlc2gNCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiA2LzIxLzEz IDM6NTUgUE0sICJEYW4gV2luZyIgPGR3aW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4N Cj4+Pj4gT24gSnVuIDIxLCAyMDEzLCBhdCAyOjAyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIHdyb3RlOg0KPj4+Pg0KPj4+Pj4gSGkgU3VyZXNoLA0KPj4+Pj4NCj4+Pj4+IElmIGEg bmV3IGFkZHJlc3MgaXMgYXNzaWduZWQgdG8gdGhlIEI0LCB0aGUgY28tbG9jYXRlZCBQQ1AgY2xp ZW50IHdpbGwNCj4+Pj4+IG5lZWQgdG8gcmUtaW5zdGFsbCB0aGUgbWFwcGluZ3MgaXQgbWFuYWdl cy4NCj4+Pj4NCj4+Pj4gV2hlbiBhIG5ldyBhZGRyZXNzIGlzIGFzc2lnbmVkIHRvIHRoZSBCNCwg dGhlIEI0J3MgUENQIHNlcnZlciBzaG91bGQNCj4+Pj4gZm9sbG93IHRoZSBwcm9jZWR1cmVzIGlu ICJBZGRyZXNzIENoYW5nZSBFdmVudHMiLA0KPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2ODg3I3NlY3Rpb24tMTEuNS4gIFRoZSBob3N0IHdoaWNoDQo+Y3JlYXRlZA0KPj4+PiB0 aGUgbWFwcGluZ3MgKHRoZSBQQ1AgY2xpZW50KSBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGUgYWRk cmVzcyBjaGFuZ2UNCj50bw0KPj4+PiB1cGRhdGUgdGhlIGluZm9ybWF0aW9uIGluIHRoZSByZW5k ZXp2b3VzIHNlcnZlciAoRE5TLCBTSVAsIFhNUFAsDQo+Pj4+IHdoYXRldmVyKSwgd2hpY2ggbWVh bnMgdGhlIEI0J3MgUENQIHNlcnZlciBpc24ndCBoZWxwaW5nIHRoaW5ncyBieQ0KPj4+PiB1cGRh dGluZyBtYXBwaW5ncyBvbiB0aGUgQ0dOIGJ5IGl0c2VsZi4NCj4+Pj4NCj4+Pj4gLWQNCj4+Pj4N Cj4+Pj4NCj4+Pj4+IFRoaXMgd2lsbCBiZSBzZWVuIGJ5IHRoZSBQQ1Agc2VydmVyIGFzIG5ldyBy ZXF1ZXN0cyBpZiB0aGUgUENQIENsaWVudA0KPj4+Pj4gSVAgQWRkcmVzcyBpcyBub3QgYWxyZWFk eSBpbiB1c2UgaW4gdGFibGUgb3IgcmVmcmVzaCBtYXBwaW5ncw0KPm90aGVyd2lzZS4NCj4+Pj4+ IEluIGJvdGggY2FzZXMsIHRoZXJlIGlzIGEgZmFpbHVyZSByaXNrIGR1ZSB0byB0aGUgcHJlc2Vu Y2Ugb2Ygc3RhbGUNCj4+Pj4+IG1hcHBpbmdzLiBZb3UgY2FuIGNoZWNrOg0KPj4+Pj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLXBjcC1mYWlsdXJlLTA2I3NlY3Rp b24tMi40DQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gTWVkDQo+Pj4+Pg0KPj4+Pj4gRGUg OiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhIFttYWlsdG86c3VyZXNoa0BqdW5pcGVy Lm5ldF0NCj4+Pj4+IEVudm95w6kgOiBqZXVkaSAyMCBqdWluIDIwMTMgMTc6MDYNCj4+Pj4+IMOA IDogQk9VQ0FEQUlSIE1vaGFtZWQgT0xOQy9PTE4NCj4+Pj4+IENjIDogcGNwQGlldGYub3JnOyBt cndAcGFpbmxlc3Mtc2VjdXJpdHkuY29tOyBmZHVwb250QGlzYy5vcmcNCj4+Pj4+IE9iamV0IDog UmU6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4gKFBDUCBEUy1MaXRlDQo+ SGFuZGxpbmcpDQo+Pj4+Pg0KPj4+Pj4gSGkgTW9oYW1tZWQNCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ug Y29ycmVjdCBtZSBpZiBJIGFtIG1pc3Npbmcgc29tZSB0aGluZy4gSG93IGNhbiBDR05BVCBrbm93 LA0KPj4+Pj4gd2hldGhlciB0aGUgcmVxdWVzdCBpcyB0byByZWZyZXNoIGV4aXN0aW5nIG1hcHBp bmdzIG9yIGZvciBuZXcNCj5tYXBwaW5ncw0KPj4+Pj4gd2hlbiB0aGUgQ1BFIGFkZHJlc3MgY2hh bmdlZD8NCj4+Pj4+IEFkZHJlc3NlcyBiZWhpbmQgQjQgY2FuIG92ZXJsYXAgcmlnaHQ/IFRoZXkg aGF2ZSB0byByZWx5IG9uIEI0IGFkZHJlc3MNCj4+Pj4+IHJpZ2h0Pw0KPj4+Pj4NCj4+Pj4+IFN1 cmVzaA0KPj4+Pj4NCj4+Pj4+IE9uIEp1biAyMCwgMjAxMywgYXQgNjoyNSBBTSwgIm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iDQo+Pj4+PiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gRGVhciBTdXJlc2gsDQo+Pj4+Pg0KPj4+Pj4gRldJVywg eW91IG1heSBmaW5kIHNvbWUgdGV4dCBkZXNjcmliaW5nIHRoaXMgZmFpbHVyZSBjYXNlDQo+Pj4+ PiBhdDpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItcGNwLWZhaWx1 cmUtMDYjc2VjdGlvbi0NCj4yLjUuDQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gTWVkDQo+ Pj4+Pg0KPj4+Pj4gRGUgOiBwY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjcC1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlDQo+Pj4+PiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBW ZW5rYXRhDQo+Pj4+PiBFbnZvecOpIDogamV1ZGkgMjAganVpbiAyMDEzIDAyOjAwDQo+Pj4+PiDD gCA6IHBjcEBpZXRmLm9yZw0KPj4+Pj4gQ2MgOiBtcndAcGFpbmxlc3Mtc2VjdXJpdHkuY29tOyBm ZHVwb250QGlzYy5vcmcNCj4+Pj4+IE9iamV0IDogW3BjcF0gQ29tbWVudHMgb24gZHJhZnQtaWV0 Zi1wY3AtZHNsaXRlLTAwLiAoUENQIERTLUxpdGUNCj4+Pj4+IEhhbmRsaW5nKQ0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+Pj4+PiBBbiBleHRlcm5hbCBJUCBhZGRyZXNzIG9mIHRo ZSBDUEUgZGV2aWNlIG1heSBjaGFuZ2UgYXMgYW5kIHdoZW4gREhDUA0KPj4+Pj4gbGVhc2UgZXhw aXJlcyBvciB3aGVuIHRoZXJlIGlzIGEgcmVib290IG9mIENQRSBmb3IgYW55IHJlYXNvbi4NCj4+ Pj4+IFRyYWZmaWMgZGVzdGluZWQgZnJvbSBleHRlcm5hbCB3b3JsZCwgdG8gdGhlc2UgbWFwcGlu Z3MsIG1heSBub3QgcmVhY2gNCj4+Pj4+IGludGVuZGVkIENQRSwgYXMgdGhlcmUgaXMgY2hhbmdl IGluIGV4dGVybmFsIGFkZHJlc3MuDQo+Pj4+PiBSRkMgNjg4NyByZWNvbW1lbmRzIG5vIGhvc3Qg cmVudW1iZXJpbmcgdG8gaGFuZGxlIGl0Lg0KPj4+Pj4NCj4+Pj4+IEhvd2V2ZXIgdGhpcyBpcyBu b3Qgc3VmZmljaWVudCBpbiB2NiBlbnZpcm9ubWVudCBlc3BlY2lhbGx5IHdpdGgNCj4+Pj4+IERT LUxpdGUsIHdoZXJlIGEgQ1BFIGlzIGFzc2lnbmVkIGEgdjZwcmVmaXggYW5kIGlzIGZyZWUgdG8g dXNlIGFueQ0KPj4+Pj4gYWRkcmVzcyB3aXRoIGluIHRoZSBwcmVmaXguIFRob3VnaCBESFBDdjYg bWF5IGFzc2lnbiBzYW1lIHByZWZpeCB0byBhDQo+Pj4+PiBDUEUsIHRoZSBob3N0IHBvcnRpb24g aXMgdHlwaWNhbGx5IGZpbGxlZCBieSBDUEUgYW5kIHR5cGljYWxseSB3aXRoDQo+bWFjDQo+Pj4+ PiBhZGRyZXNzLCB3aGljaCBjaGFuZ2VzIHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgaW4gQ1BFIGRl dmljZSBvciBmb3INCj5zb21lDQo+Pj4+PiByZWFzb24uDQo+Pj4+Pg0KPj4+Pj4gU2luY2UgdGhl IGVuZCBzeXN0ZW1zIChIb3N0cyBiZWhpbmQgQ1BFL0I0LCBhbmQgdGhlIENHTiBib3gpIGhhcyBu b3QNCj4+Pj4+IHJlYm9vdGVkLCB0aGUgbWFwcGluZ3MgdGhhdCB3ZXJlIGNyZWF0ZWQgYmVmb3Jl IGFuZCB0aGUgdHJhZmZpYw0KPmRlc3RpbmVkDQo+Pj4+PiB0byB0aG9zZSBtYXBwaW5ncyBpZiB0 dW5uZWxlZCBvdmVyIHRvIG9sZCBCNCBhZGRyZXNzIHdvdWxkIGJlIGRyb3BwZWQNCj5ieQ0KPj4+ Pj4gdGhlIENQRSBkZXZpY2UuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBhbHNvIGNhdXNlcyBvdGhlciBp bmNvbnZlbmllbmNlIGFzIHRoZXNlIG1hcHBpbmdzIGhhbmdzIGFyb3VuZA0KPj4+Pj4gdGlsbCB0 aGV5IHRpbWVvdXQoc2NhbGluZyBpbXBhY3QgYW5kIG5vbiB1c2FnZSBvZiBwb3J0cyBhbmQgbWVt b3J5KQ0KPm9yLA0KPj4+Pj4gdW5sZXNzLCBhIHBhY2tldCBmYWtlZCB3aXRoIHRoZSBvbGQgQjQg YWRkcmVzcyBhcyBzb3VyY2UgYW5kIGEgZGVsZXRlDQo+Pj4+PiByZXF1ZXN0IGlzIGlzc3VlZC4g RXZlbiBpZiB0aG9zZSBtYXBwaW5ncyBhcmUgZGVsZXRlZCAgaW4gc29tZXdheSwgYQ0KPm5ldw0K Pj4+Pj4gc2V0IG9mIG1hcHBpbmdzIGhhdmUgdG8gYmUgY3JlYXRlZCBhbmQgcHVibGlzaGVkIGZv ciBleHRlcm5hbCB3b3JsZCB0bw0KPj4+Pj4gY29ubmVjdCwgZXZlcnkgdGltZSwgd2hlbiBzdWNo IGFuIGV2ZW50IGhhcHBlbnMuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBpcyBhIHNjZW5hcmlvLCB3aGVy ZSBlbmQgc3lzdGVtcyhob3N0cyBiZWhpbmQgQjQgYW5kIENHTkFUDQo+ZGV2aWNlKQ0KPj4+Pj4g YXJlIG5vdCByZWJvb3RlZCwgYnV0IGludGVybWVkaWF0ZSBDUEUgZGV2aWNlIGlzIHJlYm9vdGVk Lg0KPj4+Pj4NCj4+Pj4+IFNpbmNlIHRoZSBlbmQgc3lzdGVtcyBhcmUgbm90IHJlYm9vdGVkLCBj YW4gdGhvc2UgbWFwcGluZ3MgYmUgbWlncmF0ZWQNCj4+Pj4+IG92ZXIgRFMtTGl0ZSB0dW5uZWxz Pw0KPj4+Pj4NCj4+Pj4+IFRoZXJlIGFyZSB0d28gb3B0aW9ucyBoZXJlLCB0byByZXVzZSB0aGVz ZSBtYXBwaW5ncy4NCj4+Pj4+ICAgIOKCrCBUaGUgb3B0aW9uIGlzLCBjcmVhdGUgbWFwcGluZ3Mg YW5kIGZsb3dzIG9uIHBlciBwcmVmaXguIFRoaXMgd2F5DQo+Pj4+PiBtYXBwaW5ncyBhbmQgZmxv d3MgYXJlIG1pZ3JhdGVkIHRvIGFueSBhZGRyZXNzIGluIHRoZSBzYW1lIHByZWZpeCB3aGVuDQo+ Pj4+PiBldmVyIHRoZXJlIGlzIGNoYW5nZSBpbiBhZGRyZXNzLiBUaGUgZGVzdGluYXRpb24gYWRk cmVzcyB0byBiZSB1c2VkIGJ5DQo+Pj4+PiB0aGUgQ0dOQVQgYm94LCB0byB0dW5uZWwgcGFja2V0 cyBvdmVyIHRob3NlIG1hcHBpbmdzIHRvIHRoZSBDUEUgc2hvdWxkDQo+Pj4+PiBiZSB0aGUgYWRk cmVzcyBsYXN0IHNlZW4gYnkgdGhlIENHTkFUIGZyb20gdGhlIENQRSBvZiB0aGUgcHJlZml4LiBU aGlzDQo+Pj4+PiB3YXksIHRyYWZmaWMgb3ZlciBtYXBwaW5ncyBhbmQgZmxvd3MgY3JlYXRlZCBv dmVyIG9sZCBCNCBhZGRyZXNzLCBjYW4NCj4+Pj4+IGNvbnRpbnVlIHRvIHJlYWNoIGludGVuZGVk IGhvc3Qgb3ZlciB0aGUgbmV3IERTLUxpdGUgdHVubmVsLg0KPj4+Pj4gICAg4oKsIENQRSB0byBh Y2NlcHQgcGFja2V0cyBkZXN0aW5lZCB0byBhbnkgYWRkcmVzcyBpbiB0aGF0IHByZWZpeC4NCj5U aGlzDQo+Pj4+PiBtYXkgYmUgYSBnZW5lcmljIHN0YWNrIGNoYW5nZSBhbmQgbWF5IG5vdCBiZSBk ZXNpcmFibGUuDQo+Pj4+PiBUaGlzIGlzIG5vdCBjb3ZlcmVkIGluDQo+Pj4+PiBodHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGNwLWRzbGl0ZS0wMC4gQ2FuIHRoaXMg YmUNCj4+Pj4+IGluY2x1ZGVkIGZvciB0aGUgZGlzY3Vzc2lvbj8NCj4+Pj4+DQo+Pj4+PiBQbGVh c2UgY29tbWVudC4NCj4+Pj4+DQo+Pj4+PiAtU3VyZXNoDQo+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gcGNwIG1haWxpbmcgbGlzdA0K Pj4+Pj4gcGNwQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BjcA0KPj4NCj4NCg0K From sureshk@juniper.net Tue Jun 25 00:47:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE821F9CC2 for ; Tue, 25 Jun 2013 00:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_75=0.6, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sTFNB4dqikX for ; Tue, 25 Jun 2013 00:47:46 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3321F9C97 for ; Tue, 25 Jun 2013 00:47:45 -0700 (PDT) Received: from mail85-db8-R.bigfish.com (10.174.8.225) by DB8EHSOBE009.bigfish.com (10.174.4.72) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 07:47:41 +0000 Received: from mail85-db8 (localhost [127.0.0.1]) by mail85-db8-R.bigfish.com (Postfix) with ESMTP id 81371A4006A for ; Tue, 25 Jun 2013 07:47:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -77 X-BigFish: VPS-77(zzbb2dI98dI9371Ic89bh148cI1432I15caKJ168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail85-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=sureshk@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail85-db8 (localhost.localdomain [127.0.0.1]) by mail85-db8 (MessageSwitch) id 137214645990675_10383; Tue, 25 Jun 2013 07:47:39 +0000 (UTC) Received: from DB8EHSMHS002.bigfish.com (unknown [10.174.8.242]) by mail85-db8.bigfish.com (Postfix) with ESMTP id 117126C0047 for ; Tue, 25 Jun 2013 07:47:39 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by DB8EHSMHS002.bigfish.com (10.174.4.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Jun 2013 07:47:36 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Jun 2013 00:47:17 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 25 Jun 2013 00:47:17 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.183) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Jun 2013 00:59:10 -0700 Received: from mail26-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 07:47:15 +0000 Received: from mail26-ch1 (localhost [127.0.0.1]) by mail26-ch1-R.bigfish.com (Postfix) with ESMTP id 6B9EB4A0161 for ; Tue, 25 Jun 2013 07:47:15 +0000 (UTC) Received: from mail26-ch1 (localhost.localdomain [127.0.0.1]) by mail26-ch1 (MessageSwitch) id 137214643351674_9356; Tue, 25 Jun 2013 07:47:13 +0000 (UTC) Received: from CH1EHSMHS042.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail26-ch1.bigfish.com (Postfix) with ESMTP id 0013A160051; Tue, 25 Jun 2013 07:47:12 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS042.bigfish.com (10.43.69.251) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 07:47:12 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 07:47:12 +0000 From: Suresh Kumar Vinapamula Venkata To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5wgACaoreAAOmyUIAAHohc Date: Tue, 25 Jun 2013 07:47:11 +0000 Message-ID: <0BB22197-CF98-4084-B902-A3B903377D95@juniper.net> References: , <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net>, <94C682931C08B048B7A8645303FDC9F36EDB5C7B20@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C7B20@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.136.207.230] Content-Type: text/plain; charset="Windows-1252" 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%ORANGE.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 X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 07:47:52 -0000 Sent from my iPhone On Jun 24, 2013, at 11:05 PM, "mohamed.boucadair@orange.com" wrote: > Hi Suresh, >=20 > Please see inline. > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >> Envoy=E9 : lundi 24 juin 2013 18:01 >> =C0 : BOUCADAIR Mohamed OLNC/OLN >> Cc : Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org >> Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >> Handling) >>=20 >> Hi Mohamed >>=20 >> Yes it can be extended to other traffic. >>=20 >> When it comes to flows, typically they are short lived and so they may >> expire even before they are migrated. >>=20 >> Pcp creates mappings that can be long lived, and there is an effort >> involved in publishing those mappings for connectivity from external wor= ld. > [Med] FWIW, you can check http://tools.ietf.org/html/draft-deng-pcp-ddns-= 02=20 This draft makes sense when there is a change in mapping. But the question = is do we need to force change of mapping for the scenario that I described?= =20 >=20 >> Also there is a conservation of NAT resources, and so the discussion. > [Med] I do understand this and I'm supportive to work on those issues.=20 With the approach that I extended, dont we conserve resources? >=20 >>=20 >> Just curious, is there a reason why there would be more than one B4 on >> customer end? > [Med] We have requested this feature mainly for dimensioning consideratio= ns on the AFTR side. For port quota checks (and other controls), we rely on= the prefix mask to enforce policies. That is not sufficient right, as full quota may not be available when there= is a change in B4, even if you ensured no subscriber renumbering while ass= igning prefix?=20 >=20 >>=20 >> Suresh >>=20 >> On Jun 23, 2013, at 11:54 PM, "mohamed.boucadair@orange.com" >> wrote: >>=20 >>> Hi Suresh, >>>=20 >>> Please see inline. >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>>> Envoy=E9 : samedi 22 juin 2013 02:37 >>>> =C0 : Dan Wing; BOUCADAIR Mohamed OLNC/OLN >>>> Cc : mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org >>>> Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >> Handling) >>>>=20 >>>> Hi Mohamed/Dan, >>>>=20 >>>> Thanks for pointing to the drafts. >>>> I understand from the drafts that if a CPE is assigned a same IP addre= ss >>>> after reboot, in case of DS-Lite, PCP proxy should send ANNOUNCE reque= st >>>> to the PCP clients. >>>> This way, PCP clients would refresh their mappings. >>>>=20 >>>> Suppose prefix say 3001::/56 is assigned to CPE after reboot and is sa= me >>>> as before reboot. >>>> Suppose IPv6 address before reboot is 3001::a and created some mapping= s. >>>>=20 >>>> However, after a reboot, a new IPv6 address may be taken as B4 say >>>> 3001::b. >>>> As per the current drafts, clients will try to refresh mappings with t= he >>>> newly assigned IPv6 address as the B4 address. >>>> Since the requests are from the different IPv6 address, CGNAT will try >> to >>>> create new mappings and the old mappings have to age out. >>>> Now hosts using these mappings have to publish these mappings, for >>>> external hosts to connect right? This is an overhead. >>>>=20 >>>> My point is, this over head can be eliminated when there is a change i= n >>>> address in the prefix, why do we need to force creation of new mapping= s >>>> and timeout of old mappings? >>>> Instead, can the mappings and the corresponding traffic be migrated to >>>> newer B4? >>>> If the same address is acquired by the B4 after reboot, CGNAT box >> doesn't >>>> differentiate right? I am suggesting can this be extended to prefix, >> such >>>> that any mappings created over one B4 address of the prefix be migrate= d >> to >>>> another B4 address within the same prefix? >>>=20 >>> [Med] This proposal is not pcp-specific. It can be applied for all the >> traffic in case only one B4 is assumed to be mounted in the customer sid= e + >> a new address that belongs to the same prefix is assigned to B4. >>>=20 >>>>=20 >>>> If there is a change in prefix, there is no option to migrate as >>>> mentioned, new mappings have to be created and old mappings have to >>>> expire. >>> [Med] Yes. >>>=20 >>>> Address change with in a prefix can be handled more gracefully right? = Am >> I >>>> missing something? >>>>=20 >>>> -Suresh >>>>=20 >>>>=20 >>>>=20 >>>> On 6/21/13 3:55 PM, "Dan Wing" wrote: >>>>=20 >>>>>=20 >>>>> On Jun 21, 2013, at 2:02 AM, mohamed.boucadair@orange.com wrote: >>>>>=20 >>>>>> Hi Suresh, >>>>>>=20 >>>>>> If a new address is assigned to the B4, the co-located PCP client wi= ll >>>>>> need to re-install the mappings it manages. >>>>>=20 >>>>> When a new address is assigned to the B4, the B4's PCP server should >>>>> follow the procedures in "Address Change Events", >>>>> http://tools.ietf.org/html/rfc6887#section-11.5. The host which >> created >>>>> the mappings (the PCP client) needs to be aware of the address change >> to >>>>> update the information in the rendezvous server (DNS, SIP, XMPP, >>>>> whatever), which means the B4's PCP server isn't helping things by >>>>> updating mappings on the CGN by itself. >>>>>=20 >>>>> -d >>>>>=20 >>>>>=20 >>>>>> This will be seen by the PCP server as new requests if the PCP Clien= t >>>>>> IP Address is not already in use in table or refresh mappings >> otherwise. >>>>>> In both cases, there is a failure risk due to the presence of stale >>>>>> mappings. You can check: >>>>>> http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section-2.= 4 >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>>>>> Envoy=E9 : jeudi 20 juin 2013 17:06 >>>>>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>>>>> Cc : pcp@ietf.org; mrw@painless-security.com; fdupont@isc.org >>>>>> Objet : Re: Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >> Handling) >>>>>>=20 >>>>>> Hi Mohammed >>>>>>=20 >>>>>> Please correct me if I am missing some thing. How can CGNAT know, >>>>>> whether the request is to refresh existing mappings or for new >> mappings >>>>>> when the CPE address changed? >>>>>> Addresses behind B4 can overlap right? They have to rely on B4 addre= ss >>>>>> right? >>>>>>=20 >>>>>> Suresh >>>>>>=20 >>>>>> On Jun 20, 2013, at 6:25 AM, "mohamed.boucadair@orange.com" >>>>>> wrote: >>>>>>=20 >>>>>> Dear Suresh, >>>>>>=20 >>>>>> FWIW, you may find some text describing this failure case >>>>>> at:http://tools.ietf.org/html/draft-boucadair-pcp-failure-06#section= - >> 2.5. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part d= e >>>>>> Suresh Kumar Vinapamula Venkata >>>>>> Envoy=E9 : jeudi 20 juin 2013 02:00 >>>>>> =C0 : pcp@ietf.org >>>>>> Cc : mrw@painless-security.com; fdupont@isc.org >>>>>> Objet : [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>>>>> Handling) >>>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> An external IP address of the CPE device may change as and when DHCP >>>>>> lease expires or when there is a reboot of CPE for any reason. >>>>>> Traffic destined from external world, to these mappings, may not rea= ch >>>>>> intended CPE, as there is change in external address. >>>>>> RFC 6887 recommends no host renumbering to handle it. >>>>>>=20 >>>>>> However this is not sufficient in v6 environment especially with >>>>>> DS-Lite, where a CPE is assigned a v6prefix and is free to use any >>>>>> address with in the prefix. Though DHPCv6 may assign same prefix to = a >>>>>> CPE, the host portion is typically filled by CPE and typically with >> mac >>>>>> address, which changes when there is a change in CPE device or for >> some >>>>>> reason. >>>>>>=20 >>>>>> Since the end systems (Hosts behind CPE/B4, and the CGN box) has not >>>>>> rebooted, the mappings that were created before and the traffic >> destined >>>>>> to those mappings if tunneled over to old B4 address would be droppe= d >> by >>>>>> the CPE device. >>>>>>=20 >>>>>> This also causes other inconvenience as these mappings hangs around >>>>>> till they timeout(scaling impact and non usage of ports and memory) >> or, >>>>>> unless, a packet faked with the old B4 address as source and a delet= e >>>>>> request is issued. Even if those mappings are deleted in someway, a >> new >>>>>> set of mappings have to be created and published for external world = to >>>>>> connect, every time, when such an event happens. >>>>>>=20 >>>>>> This is a scenario, where end systems(hosts behind B4 and CGNAT >> device) >>>>>> are not rebooted, but intermediate CPE device is rebooted. >>>>>>=20 >>>>>> Since the end systems are not rebooted, can those mappings be migrat= ed >>>>>> over DS-Lite tunnels? >>>>>>=20 >>>>>> There are two options here, to reuse these mappings. >>>>>> =80 The option is, create mappings and flows on per prefix. This w= ay >>>>>> mappings and flows are migrated to any address in the same prefix wh= en >>>>>> ever there is change in address. The destination address to be used = by >>>>>> the CGNAT box, to tunnel packets over those mappings to the CPE shou= ld >>>>>> be the address last seen by the CGNAT from the CPE of the prefix. Th= is >>>>>> way, traffic over mappings and flows created over old B4 address, ca= n >>>>>> continue to reach intended host over the new DS-Lite tunnel. >>>>>> =80 CPE to accept packets destined to any address in that prefix. >> This >>>>>> may be a generic stack change and may not be desirable. >>>>>> This is not covered in >>>>>> http://trac.tools.ietf.org/html/draft-ietf-pcp-dslite-00. Can this b= e >>>>>> included for the discussion? >>>>>>=20 >>>>>> Please comment. >>>>>>=20 >>>>>> -Suresh >>>>>> _______________________________________________ >>>>>> pcp mailing list >>>>>> pcp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pcp >=20 From mohamed.boucadair@orange.com Tue Jun 25 01:05:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1B821F9FA9 for ; Tue, 25 Jun 2013 01:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsAg1pjrApob for ; Tue, 25 Jun 2013 01:05:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83921F9FB2 for ; Tue, 25 Jun 2013 01:05:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2999D22C9FB; Tue, 25 Jun 2013 10:05:41 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 077DA27C079; Tue, 25 Jun 2013 10:05:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 25 Jun 2013 10:05:40 +0200 From: To: Suresh Kumar Vinapamula Venkata Date: Tue, 25 Jun 2013 10:05:39 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5wgACaoreAAOmyUIAAHohcgAADQpA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C7BAE@PUEXCB1B.nanterre.francetelecom.fr> References: , <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net>, <94C682931C08B048B7A8645303FDC9F36EDB5C7B20@PUEXCB1B.nanterre.francetelecom.fr> <0BB22197-CF98-4084-B902-A3B903377D95@juniper.net> In-Reply-To: <0BB22197-CF98-4084-B902-A3B903377D95@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.25.45432 Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 08:05:48 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >Envoy=E9=A0: mardi 25 juin 2013 09:47 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org >Objet=A0: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >Handling) > > > >Sent from my iPhone > >On Jun 24, 2013, at 11:05 PM, "mohamed.boucadair@orange.com" > wrote: > >> Hi Suresh, >> >> Please see inline. >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >>> Envoy=E9 : lundi 24 juin 2013 18:01 >>> =C0 : BOUCADAIR Mohamed OLNC/OLN >>> Cc : Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org >>> Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite >>> Handling) >>> >>> Hi Mohamed >>> >>> Yes it can be extended to other traffic. >>> >>> When it comes to flows, typically they are short lived and so they may >>> expire even before they are migrated. >>> >>> Pcp creates mappings that can be long lived, and there is an effort >>> involved in publishing those mappings for connectivity from external >world. >> [Med] FWIW, you can check http://tools.ietf.org/html/draft-deng-pcp-ddns= - >02 > >This draft makes sense when there is a change in mapping. But the question >is do we need to force change of mapping for the scenario that I described= ? [Med] The change you proposed make sense to me if the same prefix is assign= ed to the CPE. If a new prefix is assigned, because of stale mappings, new = external IP address and/or external ports will be assigned by the server.=20 >> >>> Also there is a conservation of NAT resources, and so the discussion. >> [Med] I do understand this and I'm supportive to work on those issues. > >With the approach that I extended, dont we conserve resources? [Med] It does. This is why I suggested to extend your proposal to not be re= stricted to PCP-created mappings but be a generic behavior of the AFTR when= it detects a new IP address from the same prefix is in use. External IP ad= dress and ports are not impacted in such case.=20 >> >>> >>> Just curious, is there a reason why there would be more than one B4 on >>> customer end? >> [Med] We have requested this feature mainly for dimensioning >considerations on the AFTR side. For port quota checks (and other >controls), we rely on the prefix mask to enforce policies. > >That is not sufficient right, as full quota may not be available when ther= e >is a change in B4, even if you ensured no subscriber renumbering while >assigning prefix? [Med] If the same prefix is assigned to a CPE after reboot, and assuming ma= pping migration procedure you suggested, port quota is not impacted by any = stale mapping. Complications arise when a new prefix is assigned and mappin= gs found to an address from that prefix are already in use in the server. From sureshk@juniper.net Tue Jun 25 12:04:38 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D5121E80C8 for ; Tue, 25 Jun 2013 12:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38P-4R65rCpn for ; Tue, 25 Jun 2013 12:04:27 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67B11E8135 for ; Tue, 25 Jun 2013 12:04:07 -0700 (PDT) Received: from mail206-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE032.bigfish.com (10.243.66.97) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 19:04:06 +0000 Received: from mail206-co1 (localhost [127.0.0.1]) by mail206-co1-R.bigfish.com (Postfix) with ESMTP id AD4207401E6 for ; Tue, 25 Jun 2013 19:04:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -76 X-BigFish: VPS-76(zz98dI9371Ic89bh1432I15caKJ1447I168aJdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h683h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail206-co1: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=sureshk@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail206-co1 (localhost.localdomain [127.0.0.1]) by mail206-co1 (MessageSwitch) id 1372187044383871_21244; Tue, 25 Jun 2013 19:04:04 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.244]) by mail206-co1.bigfish.com (Postfix) with ESMTP id 4F11F600070 for ; Tue, 25 Jun 2013 19:04:04 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Jun 2013 19:03:59 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Jun 2013 12:03:58 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 25 Jun 2013 12:03:57 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.252) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 25 Jun 2013 12:08:12 -0700 Received: from mail4-db9-R.bigfish.com (10.174.16.227) by DB9EHSOBE028.bigfish.com (10.174.14.91) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Jun 2013 19:03:53 +0000 Received: from mail4-db9 (localhost [127.0.0.1]) by mail4-db9-R.bigfish.com (Postfix) with ESMTP id 2B7502801CD for ; Tue, 25 Jun 2013 19:03:53 +0000 (UTC) Received: from mail4-db9 (localhost.localdomain [127.0.0.1]) by mail4-db9 (MessageSwitch) id 1372187030773300_3446; Tue, 25 Jun 2013 19:03:50 +0000 (UTC) Received: from DB9EHSMHS010.bigfish.com (unknown [10.174.16.249]) by mail4-db9.bigfish.com (Postfix) with ESMTP id B44BD560046; Tue, 25 Jun 2013 19:03:50 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS010.bigfish.com (10.174.14.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Jun 2013 19:03:40 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.110]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0324.000; Tue, 25 Jun 2013 19:03:37 +0000 From: Suresh Kumar Vinapamula Venkata To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) Thread-Index: AQHObIsMATbg1WwwAUqK3Vq1jsXuBZk9uIRKgADgMyCAAB1xYoABKUsAgADsMAD//6c0gIAEAZ5wgACaoreAAOmyUIAAHohcgAADQpCAALACcg== Date: Tue, 25 Jun 2013 19:03:37 +0000 Message-ID: References: , <94C682931C08B048B7A8645303FDC9F36EDB25992D@PUEXCB1B.nanterre.francetelecom.fr> <8C7FCFD9-9932-4D6F-B217-474593AEF4BB@juniper.net>, <94C682931C08B048B7A8645303FDC9F36EDB5C7B20@PUEXCB1B.nanterre.francetelecom.fr> <0BB22197-CF98-4084-B902-A3B903377D95@juniper.net>, <94C682931C08B048B7A8645303FDC9F36EDB5C7BAE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C7BAE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.54] Content-Type: text/plain; charset="iso-8859-1" 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%ORANGE.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 X-FOPE-CONNECTOR: Id%12219$Dn%PAINLESS-SECURITY.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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%ISC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "mrw@painless-security.com" , "pcp@ietf.org" , "fdupont@isc.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handling) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 25 Jun 2013 19:04:38 -0000 Thanks for the clarification on your stand.=0A= =0A= As mentioned in my previous mail, yes this can be extended. And the list I = could think of as =0A= =0A= EIM,=0A= EIF,=0A= Mapped IP in case of APP, =0A= Flows, =0A= PCP, PCP being special case of (EIM/EIF/Flows)=0A= NAT POOL limits.=0A= Flow limits.=0A= =0A= Let us add more to the list. =0A= =0A= >That is not sufficient right, as full quota may not be available when ther= e=0A= >is a change in B4, even if you ensured no subscriber renumbering while=0A= >assigning prefix?=0A= [Med] If the same prefix is assigned to a CPE after reboot, and assuming ma= pping migration procedure you suggested, port quota is not impacted by any = stale mapping. Complications arise when a new prefix is assigned and mappin= gs found to an address from that prefix are already in use in the server.= =0A= =0A= Suresh> In that case I would say, server is not supposed to assign a prefix= until all the mappings or references to that prefix are cleared.=0A= =0A= =0A= ________________________________________=0A= From: mohamed.boucadair@orange.com [mohamed.boucadair@orange.com]=0A= Sent: Tuesday, June 25, 2013 1:05 AM=0A= To: Suresh Kumar Vinapamula Venkata=0A= Cc: Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org=0A= Subject: RE: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite Handl= ing)=0A= =0A= Re-,=0A= =0A= Please see inline.=0A= Cheers,=0A= Med=0A= =0A= >-----Message d'origine-----=0A= >De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]=0A= >Envoy=E9 : mardi 25 juin 2013 09:47=0A= >=C0 : BOUCADAIR Mohamed OLNC/OLN=0A= >Cc : Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org=0A= >Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite=0A= >Handling)=0A= >=0A= >=0A= >=0A= >Sent from my iPhone=0A= >=0A= >On Jun 24, 2013, at 11:05 PM, "mohamed.boucadair@orange.com"=0A= > wrote:=0A= >=0A= >> Hi Suresh,=0A= >>=0A= >> Please see inline.=0A= >> Cheers,=0A= >> Med=0A= >>=0A= >>> -----Message d'origine-----=0A= >>> De : Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]=0A= >>> Envoy=E9 : lundi 24 juin 2013 18:01=0A= >>> =C0 : BOUCADAIR Mohamed OLNC/OLN=0A= >>> Cc : Dan Wing; mrw@painless-security.com; pcp@ietf.org; fdupont@isc.org= =0A= >>> Objet : Re: [pcp] Comments on draft-ietf-pcp-dslite-00. (PCP DS-Lite=0A= >>> Handling)=0A= >>>=0A= >>> Hi Mohamed=0A= >>>=0A= >>> Yes it can be extended to other traffic.=0A= >>>=0A= >>> When it comes to flows, typically they are short lived and so they may= =0A= >>> expire even before they are migrated.=0A= >>>=0A= >>> Pcp creates mappings that can be long lived, and there is an effort=0A= >>> involved in publishing those mappings for connectivity from external=0A= >world.=0A= >> [Med] FWIW, you can check http://tools.ietf.org/html/draft-deng-pcp-ddns= -=0A= >02=0A= >=0A= >This draft makes sense when there is a change in mapping. But the question= =0A= >is do we need to force change of mapping for the scenario that I described= ?=0A= [Med] The change you proposed make sense to me if the same prefix is assign= ed to the CPE. If a new prefix is assigned, because of stale mappings, new = external IP address and/or external ports will be assigned by the server.= =0A= =0A= =0A= >>=0A= >>> Also there is a conservation of NAT resources, and so the discussion.= =0A= >> [Med] I do understand this and I'm supportive to work on those issues.= =0A= >=0A= >With the approach that I extended, dont we conserve resources?=0A= [Med] It does. This is why I suggested to extend your proposal to not be re= stricted to PCP-created mappings but be a generic behavior of the AFTR when= it detects a new IP address from the same prefix is in use. External IP ad= dress and ports are not impacted in such case.=0A= =0A= >>=0A= >>>=0A= >>> Just curious, is there a reason why there would be more than one B4 on= =0A= >>> customer end?=0A= >> [Med] We have requested this feature mainly for dimensioning=0A= >considerations on the AFTR side. For port quota checks (and other=0A= >controls), we rely on the prefix mask to enforce policies.=0A= >=0A= >That is not sufficient right, as full quota may not be available when ther= e=0A= >is a change in B4, even if you ensured no subscriber renumbering while=0A= >assigning prefix?=0A= [Med] If the same prefix is assigned to a CPE after reboot, and assuming ma= pping migration procedure you suggested, port quota is not impacted by any = stale mapping. Complications arise when a new prefix is assigned and mappin= gs found to an address from that prefix are already in use in the server.= =0A= =0A= =0A= =0A= From mohamed.boucadair@orange.com Wed Jun 26 08:05:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813F21E8087; Wed, 26 Jun 2013 08:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYrr-4sgqB-W; Wed, 26 Jun 2013 08:04:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3273511E811B; Wed, 26 Jun 2013 08:04:56 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 859F922D5F1; Wed, 26 Jun 2013 17:04:54 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 655134C015; Wed, 26 Jun 2013 17:04:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 26 Jun 2013 17:04:54 +0200 From: To: "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Date: Wed, 26 Jun 2013 17:04:52 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> In-Reply-To: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.26.131226 Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:05:00 -0000 Dear all, I submitted this short I-D to explain how PCP can be used in IPv6 SIP deplo= yments (with a focus on the managed networks case). Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: mercredi 26 juin 2013 15:40 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP for IPv6-enabled SIP Deployments Author(s) : Mohamed Boucadair Filename : draft-boucadair-pcp-sip-ipv6-00.txt Pages : 7 Date : 2013-06-26 Abstract: This document discusses how PCP can be used in IPv6-enabled SIP deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 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 mperumal@cisco.com Wed Jun 26 08:58:22 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321ED21E8063; Wed, 26 Jun 2013 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcBd435qQLM5; Wed, 26 Jun 2013 08:58:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BA52D11E80DF; Wed, 26 Jun 2013 08:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2238; q=dns/txt; s=iport; t=1372262293; x=1373471893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1Qf+oMAVxOgwxCHGz0xiv9DJRB9TgKehyS5DmLadoRs=; b=H/uTF/Eoxvw2GwMlhI6DjswmTDBl3D8TSxCdplaF+ulTBKt+yQ4LJF1X fqyfzJNCg10fMQ2dYJSLSuXJjPz2u40l372iAo/l/LAW/6kWuH1EEMOfW QwT5yBFfNPtUynePj3F/h8s/7PC8yk+xgDOz0mlkd1+Zap+M5INcITqV4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADAPy1GtJV2Y/2dsb2JhbABagwkxSb59gQEWdIIjAQEBBAEBAWsXBAIBCBEEAQELHQcnCxQJCAEBBAESCAGIBQy6NI8aMwUGgnxhA4hqkASKeoUigxGCKA X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227720897" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 15:58:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFwCsn007918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:58:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:58:11 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKA= Date: Wed, 26 Jun 2013 15:58:10 +0000 Message-ID: References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:58:22 -0000 Hi Med, This looks interesting. Comparing with ICE, what is missing are the connect= ivity checks that are particularly important when the IPv6/IPv4 path is bro= ken. So, using PCP for retrieving the external media transport addresses an= d using ICE for concluding on them might work, I think. Muthu =20 |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f |mohamed.boucadair@orange.com |Sent: Wednesday, June 26, 2013 8:35 PM |To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org |Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | |Dear all, | |I submitted this short I-D to explain how PCP can be used in IPv6 SIP depl= oyments (with a focus on the |managed networks case). | |Cheers, |Med | |-----Message d'origine----- |De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] De la part de internet- |drafts@ietf.org |Envoy=E9=A0: mercredi 26 juin 2013 15:40 |=C0=A0: i-d-announce@ietf.org |Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | | |A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. | | | Title : PCP for IPv6-enabled SIP Deployments | Author(s) : Mohamed Boucadair | Filename : draft-boucadair-pcp-sip-ipv6-00.txt | Pages : 7 | Date : 2013-06-26 | |Abstract: | This document discusses how PCP can be used in IPv6-enabled SIP | deployments. | | |The IETF datatracker status page for this draft is: |https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 | |There's also a htmlized version available at: |http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 | | |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 |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From mohamed.boucadair@orange.com Wed Jun 26 22:49:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088B21F9BCE; Wed, 26 Jun 2013 22:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1J7VxIjkobh; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0D421F9BCB; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 11851264C83; Thu, 27 Jun 2013 07:49:12 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1D75235C04E; Thu, 27 Jun 2013 07:49:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 27 Jun 2013 07:49:00 +0200 From: To: "Muthu Arul Mozhi Perumal (mperumal)" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Date: Thu, 27 Jun 2013 07:48:58 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKAAHPPhkA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C836F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] I-D Action: draft-boucadair-pcp-sip-ipv6-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: Thu, 27 Jun 2013 05:49:17 -0000 Dear Muthu, Thank you for the feedback.=20 For managed networks, there is no need to do connectivity checks. For the g= eneral case, yes PCP can co-exist with ICE as discussed in draft-penno-rtcw= eb-pcp. Various reasons are identified in that document. You may notice this text in the draft which captures this discussion: " Even in deployments where ICE [RFC5245] is required, PCP can be of great help as discussed in [I-D.penno-rtcweb-pcp]. The document is targeting SIP deployments in managed networks." Cheers, Med >-----Message d'origine----- >De=A0: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Envoy=E9=A0: mercredi 26 juin 2013 17:58 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; mmusic@ietf.org; >dispatch@ietf.org >Objet=A0: RE: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >Hi Med, > >This looks interesting. Comparing with ICE, what is missing are the >connectivity checks that are particularly important when the IPv6/IPv4 pat= h >is broken. So, using PCP for retrieving the external media transport >addresses and using ICE for concluding on them might work, I think. > >Muthu > >|-----Original Message----- >|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of >|mohamed.boucadair@orange.com >|Sent: Wednesday, June 26, 2013 8:35 PM >|To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org >|Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >|Dear all, >| >|I submitted this short I-D to explain how PCP can be used in IPv6 SIP >deployments (with a focus on the >|managed networks case). >| >|Cheers, >|Med >| >|-----Message d'origine----- >|De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] >De la part de internet- >|drafts@ietf.org >|Envoy=E9=A0: mercredi 26 juin 2013 15:40 >|=C0=A0: i-d-announce@ietf.org >|Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >| >|A New Internet-Draft is available from the on-line Internet-Drafts >directories. >| >| >| Title : PCP for IPv6-enabled SIP Deployments >| Author(s) : Mohamed Boucadair >| Filename : draft-boucadair-pcp-sip-ipv6-00.txt >| Pages : 7 >| Date : 2013-06-26 >| >|Abstract: >| This document discusses how PCP can be used in IPv6-enabled SIP >| deployments. >| >| >|The IETF datatracker status page for this draft is: >|https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 >| >|There's also a htmlized version available at: >|http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 >| >| >|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 >|_______________________________________________ >|mmusic mailing list >|mmusic@ietf.org >|https://www.ietf.org/mailman/listinfo/mmusic From repenno@cisco.com Fri Jun 28 07:44:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9121F995A for ; Fri, 28 Jun 2013 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgisBuMtBF3F for ; Fri, 28 Jun 2013 07:44:32 -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 53C2B21F9BB0 for ; Fri, 28 Jun 2013 07:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=577; q=dns/txt; s=iport; t=1372430672; x=1373640272; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NAzfLBIhKWfelPeSdi3kFVxoP6Kd2C0uqtwEmb8X9lo=; b=NMPG97Ft43IqzqG/CDjRCovJXwl9H1yJ3DktvwLaVRsQMuywOr386F1a awpptwDfIkfTNROHrTJXjpiroNLxGlUjyhGGq/KVPPVzo2fn/WTYCWAAr PSv+uAxhLjPxhaGAso8csGuwAEHBXMthu/ELlL6h6LRymxs8lrSrvzS/Q U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0FACWgzVGtJXHB/2dsb2JhbABbgwl6gkC8SYEIFnSCIwEBAQQ6UQEIIhRCGwEGAwIEEwiIBptEoDiPJDiDAmMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,958,1363132800"; d="scan'208";a="228619662" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jun 2013 14:44:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5SEiUNF008124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 14:44:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 09:44:30 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: pcp - Requested sessions have been scheduled for IETF 87 Thread-Index: AQHOc3E42B6YBKoQrkaOX+IbFBIGgplLVp6A Date: Fri, 28 Jun 2013 14:44:30 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C0C41@xmb-rcd-x04.cisco.com> In-Reply-To: <20130627200211.27666.54890.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.13.0.110805 x-originating-ip: [10.21.95.145] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] FW: pcp - Requested sessions have been scheduled for IETF 87 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.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, 28 Jun 2013 14:44:52 -0000 FYI. On 6/27/13 5:02 PM, ""IETF Secretariat"" wrote: >Dear Reinaldo Penno, > >The session(s) that you have requested have been scheduled. >Below is the scheduled session information followed by >the original request. > >pcp Session 1 (2:00:00) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Charlottenburg 1 > --------------------------------------------- > pcp Session 2 (2:00:00) > Wednesday, Afternoon Session I 1300-1500 > Room Name: Schoeneberg 1/2 > --------------------------------------------- > =20