Is there a way to age out a MAC address in EVP= N?

Does the advertising MES just withdraw it when= it ages out?

Is there a possibility to add an age to the MA= C NLRI?

Or put an age into a BGP extended community?

Jakob Heitz.

--_000_7309FCBCAE981B43ABBE69B31C8D213924383B2B2DEUSAACMS0701e_-- From wim.henderickx@alcatel-lucent.com Tue Jul 3 00:11:24 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9189E21F8607 for ; Tue, 3 Jul 2012 00:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cbPvlUlw1bwg for ; Tue, 3 Jul 2012 00:11:23 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 175C121F855E for ; Tue, 3 Jul 2012 00:11:15 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q637B3xX031377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jul 2012 09:11:19 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 3 Jul 2012 09:11:14 +0200 From: "Henderickx, Wim (Wim)" To: Jakob Heitz , "l2vpn@ietf.org" Date: Tue, 3 Jul 2012 09:11:10 +0200 Subject: RE: EVPN: MAC age Thread-Topic: EVPN: MAC age Thread-Index: Ac1Y51xRj29YAAO7TbObPRz4rQCOXQAA401Q Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <7309FCBCAE981B43ABBE69B31C8D213924383B2B2D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213924383B2B2D@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06FRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 07:11:25 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06FRMRSSXCHMBSB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aging is done in the same way as VPLS. You have a local age timer and if it= expires the MAC address is withdrawn from the EVPN. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of J= akob Heitz Sent: dinsdag 3 juli 2012 8:45 To: l2vpn@ietf.org Subject: EVPN: MAC age Is there a way to age out a MAC address in EVPN? Does the advertising MES just withdraw it when it ages out? Is there a possibility to add an age to the MAC NLRI? Or put an age into a BGP extended community? -- Jakob Heitz. --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06FRMRSSXCHMBSB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Aging is = done in the same way as VPLS. You have a local age timer and if it expires = the MAC address is withdrawn from the EVPN.

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half Of Jakob Heitz
Sent: dinsdag 3 juli 2012 8:45
To:<= /b> l2vpn@ietf.org
Subject: EVPN: MAC age

Is there a way to age out a MAC address in EVPN?

Does the advertising MES just withdraw it when it a= ges out?Is there a possibil= ity to add an age to the MAC NLRI?

Or put an age into a BGP extended community?

Jakob Heitz.

<= p class=3DMsoNormal>

, Jakob Heitz Subject: RE: EVPN: MAC age Thread-Topic: EVPN: MAC age Thread-Index: Ac1Y51xRj29YAAO7TbObPRz4rQCOXQAA401QAAIi1fA= Date: Tue, 3 Jul 2012 08:19:48 +0000 Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D213924383B2B2D@EUSAACMS0701.eamcs.ericsson.se> <14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF8FAC06@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020975B0FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTWUwTURT1dboM2DFDrfCoxExeMBoVUlxCXUr8IcEYUwSNS4I4dp7thHZa OxWpHwYFjCIoxg8QQwBBgyIQ+UDiWhFNwLoEd41LAI2iJoIirsQZBpDEOF/n3nPuufe9d4ck DHk6E8kLfuwTWBfShqvDwSRTHKwfsJmLQnMt3Qeuqyw9X9t0lmM937TLiZSCN5c0KT8GH2hT amu/q1KJjblgGSsIHj/rxwyHRbsVpfr4bNYeQAzPWVECYrwu1o7dWPBbEev1YoFDSeHMP98y ScYLDBbsHo4XHFa0It0WZ7EsWhyXgJLWOHmRwXFulncxbiyKrAMzUkaeW+A2NxLOvsFSwtu+ Iaf/4SuQC4pTC0EYCemFsKy0T6fgSHj3RZO2EISTBroTwIpnuaNBjRS8DqlllZa2wub651oZ G2kenjhfopIxQc+E+c2XgYyn0ia4P/RVp2imw8+hQrWCl8Cyw72ShiTVdCz8+XumnKboVfBE 11ud0qsBwJdPGkb0YfRmGPrQPeIPpOmGOs+M9oqCT3srVcrUNKy9eIdQ8DT4rmdYo+AZcM+p +zpF74FNwWqN0iwCdhztVSuaaHi17rG6BESWT7Atn1BSPqFEyc+DVRcGtAqeC09WvyfGcCjY o5qYrwK60wBu9fGcy5stbjGbF8RjO+/HLhxv97ibgbRJdeuMRCv4cii+DdAkQHoqeGTAZtCw 2WLA3QaiSRWaRq2qk1JTtni4gJMVnZm+7S4stgFIEshIbWrvtxkojg3sxD7PGJUsXe5hwjTZ 7pHf3p+5wGz+f4CiqKa0JJuBdkjbmYWxF/vGfGJIEkHKe1pqH+HDDpyzlXf5/9IqMkweQy+N kS9rKNHLukXeofCdINoURWXKBC0Tzu3CeG0fiJIOO5VKk1m9tKHjVX2SoUoyFGpGDKU/Zpwy 5YJt/VfbYw6tQ2U7rtRm3N49vP5jwrWCV9ZvlbNu6TeE3AYjXjunYW1Wy775NXuzHq2nb+ip iMtLjDeLOmN/3cvRoNXHS+mlFzMqDg4PBR+9aJwlrkgODp2b3bWwK/CppvFg6c/6XYN5sSW/ W85Wtp7nVtp1r5nq9MSO1MSO1n27ih8mIrXoZBPmED6R/QPoT2ZNFgQAAA== Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 08:19:47 -0000 --_000_F9336571731ADE42A5397FC831CEAA020975B0FRIDWPPMB001ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I have doubts regarding the statement in Wim's message "Aging is done in the= same way as VPLS." AFAIK VPLS implementations that learn MCA addresses from traffic typically m= aintain "usage state" for learned MAC addresses i their data path so that on= ly MAC addresses that have learned once but not seen for a long time are age= d out. To the best of my understanding, in EVPN this would still work for MAC addre= sses learned from the local ACs, but not for MAC addresses that have been in= stalled via the control plane. Or do I miss something substantial here? Regards, Sasha Regards, Sasha From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of He= nderickx, Wim (Wim) Sent: Tuesday, July 03, 2012 10:11 AM To: Jakob Heitz; l2vpn@ietf.org Subject: RE: EVPN: MAC age Aging is done in the same way as VPLS. You have a local age timer and if it= expires the MAC address is withdrawn from the EVPN. From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ja= kob Heitz Sent: dinsdag 3 juli 2012 8:45 To: l2vpn@ietf.org Subject: EVPN: MAC age Is there a way to age out a MAC address in EVPN? Does the advertising MES just withdraw it when it ages out? Is there a possibility to add an age to the MAC NLRI? Or put an age into a BGP extended community? -- Jakob Heitz. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA020975B0FRIDWPPMB001ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,
I have doubts regarding the= statement in Wim’s message “Ag= ing is done in the same way as VPLS.”=

AFAIK VPLS implementations= that learn MCA addresses from traffic typically maintain “usage state= ” for learned MAC addresses i their data path so that only MAC addresses that have learned once but not seen for a long time are aged out.=

To the best of my understan= ding, in EVPN this would still work for MAC addresses learned from the local= ACs, but not for MAC addresses that have been installed via the control plane. Or do I miss something substantial here?<= /span>

Regards,<= /p>
Sa= sha

Regards,<= /p>
Sa= sha

From: l2vpn-bounc= es@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, July 03, 2012 10:11 AM
To: Jakob Heitz; l2vpn@ietf.org
Subject: RE: EVPN: MAC age

Aging is done in the same w= ay as VPLS. You have a local age timer and if it expires the MAC address is= withdrawn from the EVPN.

From: l2vpn-bounc= es@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: dinsdag 3 juli 2012 8:45
To: l2vpn@ietf.org
Subject: EVPN: MAC age

Is there a way to age out a MAC address in E= VPN?

Does the advertising MES just withdraw it wh= en it ages out?

Is there a possibility to add an age to the= MAC NLRI?

Or put an age into a BGP extended community?=

--

Jakob Heitz.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.
--_000_F9336571731ADE42A5397FC831CEAA020975B0FRIDWPPMB001ecite_-- From wim.henderickx@alcatel-lucent.com Tue Jul 3 01:29:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EAA21F87C7 for ; Tue, 3 Jul 2012 01:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 vk4RJTPoqh-y for ; Tue, 3 Jul 2012 01:29:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75921F87C4 for ; Tue, 3 Jul 2012 01:29:26 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q638TH96016085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jul 2012 10:29:32 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 3 Jul 2012 10:28:40 +0200 From: "Henderickx, Wim (Wim)" To: "'Alexander.Vainshtein@ecitele.com'" , "'jakob.heitz@ericsson.com'" Date: Tue, 3 Jul 2012 10:28:38 +0200 Subject: Re: EVPN: MAC age Thread-Topic: EVPN: MAC age Thread-Index: Ac1Y51xRj29YAAO7TbObPRz4rQCOXQAA401QAAIi1fAAAJjw7g== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DDFRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 08:29:28 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DDFRMRSSXCHMBSB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHJlbW90ZSBtYWMgYWRkcmVzc2VzIHlvdSBjYW4gcmVseSBvbiBiZ3Agd2l0aGRyYXdzIG9y IGRvIGFnaW5nIGxvY2FsbHkgYmFzZWQgb24gYWN0aXZpdHkgb3IgYm90aC4gTm93IGdpdmVuIHRo YXQgeW91IHByb3ZpZGUgbXVsdGktcGF0aGluZyBpdCBpcyBiZXN0IHRvIHJlbHkgb24gYmdwIHdp dGhkcmF3IGZvciByZW1vdGUgbWFjIGFkZHJlc3NlcyB0byBlbnN1cmUgY29uc2lzdGVuY3kgYWNj cm9zcyBhbGwgbWVzKGVzKS4NCg0KQ2hlZXJzLA0KV2ltDQpfX19fX19fX19fX19fX19fXw0Kc2Vu dCBmcm9tIGJsYWNrYmVycnkNCg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDMs IDIwMTIgMTA6MTkgQU0NClRvOiBIZW5kZXJpY2t4LCBXaW0gKFdpbSk7IEpha29iIEhlaXR6IDxq YWtvYi5oZWl0ekBlcmljc3Nvbi5jb20+DQpDYzogbDJ2cG5AaWV0Zi5vcmcgPGwydnBuQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IEVWUE46IE1BQyBhZ2UNCg0KSGkgYWxsLA0KSSBoYXZlIGRvdWJ0 cyByZWdhcmRpbmcgdGhlIHN0YXRlbWVudCBpbiBXaW3igJlzIG1lc3NhZ2Ug4oCcQWdpbmcgaXMg ZG9uZSBpbiB0aGUgc2FtZSB3YXkgYXMgVlBMUy7igJ0NCg0KQUZBSUsgVlBMUyBpbXBsZW1lbnRh dGlvbnMgdGhhdCBsZWFybiBNQ0EgYWRkcmVzc2VzIGZyb20gdHJhZmZpYyB0eXBpY2FsbHkgbWFp bnRhaW4g4oCcdXNhZ2Ugc3RhdGXigJ0gZm9yIGxlYXJuZWQgTUFDIGFkZHJlc3NlcyBpIHRoZWly IGRhdGEgcGF0aCBzbyB0aGF0IG9ubHkgTUFDIGFkZHJlc3NlcyB0aGF0IGhhdmUgbGVhcm5lZCBv bmNlIGJ1dCBub3Qgc2VlbiBmb3IgYSBsb25nIHRpbWUgYXJlIGFnZWQgb3V0Lg0KDQpUbyB0aGUg YmVzdCBvZiBteSB1bmRlcnN0YW5kaW5nLCBpbiBFVlBOIHRoaXMgd291bGQgc3RpbGwgd29yayBm b3IgTUFDIGFkZHJlc3NlcyBsZWFybmVkIGZyb20gdGhlIGxvY2FsIEFDcywgYnV0IG5vdCBmb3Ig TUFDIGFkZHJlc3NlcyB0aGF0IGhhdmUgYmVlbiBpbnN0YWxsZWQgdmlhIHRoZSBjb250cm9sIHBs YW5lLiBPciBkbyBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsIGhlcmU/DQoNClJlZ2FyZHMs DQogICAgIFNhc2hhDQoNCg0KUmVnYXJkcywNCiAgICAgU2FzaGENCg0KRnJvbTogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDMsIDIwMTIgMTA6 MTEgQU0NClRvOiBKYWtvYiBIZWl0ejsgbDJ2cG5AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBFVlBO OiBNQUMgYWdlDQoNCkFnaW5nIGlzIGRvbmUgaW4gdGhlIHNhbWUgd2F5IGFzIFZQTFMuIFlvdSBo YXZlIGEgbG9jYWwgYWdlIHRpbWVyIGFuZCBpZiBpdCBleHBpcmVzIHRoZSBNQUMgYWRkcmVzcyBp cyB3aXRoZHJhd24gZnJvbSB0aGUgRVZQTi4NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWtvYiBIZWl0 eg0KU2VudDogZGluc2RhZyAzIGp1bGkgMjAxMiA4OjQ1DQpUbzogbDJ2cG5AaWV0Zi5vcmcNClN1 YmplY3Q6IEVWUE46IE1BQyBhZ2UNCg0KSXMgdGhlcmUgYSB3YXkgdG8gYWdlIG91dCBhIE1BQyBh ZGRyZXNzIGluIEVWUE4/DQpEb2VzIHRoZSBhZHZlcnRpc2luZyBNRVMganVzdCB3aXRoZHJhdyBp dCB3aGVuIGl0IGFnZXMgb3V0Pw0KSXMgdGhlcmUgYSBwb3NzaWJpbGl0eSB0byBhZGQgYW4gYWdl IHRvIHRoZSBNQUMgTkxSST8NCk9yIHB1dCBhbiBhZ2UgaW50byBhIEJHUCBleHRlbmRlZCBjb21t dW5pdHk/DQoNCi0tDQpKYWtvYiBIZWl0ei4NCg0KDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMg aW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24g d2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJ IFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9y LCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo= --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DDFRMRSSXCHMBSB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1XaW5kb3dzLTEyNTIiPg0KPG1ldGEgbmFtZT0iR2Vu ZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8 c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2Ut MToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuZW1haWxxdW90ZSwgbGkuZW1h aWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxmb250IHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCkZvciByZW1vdGUgbWFjIGFkZHJlc3NlcyB5b3UgY2Fu IHJlbHkgb24gYmdwIHdpdGhkcmF3cyBvciBkbyBhZ2luZyBsb2NhbGx5IGJhc2VkIG9uIGFjdGl2 aXR5IG9yIGJvdGguIE5vdyBnaXZlbiB0aGF0IHlvdSBwcm92aWRlIG11bHRpLXBhdGhpbmcgaXQg aXMgYmVzdCB0byByZWx5IG9uIGJncCB3aXRoZHJhdyBmb3IgcmVtb3RlIG1hYyBhZGRyZXNzZXMg dG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFjY3Jvc3MgYWxsIG1lcyhlcykuDTxicj4NPGJyPkNoZWVy cywNPGJyPldpbQ08YnI+X19fX19fX19fX19fX19fX18NPGJyPnNlbnQgZnJvbSBibGFja2JlcnJ5 PC9mb250Pjxicj4mbmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogQWxleGFuZGVyIFZhaW5zaHRlaW4g W21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NPGJyPjxiPlNlbnQ8L2I+ OiBUdWVzZGF5LCBKdWx5IDAzLCAyMDEyIDEwOjE5IEFNPGJyPjxiPlRvPC9iPjogSGVuZGVyaWNr eCwgV2ltIChXaW0pOyBKYWtvYiBIZWl0eiAmbHQ7amFrb2IuaGVpdHpAZXJpY3Nzb24uY29tJmd0 Ow08YnI+PGI+Q2M8L2I+OiBsMnZwbkBpZXRmLm9yZyAmbHQ7bDJ2cG5AaWV0Zi5vcmcmZ3Q7DTxi cj48Yj5TdWJqZWN0PC9iPjogUkU6IEVWUE46IE1BQyBhZ2UNPGJyPjwvZm9udD4mbmJzcDs8YnI+ PC9kaXY+DQoNCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgZG91YnRzIHJlZ2FyZGluZyB0aGUgc3Rh dGVtZW50IGluIFdpbeKAmXMgbWVzc2FnZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFnaW5nIGlzIGRvbmUNCiBpbiB0aGUgc2FtZSB3YXkgYXMg VlBMUy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKA nTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QUZBSUsgVlBMUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBsZWFybiBNQ0EgYWRk cmVzc2VzIGZyb20gdHJhZmZpYyB0eXBpY2FsbHkgbWFpbnRhaW4g4oCcdXNhZ2Ugc3RhdGXigJ0g Zm9yIGxlYXJuZWQgTUFDIGFkZHJlc3NlcyBpIHRoZWlyIGRhdGEgcGF0aCBzbyB0aGF0IG9ubHkg TUFDDQogYWRkcmVzc2VzIHRoYXQgaGF2ZSBsZWFybmVkIG9uY2UgYnV0IG5vdCBzZWVuIGZvciBh IGxvbmcgdGltZSBhcmUgYWdlZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UbyB0aGUgYmVzdCBvZiBteSB1bmRl cnN0YW5kaW5nLCBpbiBFVlBOIHRoaXMgd291bGQgc3RpbGwgd29yayBmb3IgTUFDIGFkZHJlc3Nl cyBsZWFybmVkIGZyb20gdGhlIGxvY2FsIEFDcywgYnV0IG5vdCBmb3IgTUFDIGFkZHJlc3NlcyB0 aGF0IGhhdmUgYmVlbiBpbnN0YWxsZWQNCiB2aWEgdGhlIGNvbnRyb2wgcGxhbmUuIE9yIGRvIEkg bWlzcyBzb21ldGhpbmcgc3Vic3RhbnRpYWwgaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgU2FzaGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SGVuZGVyaWNreCwgV2ltIChXaW0pPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEp1bHkgMDMsIDIwMTIgMTA6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IEph a29iIEhlaXR6OyBsMnZwbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogRVZQTjog TUFDIGFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZ2luZyBpcyBkb25lIGlu IHRoZSBzYW1lIHdheSBhcyBWUExTLiBZb3UgaGF2ZSBhIGxvY2FsIGFnZSB0aW1lciBhbmQgaWYg aXQgZXhwaXJlcyB0aGUgTUFDIGFkZHJlc3MgaXMgd2l0aGRyYXduIGZyb20gdGhlIEVWUE4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpha29iIEhlaXR6PGJyPg0KPGI+ U2VudDo8L2I+IGRpbnNkYWcgMyBqdWxpIDIwMTIgODo0NTxicj4NCjxiPlRvOjwvYj4gbDJ2cG5A aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRVZQTjogTUFDIGFnZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xv cjpwdXJwbGUiPklzIHRoZXJlIGEgd2F5IHRvIGFnZSBvdXQgYSBNQUMgYWRkcmVzcyBpbiBFVlBO Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtM dWNpZGEgQ29uc29sZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6cHVycGxlIj5Eb2VzIHRo ZSBhZHZlcnRpc2luZyBNRVMganVzdCB3aXRoZHJhdyBpdCB3aGVuIGl0IGFnZXMgb3V0Pzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6cHVycGxlIj5JcyB0aGVyZSBhIHBv c3NpYmlsaXR5IHRvIGFkZCBhbiBhZ2UgdG8gdGhlIE1BQyBOTFJJPzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVj aWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6cHVycGxlIj5PciBwdXQgYW4gYWdlIGludG8gYSBCR1Ag ZXh0ZW5kZWQgY29tbXVuaXR5Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29s b3I6cHVycGxlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPi0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5KYWtvYiBIZWl0ei48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6cHVycGxlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xl JnF1b3Q7O2NvbG9yOnB1cnBsZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD5UaGlzIGUtbWFpbCBtZXNz YWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9y bWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5 IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRo ZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DDFRMRSSXCHMBSB_-- From Alexander.Vainshtein@ecitele.com Tue Jul 3 02:12:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9640521F87DF for ; Tue, 3 Jul 2012 02:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, 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 bTlRMy2cqejI for ; Tue, 3 Jul 2012 02:12:42 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5D321F86DB for ; Tue, 3 Jul 2012 02:12:39 -0700 (PDT) Received: from [85.158.138.51:22797] by server-11.bemta-3.messagelabs.com id D8/C7-02904-E87B2FF4; Tue, 03 Jul 2012 09:12:46 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1341306765!26711160!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 28834 invoked from network); 3 Jul 2012 09:12:46 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-10.tower-174.messagelabs.com with SMTP; 3 Jul 2012 09:12:46 -0000 X-AuditID: a8571403-b7eff6d000003899-eb-4ff2b77f6d01 Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 54.34.14489.F77B2FF4; Tue, 3 Jul 2012 11:12:31 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Tue, 3 Jul 2012 11:12:44 +0200 From: Alexander Vainshtein To: "Henderickx, Wim (Wim)" Subject: RE: EVPN: MAC age Thread-Topic: EVPN: MAC age Thread-Index: Ac1Y51xRj29YAAO7TbObPRz4rQCOXQAA401QAAIi1fAAAJjw7gABhkqA Date: Tue, 3 Jul 2012 09:12:43 +0000 Message-ID: References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA020975DEFRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURh1Z7a70+rUWGWvJTrGI0haux7JSrrlD+qVNioRRJjO3O5O7M6u nW2piCzJEu2P1it0qUraxDOWepR6hA1aq4l3NEK1FknrEWmLJYI7O1QTMb/OfN/5zjl35rsU aawwmClJ9iOfzLs4fYouBQwwZwYauvMsvTfMtpflNwlb7HPEYNsfi+tnkbnBN1eScr99eqzP rav7SuSTywMgm5dlj5/3I1ZEimDn8n1SCS+Ucqwk2jkrx3pdvIDcSPbbOd7rRbLI5aSw/zzZ mCbJLJIFjyjJDjs3ryAv02abPiPTyuUscUoKizLdvORi3UhReAdicUXNLYurT5LOvR+jhPdk LVjfHa8kAyBQA8pAMgWZafBJU5jQ8DB4ry2sV7GRiQL4szWjDKRgXAvgxeDZxICescP6488T pHRmJvzwrMqgYpIphFUtkSQVD2HMcHvLZ4PGGQF7Wsp0Gp4D4+++kyrWMWNh4/uaBJ9mFsFD m98BzRibhYJOFSczq2H0y8FEOIDDfYmeIDQvE3z6quZ3aAbWXb5Lango7Iz9SNLwKLjl6KPf 2Tyw/eg2veY1GN6ueqXTOMPh9SOtukowLNRPNtRvJNRvJAQoXJ8Iw42TNcpouLu8w6DhCTB4 oNrQv34IGI4BWOSTRJe3RCm0WKZmIUHyIxfKEjzueoA36cjSdPIC6K3IigCGAlwqfW1Xd54x iS9RSt0RMJwiuKF0zzlcSiv0iKVOXnGu8hW7kBIBkCK5dPrxWdyjRb50A/J5/rRm42+7gzQP FDzqv/evmmqx/P+FM9HhxTl5RsaBt3MNQl7k+6MzkqI4SHecxxaDfciB1hdJLv/fNkElqzFS cYxPKodWvLxbkRxaPwrGUY0Nza3AqJM9MjKbaAJfGCOjkpzFcp9OFzDhgw+hI6pEKt7WPoUu LE5gcbk2IY5vT1/LHAAm69sp8TsP973+OmXTJmq0Y8HCnt3Pq3LWkpuZZbPnxDoeXOosSLd2 rEOLm0YWb2yrOHOaaXxxNb403P5t6+GdbODUFjGt66BrXFrBniLvpeYxH+dXBIPj0/zVT5uE dufc4/VXM+6fOhbTdf5oG9SZv+/KimvZGbcqd2SsbBB6m5eXOzid4uStk0ifwv8C6APZLiIE AAA= Cc: "'l2vpn@ietf.org'" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 09:12:43 -0000 --_000_F9336571731ADE42A5397FC831CEAA020975DEFRIDWPPMB001ecite_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 V2ltLA0KTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IGFuZCBoaWdobHkgaW5mb3JtYXRp dmUgcmVzcG9uc2UuDQoNClJlZ2FyZHMsDQogICAgIFNhc2hhDQoNCkZyb206IEhlbmRlcmlj a3gsIFdpbSAoV2ltKSBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNv bV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDMsIDIwMTIgMTE6MjkgQU0NClRvOiBBbGV4YW5k ZXIgVmFpbnNodGVpbjsgJ2pha29iLmhlaXR6QGVyaWNzc29uLmNvbScNCkNjOiAnbDJ2cG5A aWV0Zi5vcmcnDQpTdWJqZWN0OiBSZTogRVZQTjogTUFDIGFnZQ0KDQpGb3IgcmVtb3RlIG1h YyBhZGRyZXNzZXMgeW91IGNhbiByZWx5IG9uIGJncCB3aXRoZHJhd3Mgb3IgZG8gYWdpbmcg bG9jYWxseSBiYXNlZCBvbiBhY3Rpdml0eSBvciBib3RoLiBOb3cgZ2l2ZW4gdGhhdCB5b3Ug cHJvdmlkZSBtdWx0aS1wYXRoaW5nIGl0IGlzIGJlc3QgdG8gcmVseSBvbiBiZ3Agd2l0aGRy YXcgZm9yIHJlbW90ZSBtYWMgYWRkcmVzc2VzIHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBhY2Ny b3NzIGFsbCBtZXMoZXMpLg0KDQpDaGVlcnMsDQpXaW0NCl9fX19fX19fX19fX19fX19fDQpz ZW50IGZyb20gYmxhY2tiZXJyeQ0KDQpGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiBbbWFp bHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tXQ0KU2VudDogVHVlc2RheSwg SnVseSAwMywgMjAxMiAxMDoxOSBBTQ0KVG86IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgSmFr b2IgSGVpdHogPGpha29iLmhlaXR6QGVyaWNzc29uLmNvbT4NCkNjOiBsMnZwbkBpZXRmLm9y ZyA8bDJ2cG5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogRVZQTjogTUFDIGFnZQ0KDQpIaSBh bGwsDQpJIGhhdmUgZG91YnRzIHJlZ2FyZGluZyB0aGUgc3RhdGVtZW50IGluIFdpbeKAmXMg bWVzc2FnZSDigJxBZ2luZyBpcyBkb25lIGluIHRoZSBzYW1lIHdheSBhcyBWUExTLuKAnQ0K DQpBRkFJSyBWUExTIGltcGxlbWVudGF0aW9ucyB0aGF0IGxlYXJuIE1DQSBhZGRyZXNzZXMg ZnJvbSB0cmFmZmljIHR5cGljYWxseSBtYWludGFpbiDigJx1c2FnZSBzdGF0ZeKAnSBmb3Ig bGVhcm5lZCBNQUMgYWRkcmVzc2VzIGkgdGhlaXIgZGF0YSBwYXRoIHNvIHRoYXQgb25seSBN QUMgYWRkcmVzc2VzIHRoYXQgaGF2ZSBsZWFybmVkIG9uY2UgYnV0IG5vdCBzZWVuIGZvciBh IGxvbmcgdGltZSBhcmUgYWdlZCBvdXQuDQoNClRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3Rh bmRpbmcsIGluIEVWUE4gdGhpcyB3b3VsZCBzdGlsbCB3b3JrIGZvciBNQUMgYWRkcmVzc2Vz IGxlYXJuZWQgZnJvbSB0aGUgbG9jYWwgQUNzLCBidXQgbm90IGZvciBNQUMgYWRkcmVzc2Vz IHRoYXQgaGF2ZSBiZWVuIGluc3RhbGxlZCB2aWEgdGhlIGNvbnRyb2wgcGxhbmUuIE9yIGRv IEkgbWlzcyBzb21ldGhpbmcgc3Vic3RhbnRpYWwgaGVyZT8NCg0KUmVnYXJkcywNCiAgICAg U2FzaGENCg0KDQpSZWdhcmRzLA0KICAgICBTYXNoYQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEhlbmRlcmlja3gsIFdpbSAoV2ltKQ0KU2VudDogVHVlc2RheSwgSnVseSAwMywgMjAxMiAx MDoxMSBBTQ0KVG86IEpha29iIEhlaXR6OyBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IEVWUE46IE1BQyBhZ2UNCg0KQWdpbmcgaXMgZG9uZSBpbiB0aGUgc2FtZSB3YXkgYXMgVlBM Uy4gWW91IGhhdmUgYSBsb2NhbCBhZ2UgdGltZXIgYW5kIGlmIGl0IGV4cGlyZXMgdGhlIE1B QyBhZGRyZXNzIGlzIHdpdGhkcmF3biBmcm9tIHRoZSBFVlBOLg0KDQpGcm9tOiBsMnZwbi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpha29iIEhlaXR6DQpTZW50OiBkaW5zZGFnIDMganVsaSAyMDEyIDg6NDUNClRv OiBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDogRVZQTjogTUFDIGFnZQ0KDQpJcyB0aGVyZSBh IHdheSB0byBhZ2Ugb3V0IGEgTUFDIGFkZHJlc3MgaW4gRVZQTj8NCkRvZXMgdGhlIGFkdmVy dGlzaW5nIE1FUyBqdXN0IHdpdGhkcmF3IGl0IHdoZW4gaXQgYWdlcyBvdXQ/DQpJcyB0aGVy ZSBhIHBvc3NpYmlsaXR5IHRvIGFkZCBhbiBhZ2UgdG8gdGhlIE1BQyBOTFJJPw0KT3IgcHV0 IGFuIGFnZSBpbnRvIGEgQkdQIGV4dGVuZGVkIGNvbW11bml0eT8NCg0KLS0NCkpha29iIEhl aXR6Lg0KDQoNCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJl Y2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURF TlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUg b3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCg0KVGhpcyBlLW1haWwgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZv cm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmll dGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBm YXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVv Zi4NCg0K --_000_F9336571731ADE42A5397FC831CEAA020975DEFRIDWPPMB001ecite_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJMdWNpZGEgQ29uc29sZSI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNCA1IDQgMiAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuZW1haWxxdW90ZSwgbGkuZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7 bXNvLXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X aW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvdHMgb2YgdGhhbmtz IGZvciBhIHByb21wdCBhbmQgaGlnaGx5IGluZm9ybWF0aXZlIHJlc3BvbnNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTYXNoYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBIZW5kZXJpY2t4LCBXaW0gKFdpbSkgW21haWx0bzp3aW0u aGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgSnVseSAwMywgMjAxMiAxMToyOSBBTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVy IFZhaW5zaHRlaW47ICdqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20nPGJyPg0KPGI+Q2M6PC9i PiAnbDJ2cG5AaWV0Zi5vcmcnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFVlBOOiBNQUMg YWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciByZW1v dGUgbWFjIGFkZHJlc3NlcyB5b3UgY2FuIHJlbHkgb24gYmdwIHdpdGhkcmF3cyBvciBkbyBh Z2luZyBsb2NhbGx5IGJhc2VkIG9uIGFjdGl2aXR5IG9yIGJvdGguIE5vdyBnaXZlbiB0aGF0 IHlvdSBwcm92aWRlIG11bHRpLXBhdGhpbmcgaXQgaXMgYmVzdCB0bw0KIHJlbHkgb24gYmdw IHdpdGhkcmF3IGZvciByZW1vdGUgbWFjIGFkZHJlc3NlcyB0byBlbnN1cmUgY29uc2lzdGVu Y3kgYWNjcm9zcyBhbGwgbWVzKGVzKS4NCjxicj4NCjxicj4NCkNoZWVycywgPGJyPg0KV2lt IDxicj4NCl9fX19fX19fX19fX19fX19fIDxicj4NCnNlbnQgZnJvbSBibGFja2JlcnJ5PC9z cGFuPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb208L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij46IEFsZXhhbmRlciBWYWluc2h0ZWluIFttYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVHVlc2RheSwgSnVseSAwMywgMjAx MiAxMDoxOSBBTTxicj4NCjxiPlRvPC9iPjogSGVuZGVyaWNreCwgV2ltIChXaW0pOyBKYWtv YiBIZWl0eiAmbHQ7amFrb2IuaGVpdHpAZXJpY3Nzb24uY29tJmd0OyA8YnI+DQo8Yj5DYzwv Yj46IGwydnBuQGlldGYub3JnICZsdDtsMnZwbkBpZXRmLm9yZyZndDsgPGJyPg0KPGI+U3Vi amVjdDwvYj46IFJFOiBFVlBOOiBNQUMgYWdlIDxicj4NCjwvc3Bhbj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIGRvdWJ0cyByZWdhcmRpbmcgdGhlIHN0YXRl bWVudCBpbiBXaW3igJlzIG1lc3NhZ2Ug4oCcQWdpbmcgaXMgZG9uZSBpbiB0aGUgc2FtZSB3 YXkgYXMgVlBMUy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFGQUlLIFZQTFMgaW1w bGVtZW50YXRpb25zIHRoYXQgbGVhcm4gTUNBIGFkZHJlc3NlcyBmcm9tIHRyYWZmaWMgdHlw aWNhbGx5IG1haW50YWluIOKAnHVzYWdlIHN0YXRl4oCdIGZvciBsZWFybmVkIE1BQyBhZGRy ZXNzZXMgaSB0aGVpciBkYXRhIHBhdGggc28gdGhhdCBvbmx5IE1BQw0KIGFkZHJlc3NlcyB0 aGF0IGhhdmUgbGVhcm5lZCBvbmNlIGJ1dCBub3Qgc2VlbiBmb3IgYSBsb25nIHRpbWUgYXJl IGFnZWQgb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gdGhlIGJlc3Qgb2YgbXkg dW5kZXJzdGFuZGluZywgaW4gRVZQTiB0aGlzIHdvdWxkIHN0aWxsIHdvcmsgZm9yIE1BQyBh ZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoZSBsb2NhbCBBQ3MsIGJ1dCBub3QgZm9yIE1BQyBh ZGRyZXNzZXMgdGhhdCBoYXZlIGJlZW4gaW5zdGFsbGVkDQogdmlhIHRoZSBjb250cm9sIHBs YW5lLiBPciBkbyBJIG1pc3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsIGhlcmU/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FzaGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXJpZ2h0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IZW5kZXJpY2t4LCBXaW0gKFdpbSk8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSnVseSAwMywgMjAxMiAxMDoxMSBBTTxicj4NCjxiPlRvOjwv Yj4gSmFrb2IgSGVpdHo7IGwydnBuQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBFVlBOOiBNQUMgYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFnaW5nIGlzIGRvbmUgaW4gdGhlIHNhbWUgd2F5IGFzIFZQTFMuIFlvdSBoYXZlIGEg bG9jYWwgYWdlIHRpbWVyIGFuZCBpZiBpdCBleHBpcmVzIHRoZSBNQUMgYWRkcmVzcyBpcyB3 aXRoZHJhd24gZnJvbSB0aGUgRVZQTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFrb2IgSGVpdHo8YnI+DQo8 Yj5TZW50OjwvYj4gZGluc2RhZyAzIGp1bGkgMjAxMiA4OjQ1PGJyPg0KPGI+VG86PC9iPiBs MnZwbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBFVlBOOiBNQUMgYWdlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBD b25zb2xlJnF1b3Q7O2NvbG9yOnB1cnBsZSI+SXMgdGhlcmUgYSB3YXkgdG8gYWdlIG91dCBh IE1BQyBhZGRyZXNzIGluIEVWUE4/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29u c29sZSZxdW90Oztjb2xvcjpwdXJwbGUiPkRvZXMgdGhlIGFkdmVydGlzaW5nIE1FUyBqdXN0 IHdpdGhkcmF3IGl0IHdoZW4gaXQgYWdlcyBvdXQ/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtM dWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpwdXJwbGUiPklzIHRoZXJlIGEgcG9zc2liaWxp dHkgdG8gYWRkIGFuIGFnZSB0byB0aGUgTUFDIE5MUkk/PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjpwdXJwbGUiPk9yIHB1dCBhbiBhZ2UgaW50 byBhIEJHUCBleHRlbmRlZCBjb21tdW5pdHk/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNp ZGEgQ29uc29sZSZxdW90Oztjb2xvcjpwdXJwbGUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENv bnNvbGUmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkpha29i IEhlaXR6Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6cHVycGxlIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNv bGUmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cD5U aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkg YW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBl LW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlDQogdGhlIG9yaWdpbmFsIGFu ZCBhbGwgY29waWVzIHRoZXJlb2YuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwPlRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQg b25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFu ZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVz IGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F9336571731ADE42A5397FC831CEAA020975DEFRIDWPPMB001ecite_-- From lizho.jin@gmail.com Tue Jul 3 06:10:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B5A21F8855 for ; Tue, 3 Jul 2012 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2KY1nOKIXUc for ; Tue, 3 Jul 2012 06:10:29 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F176C21F8649 for ; Tue, 3 Jul 2012 06:10:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5820727ghb.31 for ; Tue, 03 Jul 2012 06:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XkGsVyvRPGoyxI7dWSfmfK7oCaw1WqQmswEE6e4sVqU=; b=B3x0PGRhTGvIDXj8sz9AFGBnXGXk7cRWEAiOEpj5eBoGewfcCljH8rsNxfg76N2PAf AAL6f3r/0s+M2BkB8ImG9TTKXuOG/uW0vaeQ0nwdqvCCetYnTJ5uDNdAHUEp+V6T5eo0 qXw+55i5iRD8+WclWKSeVMqEJEm+nk+fMR/519jBgy2L6WbakBj4Tjk6CmQrVvGYbJwf zCkGiCMCCLMz0RmCPh2p0Uj4a9L5eoRIfS9QfULKLtIImH7oTZHPv6Be1qM2U6Shbwp6 8qyNvg50MqpCFDwYDaymJ3VbhIwo6tjAEoJXgPTUr6HHlXZWQv2NjSU122FzYClUmK0y SetQ== MIME-Version: 1.0 Received: by 10.50.189.135 with SMTP id gi7mr8030071igc.8.1341321031153; Tue, 03 Jul 2012 06:10:31 -0700 (PDT) Received: by 10.50.106.198 with HTTP; Tue, 3 Jul 2012 06:10:31 -0700 (PDT) Date: Tue, 3 Jul 2012 21:10:31 +0800 Message-ID: Subject: Re: EVPN: MAC age From: Lizhong Jin To: l2vpn@ietf.org, "Henderickx, Wim (Wim)" Content-Type: multipart/alternative; boundary=14dae934040b977a1804c3eca30a X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:10:34 -0000 --14dae934040b977a1804c3eca30a Content-Type: text/plain; charset=ISO-8859-1 Hi Wim, I have slightly different opinion about the aging. If the remote MAC advertised by BGP is aged out by receiving node, how to learn the MAC address again? Will the unknown unicast packet be broadcasted if aged out? In my opinion, the control plane should maintain all the MAC address advertised by BGP without aging, but the dataplane could maintain the active MAC address only. When not matching for packet forwarding, lookup the table in control plane, and install the corresponding active MAC entry in dataplane. Jakob's question is to ask for adding an age time to the MAC NLRI. I do not suggest to do that. If MAC address is aged out, how to handle the potential unknow unicast packet? Lizhong > ------------------------------------- > Message: 1 > Date: Tue, 3 Jul 2012 10:28:38 +0200 > From: "Henderickx, Wim (Wim)" > To: "'Alexander.Vainshtein@ecitele.com'" > , "'jakob.heitz@ericsson.com > '" > > Cc: "'l2vpn@ietf.org'" > Subject: Re: EVPN: MAC age > Message-ID: > < > 14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com > > > > Content-Type: text/plain; charset="utf-8" > > For remote mac addresses you can rely on bgp withdraws or do aging locally > based on activity or both. Now given that you provide multi-pathing it is > best to rely on bgp withdraw for remote mac addresses to ensure consistency > accross all mes(es). > > Cheers, > Wim > _________________ > sent from blackberry > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, July 03, 2012 10:19 AM > To: Henderickx, Wim (Wim); Jakob Heitz > Cc: l2vpn@ietf.org > Subject: RE: EVPN: MAC age > > Hi all, > I have doubts regarding the statement in Wim?s message ?Aging is done in > the same way as VPLS.? > > AFAIK VPLS implementations that learn MCA addresses from traffic typically > maintain ?usage state? for learned MAC addresses i their data path so that > only MAC addresses that have learned once but not seen for a long time are > aged out. > > To the best of my understanding, in EVPN this would still work for MAC > addresses learned from the local ACs, but not for MAC addresses that have > been installed via the control plane. Or do I miss something substantial > here? > > Regards, > Sasha > > > Regards, > Sasha > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Tuesday, July 03, 2012 10:11 AM > To: Jakob Heitz; l2vpn@ietf.org > Subject: RE: EVPN: MAC age > > Aging is done in the same way as VPLS. You have a local age timer and if > it expires the MAC address is withdrawn from the EVPN. > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Jakob Heitz > Sent: dinsdag 3 juli 2012 8:45 > To: l2vpn@ietf.org > Subject: EVPN: MAC age > > Is there a way to age out a MAC address in EVPN? > Does the advertising MES just withdraw it when it ages out? > Is there a possibility to add an age to the MAC NLRI? > Or put an age into a BGP extended community? > > -- > Jakob Heitz. > > --14dae934040b977a1804c3eca30a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Wim,

I have slightly different opinion about the aging. If the remote=A0MAC= advertised by BGP is aged out by receiving node, how to learn the MAC addr= ess again? Will the unknown unicast packet be broadcasted if aged out?
In my opinion, the control plane should maintain all the MAC address a= dvertised by BGP without aging, but the dataplane could maintain the active= MAC address only. When not matching for packet forwarding, lookup the tabl= e in control plane, and install the corresponding active MAC entry in datap= lane.

=A0

Jakob's question is to ask for=A0 adding an age time=A0to the MAC = NLRI. I do not suggest to do that. If MAC address=A0is aged out, how to han= dle the potential=A0unknow unicast packet?

=A0

Lizhong

=A0

-------------------------------------=
Message: 1
Date: Tue, 3 Jul 2012 10:28:38 +0200
From: "Hende= rickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "'Alexande= r.Vainshtein@ecitele.com'"
=A0 =A0 =A0 =A0 <Alexander.Vainshtein@ecitele.com>, =A0 =A0 "'jakob= .heitz@ericsson.com'"
=A0 =A0 =A0 =A0 <jakob.heitz= @ericsson.com>
Cc: "'l= 2vpn@ietf.org'" <l2vpn@ie= tf.org>
Subject: Re: EVPN: MAC age
Message-ID:
=A0 =A0 =A0 =A0 <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.d= c-m.alcatel-lucent.com>

Content-Type: text/plain; charset=3D"utf-8"

For remote= mac addresses you can rely on bgp withdraws or do aging locally based on a= ctivity or both. Now given that you provide multi-pathing it is best to rel= y on bgp withdraw for remote mac addresses to ensure consistency accross al= l mes(es).

Cheers,
Wim
_________________
sent from blackberry

From= : Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, July 03, 20= 12 10:19 AM
To: Henderickx, Wim (Wim); Jakob Heitz <jakob.heitz@ericsson.com>
Cc: l2vpn@ietf.org <l2vpn@i= etf.org>
Subject: RE: EVPN: MAC age

Hi all,
I have doubts regarding the st= atement in Wim?s message ?Aging is done in the same way as VPLS.?

AF= AIK VPLS implementations that learn MCA addresses from traffic typically ma= intain ?usage state? for learned MAC addresses i their data path so that on= ly MAC addresses that have learned once but not seen for a long time are ag= ed out.

To the best of my understanding, in EVPN this would still work for MAC = addresses learned from the local ACs, but not for MAC addresses that have b= een installed via the control plane. Or do I miss something substantial her= e?

Regards,
=A0 =A0 =A0Sasha

Regards,
=A0 =A0 =A0Sasha
From: l2vpn-bounces@ietf.org= [mailto:l2vpn-bounces@ietf.o= rg] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, July 03, 2012 10:11 AM
To: Jakob Heitz; l2vpn@ietf.org
Subject: RE: EVPN: MAC age

Ag= ing is done in the same way as VPLS. You have a local age timer and if it e= xpires the MAC address is withdrawn from the EVPN.

From: l2vpn-bounces@ietf.org<= /a> [mailto:l2vpn-bounces@ietf.or= g] On Behalf Of Jakob Heitz
Sent: dinsdag 3 juli 2012 8:45
To: l2vpn@ietf.org
Subject: EVPN: MAC age

Is there a way to age out a MAC address in EV= PN?
Does the advertising MES just withdraw it when it ages out?
Is th= ere a possibility to add an age to the MAC NLRI?
Or put an age into a BG= P extended community?

--
Jakob Heitz.

--14dae934040b977a1804c3eca30a-- From wim.henderickx@alcatel-lucent.com Tue Jul 3 06:17:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B4C21F8738 for ; Tue, 3 Jul 2012 06:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.615 X-Spam-Level: X-Spam-Status: No, score=-7.615 tagged_above=-999 required=5 tests=[AWL=-2.467, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEUP22ZJaLgc for ; Tue, 3 Jul 2012 06:17:15 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3521F885E for ; Tue, 3 Jul 2012 06:17:14 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q63DH5V6024929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jul 2012 15:17:19 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 3 Jul 2012 15:17:10 +0200 From: "Henderickx, Wim (Wim)" To: "'lizho.jin@gmail.com'" , "'l2vpn@ietf.org'" Date: Tue, 3 Jul 2012 15:17:09 +0200 Subject: Re: EVPN: MAC age Thread-Topic: EVPN: MAC age Thread-Index: Ac1ZHU7ojnMOG2woQWaG3agCD9+taAAANeNN Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: multipart/alternative; boundary="_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9FRMRSSXCHMBSB_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:17:17 -0000 --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9FRMRSSXCHMBSB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIG15IHJlcGx5IHRvIGFsZXguIFRoZSByZW1vdGUgbWFjcyBzaG91bGQgY29udHJvbGxlZCBi eSBiZ3AuIFRoZSBsb2NhbCBtYWMgY2FuIGVpdGhlciBiZSBwcmVyZWdpc3RlcmVkIHZpYSBhIHBy b3RvY29sIG9yIGxlYXJuZWQgaW4gdGhlIGRhdGFwbGFuZS4gRm9yIHByZXJlZ2lzdHJhdGlvbiB0 aGUgcHJvdG9jb2wgc2hvdWxkIHRha2UgY2FyZSBvZiB0aGUgYWdpbmcgd2hpbGUgZm9yIGRhdGFw bGFuZSBsZWFybmluZyBkYXRhcGxhbmUgYWdpbmcgaXMgcmVxdWlyZWQuDQoNCkNoZWVycywNCldp bQ0KX19fX19fX19fX19fX19fX18NCnNlbnQgZnJvbSBibGFja2JlcnJ5DQoNCkZyb206IExpemhv bmcgSmluIFttYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkg MDMsIDIwMTIgMDM6MTAgUE0NClRvOiBsMnZwbkBpZXRmLm9yZyA8bDJ2cG5AaWV0Zi5vcmc+OyBI ZW5kZXJpY2t4LCBXaW0gKFdpbSkNClN1YmplY3Q6IFJlOiBFVlBOOiBNQUMgYWdlDQoNCkhpIFdp bSwNCkkgaGF2ZSBzbGlnaHRseSBkaWZmZXJlbnQgb3BpbmlvbiBhYm91dCB0aGUgYWdpbmcuIElm IHRoZSByZW1vdGUgTUFDIGFkdmVydGlzZWQgYnkgQkdQIGlzIGFnZWQgb3V0IGJ5IHJlY2Vpdmlu ZyBub2RlLCBob3cgdG8gbGVhcm4gdGhlIE1BQyBhZGRyZXNzIGFnYWluPyBXaWxsIHRoZSB1bmtu b3duIHVuaWNhc3QgcGFja2V0IGJlIGJyb2FkY2FzdGVkIGlmIGFnZWQgb3V0Pw0KSW4gbXkgb3Bp bmlvbiwgdGhlIGNvbnRyb2wgcGxhbmUgc2hvdWxkIG1haW50YWluIGFsbCB0aGUgTUFDIGFkZHJl c3MgYWR2ZXJ0aXNlZCBieSBCR1Agd2l0aG91dCBhZ2luZywgYnV0IHRoZSBkYXRhcGxhbmUgY291 bGQgbWFpbnRhaW4gdGhlIGFjdGl2ZSBNQUMgYWRkcmVzcyBvbmx5LiBXaGVuIG5vdCBtYXRjaGlu ZyBmb3IgcGFja2V0IGZvcndhcmRpbmcsIGxvb2t1cCB0aGUgdGFibGUgaW4gY29udHJvbCBwbGFu ZSwgYW5kIGluc3RhbGwgdGhlIGNvcnJlc3BvbmRpbmcgYWN0aXZlIE1BQyBlbnRyeSBpbiBkYXRh cGxhbmUuDQoNCkpha29iJ3MgcXVlc3Rpb24gaXMgdG8gYXNrIGZvciAgYWRkaW5nIGFuIGFnZSB0 aW1lIHRvIHRoZSBNQUMgTkxSSS4gSSBkbyBub3Qgc3VnZ2VzdCB0byBkbyB0aGF0LiBJZiBNQUMg YWRkcmVzcyBpcyBhZ2VkIG91dCwgaG93IHRvIGhhbmRsZSB0aGUgcG90ZW50aWFsIHVua25vdyB1 bmljYXN0IHBhY2tldD8NCg0KTGl6aG9uZw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCk1lc3NhZ2U6IDENCkRhdGU6IFR1ZSwgMyBKdWwgMjAxMiAxMDoyODozOCAr MDIwMA0KRnJvbTogIkhlbmRlcmlja3gsIFdpbSAoV2ltKSIgPHdpbS5oZW5kZXJpY2t4QGFsY2F0 ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPj4N ClRvOiAiJ0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4nIg0KICAgICAgICA8QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4sICAg ICAiJ2pha29iLmhlaXR6QGVyaWNzc29uLmNvbTxtYWlsdG86amFrb2IuaGVpdHpAZXJpY3Nzb24u Y29tPiciDQogICAgICAgIDxqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208bWFpbHRvOmpha29iLmhl aXR6QGVyaWNzc29uLmNvbT4+DQpDYzogIidsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+JyIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSZTogRVZQTjogTUFDIGFnZQ0KTWVzc2FnZS1JRDoNCiAgICAgICAgPDE0QzdGNEYwNkRCNTgx NEFCMERFMjk3MTZDNEY2RDY3MDJERjIxNzFEREBGUk1SU1NYQ0hNQlNCMS5kYy1tLmFsY2F0ZWwt bHVjZW50LmNvbTxtYWlsdG86MTRDN0Y0RjA2REI1ODE0QUIwREUyOTcxNkM0RjZENjcwMkRGMjE3 MUREQEZSTVJTU1hDSE1CU0IxLmRjLW0uYWxjYXRlbC1sdWNlbnQuY29tPj4NCg0KQ29udGVudC1U eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCg0KRm9yIHJlbW90ZSBtYWMgYWRkcmVz c2VzIHlvdSBjYW4gcmVseSBvbiBiZ3Agd2l0aGRyYXdzIG9yIGRvIGFnaW5nIGxvY2FsbHkgYmFz ZWQgb24gYWN0aXZpdHkgb3IgYm90aC4gTm93IGdpdmVuIHRoYXQgeW91IHByb3ZpZGUgbXVsdGkt cGF0aGluZyBpdCBpcyBiZXN0IHRvIHJlbHkgb24gYmdwIHdpdGhkcmF3IGZvciByZW1vdGUgbWFj IGFkZHJlc3NlcyB0byBlbnN1cmUgY29uc2lzdGVuY3kgYWNjcm9zcyBhbGwgbWVzKGVzKS4NCg0K Q2hlZXJzLA0KV2ltDQpfX19fX19fX19fX19fX19fXw0Kc2VudCBmcm9tIGJsYWNrYmVycnkNCg0K RnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+XQ0KU2Vu dDogVHVlc2RheSwgSnVseSAwMywgMjAxMiAxMDoxOSBBTQ0KVG86IEhlbmRlcmlja3gsIFdpbSAo V2ltKTsgSmFrb2IgSGVpdHogPGpha29iLmhlaXR6QGVyaWNzc29uLmNvbTxtYWlsdG86amFrb2Iu aGVpdHpAZXJpY3Nzb24uY29tPj4NCkNjOiBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0 Zi5vcmc+IDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KU3ViamVjdDog UkU6IEVWUE46IE1BQyBhZ2UNCg0KSGkgYWxsLA0KSSBoYXZlIGRvdWJ0cyByZWdhcmRpbmcgdGhl IHN0YXRlbWVudCBpbiBXaW0/cyBtZXNzYWdlID9BZ2luZyBpcyBkb25lIGluIHRoZSBzYW1lIHdh eSBhcyBWUExTLj8NCg0KQUZBSUsgVlBMUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBsZWFybiBNQ0Eg YWRkcmVzc2VzIGZyb20gdHJhZmZpYyB0eXBpY2FsbHkgbWFpbnRhaW4gP3VzYWdlIHN0YXRlPyBm b3IgbGVhcm5lZCBNQUMgYWRkcmVzc2VzIGkgdGhlaXIgZGF0YSBwYXRoIHNvIHRoYXQgb25seSBN QUMgYWRkcmVzc2VzIHRoYXQgaGF2ZSBsZWFybmVkIG9uY2UgYnV0IG5vdCBzZWVuIGZvciBhIGxv bmcgdGltZSBhcmUgYWdlZCBvdXQuDQoNClRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcs IGluIEVWUE4gdGhpcyB3b3VsZCBzdGlsbCB3b3JrIGZvciBNQUMgYWRkcmVzc2VzIGxlYXJuZWQg ZnJvbSB0aGUgbG9jYWwgQUNzLCBidXQgbm90IGZvciBNQUMgYWRkcmVzc2VzIHRoYXQgaGF2ZSBi ZWVuIGluc3RhbGxlZCB2aWEgdGhlIGNvbnRyb2wgcGxhbmUuIE9yIGRvIEkgbWlzcyBzb21ldGhp bmcgc3Vic3RhbnRpYWwgaGVyZT8NCg0KUmVnYXJkcywNCiAgICAgU2FzaGENCg0KDQpSZWdhcmRz LA0KICAgICBTYXNoYQ0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZw bi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSGVuZGVyaWNreCwgV2ltIChX aW0pDQpTZW50OiBUdWVzZGF5LCBKdWx5IDAzLCAyMDEyIDEwOjExIEFNDQpUbzogSmFrb2IgSGVp dHo7IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBF VlBOOiBNQUMgYWdlDQoNCkFnaW5nIGlzIGRvbmUgaW4gdGhlIHNhbWUgd2F5IGFzIFZQTFMuIFlv dSBoYXZlIGEgbG9jYWwgYWdlIHRpbWVyIGFuZCBpZiBpdCBleHBpcmVzIHRoZSBNQUMgYWRkcmVz cyBpcyB3aXRoZHJhd24gZnJvbSB0aGUgRVZQTi4NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsMnZwbi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEph a29iIEhlaXR6DQpTZW50OiBkaW5zZGFnIDMganVsaSAyMDEyIDg6NDUNClRvOiBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBFVlBOOiBNQUMgYWdlDQoNCklz IHRoZXJlIGEgd2F5IHRvIGFnZSBvdXQgYSBNQUMgYWRkcmVzcyBpbiBFVlBOPw0KRG9lcyB0aGUg YWR2ZXJ0aXNpbmcgTUVTIGp1c3Qgd2l0aGRyYXcgaXQgd2hlbiBpdCBhZ2VzIG91dD8NCklzIHRo ZXJlIGEgcG9zc2liaWxpdHkgdG8gYWRkIGFuIGFnZSB0byB0aGUgTUFDIE5MUkk/DQpPciBwdXQg YW4gYWdlIGludG8gYSBCR1AgZXh0ZW5kZWQgY29tbXVuaXR5Pw0KDQotLQ0KSmFrb2IgSGVpdHou DQoNCg== --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9FRMRSSXCHMBSB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KU2VlIG15IHJlcGx5 IHRvIGFsZXguIFRoZSByZW1vdGUgbWFjcyBzaG91bGQgY29udHJvbGxlZCBieSBiZ3AuIFRoZSBs b2NhbCBtYWMgY2FuIGVpdGhlciBiZSBwcmVyZWdpc3RlcmVkIHZpYSBhIHByb3RvY29sIG9yIGxl YXJuZWQgaW4gdGhlIGRhdGFwbGFuZS4gRm9yIHByZXJlZ2lzdHJhdGlvbiB0aGUgcHJvdG9jb2wg c2hvdWxkIHRha2UgY2FyZSBvZiB0aGUgYWdpbmcgd2hpbGUgZm9yIGRhdGFwbGFuZSBsZWFybmlu ZyBkYXRhcGxhbmUgYWdpbmcgaXMgcmVxdWlyZWQuDTxicj4NPGJyPkNoZWVycywNPGJyPldpbQ08 YnI+X19fX19fX19fX19fX19fX18NPGJyPnNlbnQgZnJvbSBibGFja2JlcnJ5PC9mb250Pjxicj4m bmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQo8Yj5Gcm9tPC9iPjogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpoby5qaW5AZ21h aWwuY29tXQ08YnI+PGI+U2VudDwvYj46IFR1ZXNkYXksIEp1bHkgMDMsIDIwMTIgMDM6MTAgUE08 YnI+PGI+VG88L2I+OiBsMnZwbkBpZXRmLm9yZyAmbHQ7bDJ2cG5AaWV0Zi5vcmcmZ3Q7OyBIZW5k ZXJpY2t4LCBXaW0gKFdpbSkNPGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogRVZQTjogTUFDIGFnZQ08 YnI+PC9mb250PiZuYnNwOzxicj48L2Rpdj4NCjxkaXY+SGkgV2ltLDwvZGl2Pg0KPGRpdj5JIGhh dmUgc2xpZ2h0bHkgZGlmZmVyZW50IG9waW5pb24gYWJvdXQgdGhlIGFnaW5nLiBJZiB0aGUgcmVt b3RlwqBNQUMgYWR2ZXJ0aXNlZCBieSBCR1AgaXMgYWdlZCBvdXQgYnkgcmVjZWl2aW5nIG5vZGUs IGhvdyB0byBsZWFybiB0aGUgTUFDIGFkZHJlc3MgYWdhaW4/IFdpbGwgdGhlIHVua25vd24gdW5p Y2FzdCBwYWNrZXQgYmUgYnJvYWRjYXN0ZWQgaWYgYWdlZCBvdXQ/PC9kaXY+DQoNCjxkaXY+SW4g bXkgb3BpbmlvbiwgdGhlIGNvbnRyb2wgcGxhbmUgc2hvdWxkIG1haW50YWluIGFsbCB0aGUgTUFD IGFkZHJlc3MgYWR2ZXJ0aXNlZCBieSBCR1Agd2l0aG91dCBhZ2luZywgYnV0IHRoZSBkYXRhcGxh bmUgY291bGQgbWFpbnRhaW4gdGhlIGFjdGl2ZSBNQUMgYWRkcmVzcyBvbmx5LiBXaGVuIG5vdCBt YXRjaGluZyBmb3IgcGFja2V0IGZvcndhcmRpbmcsIGxvb2t1cCB0aGUgdGFibGUgaW4gY29udHJv bCBwbGFuZSwgYW5kIGluc3RhbGwgdGhlIGNvcnJlc3BvbmRpbmcgYWN0aXZlIE1BQyBlbnRyeSBp biBkYXRhcGxhbmUuPC9kaXY+DQoNCjxkaXY+wqA8L2Rpdj4NCjxkaXY+SmFrb2ImIzM5O3MgcXVl c3Rpb24gaXMgdG8gYXNrIGZvcsKgIGFkZGluZyBhbiBhZ2UgdGltZcKgdG8gdGhlIE1BQyBOTFJJ LiBJIGRvIG5vdCBzdWdnZXN0IHRvIGRvIHRoYXQuIElmIE1BQyBhZGRyZXNzwqBpcyBhZ2VkIG91 dCwgaG93IHRvIGhhbmRsZSB0aGUgcG90ZW50aWFswqB1bmtub3cgdW5pY2FzdCBwYWNrZXQ/PC9k aXY+DQo8ZGl2PsKgPC9kaXY+DQo8ZGl2Pkxpemhvbmc8L2Rpdj4NCjxkaXY+PGJyPsKgPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxF RlQ6I2NjYyAxcHggc29saWQ7TUFSR0lOOjBweCAwcHggMHB4IDAuOGV4O1BBRERJTkctTEVGVDox ZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj5NZXNzYWdlOiAxPGJyPkRhdGU6IFR1ZSwgMyBKdWwgMjAxMiAxMDoyODozOCArMDIw MDxicj5Gcm9tOiAmcXVvdDtIZW5kZXJpY2t4LCBXaW0gKFdpbSkmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20iPndpbS5oZW5kZXJpY2t4 QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7PGJyPg0KVG86ICZxdW90OyYjMzk7PGEgaHJlZj0i bWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbTwvYT4mIzM5OyZxdW90Ozxicj7CoCDCoCDCoCDCoCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tIj5BbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7LCDCoCDCoCAmcXVvdDsmIzM5OzxhIGhyZWY9Im1h aWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb20iPmpha29iLmhlaXR6QGVyaWNzc29uLmNvbTwv YT4mIzM5OyZxdW90Ozxicj4NCsKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86amFrb2Iu aGVpdHpAZXJpY3Nzb24uY29tIj5qYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj5D YzogJnF1b3Q7JiMzOTs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYu b3JnPC9hPiYjMzk7JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwy dnBuQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogRVZQTjogTUFDIGFnZTxicj5N ZXNzYWdlLUlEOjxicj7CoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOjE0QzdGNEYwNkRC NTgxNEFCMERFMjk3MTZDNEY2RDY3MDJERjIxNzFEREBGUk1SU1NYQ0hNQlNCMS5kYy1tLmFsY2F0 ZWwtbHVjZW50LmNvbSI+MTRDN0Y0RjA2REI1ODE0QUIwREUyOTcxNkM0RjZENjcwMkRGMjE3MURE QEZSTVJTU1hDSE1CU0IxLmRjLW0uYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs8YnI+DQo8YnI+ Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSZxdW90O3V0Zi04JnF1b3Q7PGJyPjxi cj5Gb3IgcmVtb3RlIG1hYyBhZGRyZXNzZXMgeW91IGNhbiByZWx5IG9uIGJncCB3aXRoZHJhd3Mg b3IgZG8gYWdpbmcgbG9jYWxseSBiYXNlZCBvbiBhY3Rpdml0eSBvciBib3RoLiBOb3cgZ2l2ZW4g dGhhdCB5b3UgcHJvdmlkZSBtdWx0aS1wYXRoaW5nIGl0IGlzIGJlc3QgdG8gcmVseSBvbiBiZ3Ag d2l0aGRyYXcgZm9yIHJlbW90ZSBtYWMgYWRkcmVzc2VzIHRvIGVuc3VyZSBjb25zaXN0ZW5jeSBh Y2Nyb3NzIGFsbCBtZXMoZXMpLjxicj4NCjxicj5DaGVlcnMsPGJyPldpbTxicj5fX19fX19fX19f X19fX19fXzxicj5zZW50IGZyb20gYmxhY2tiZXJyeTxicj48YnI+RnJvbTogQWxleGFuZGVyIFZh aW5zaHRlaW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNp dGVsZS5jb20iPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPl08YnI+U2VudDog VHVlc2RheSwgSnVseSAwMywgMjAxMiAxMDoxOSBBTTxicj4NClRvOiBIZW5kZXJpY2t4LCBXaW0g KFdpbSk7IEpha29iIEhlaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86amFrb2IuaGVpdHpAZXJpY3Nz b24uY29tIj5qYWtvYi5oZWl0ekBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj5DYzogPGEgaHJlZj0i bWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1h aWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6 IFJFOiBFVlBOOiBNQUMgYWdlPGJyPjxicj5IaSBhbGwsPGJyPkkgaGF2ZSBkb3VidHMgcmVnYXJk aW5nIHRoZSBzdGF0ZW1lbnQgaW4gV2ltP3MgbWVzc2FnZSA/QWdpbmcgaXMgZG9uZSBpbiB0aGUg c2FtZSB3YXkgYXMgVlBMUy4/PGJyPjxicj5BRkFJSyBWUExTIGltcGxlbWVudGF0aW9ucyB0aGF0 IGxlYXJuIE1DQSBhZGRyZXNzZXMgZnJvbSB0cmFmZmljIHR5cGljYWxseSBtYWludGFpbiA/dXNh Z2Ugc3RhdGU/IGZvciBsZWFybmVkIE1BQyBhZGRyZXNzZXMgaSB0aGVpciBkYXRhIHBhdGggc28g dGhhdCBvbmx5IE1BQyBhZGRyZXNzZXMgdGhhdCBoYXZlIGxlYXJuZWQgb25jZSBidXQgbm90IHNl ZW4gZm9yIGEgbG9uZyB0aW1lIGFyZSBhZ2VkIG91dC48YnI+DQo8YnI+VG8gdGhlIGJlc3Qgb2Yg bXkgdW5kZXJzdGFuZGluZywgaW4gRVZQTiB0aGlzIHdvdWxkIHN0aWxsIHdvcmsgZm9yIE1BQyBh ZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoZSBsb2NhbCBBQ3MsIGJ1dCBub3QgZm9yIE1BQyBhZGRy ZXNzZXMgdGhhdCBoYXZlIGJlZW4gaW5zdGFsbGVkIHZpYSB0aGUgY29udHJvbCBwbGFuZS4gT3Ig ZG8gSSBtaXNzIHNvbWV0aGluZyBzdWJzdGFudGlhbCBoZXJlPzxicj4NCjxicj5SZWdhcmRzLDxi cj7CoCDCoCDCoFNhc2hhPGJyPjxicj48YnI+UmVnYXJkcyw8YnI+wqAgwqAgwqBTYXNoYTxicj48 YnI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSGVuZGVy aWNreCwgV2ltIChXaW0pPGJyPg0KU2VudDogVHVlc2RheSwgSnVseSAwMywgMjAxMiAxMDoxMSBB TTxicj5UbzogSmFrb2IgSGVpdHo7IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2 cG5AaWV0Zi5vcmc8L2E+PGJyPlN1YmplY3Q6IFJFOiBFVlBOOiBNQUMgYWdlPGJyPjxicj5BZ2lu ZyBpcyBkb25lIGluIHRoZSBzYW1lIHdheSBhcyBWUExTLiBZb3UgaGF2ZSBhIGxvY2FsIGFnZSB0 aW1lciBhbmQgaWYgaXQgZXhwaXJlcyB0aGUgTUFDIGFkZHJlc3MgaXMgd2l0aGRyYXduIGZyb20g dGhlIEVWUE4uPGJyPg0KPGJyPkZyb206IDxhIGhyZWY9Im1haWx0bzpsMnZwbi1ib3VuY2VzQGll dGYub3JnIj5sMnZwbi1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnIj5sMnZwbi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIEpha29iIEhlaXR6PGJyPlNlbnQ6IGRpbnNkYWcgMyBqdWxpIDIwMTIgODo0NTxi cj5UbzogPGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBFVlBOOiBNQUMgYWdlPGJyPjxicj5JcyB0aGVyZSBhIHdheSB0byBhZ2Ug b3V0IGEgTUFDIGFkZHJlc3MgaW4gRVZQTj88YnI+RG9lcyB0aGUgYWR2ZXJ0aXNpbmcgTUVTIGp1 c3Qgd2l0aGRyYXcgaXQgd2hlbiBpdCBhZ2VzIG91dD88YnI+SXMgdGhlcmUgYSBwb3NzaWJpbGl0 eSB0byBhZGQgYW4gYWdlIHRvIHRoZSBNQUMgTkxSST88YnI+T3IgcHV0IGFuIGFnZSBpbnRvIGEg QkdQIGV4dGVuZGVkIGNvbW11bml0eT88YnI+DQo8YnI+LS08YnI+SmFrb2IgSGVpdHouPGJyPjxi cj48L2Jsb2NrcXVvdGU+PC9kaXY+DQo= --_000_14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9FRMRSSXCHMBSB_-- From lizho.jin@gmail.com Tue Jul 3 06:40:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373D21F869F for ; Tue, 3 Jul 2012 06:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4Txmely18QF for ; Tue, 3 Jul 2012 06:40:13 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3FD821F87C9 for ; Tue, 3 Jul 2012 06:40:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5859561ghb.31 for ; Tue, 03 Jul 2012 06:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lOnIX7sNioieoc490yxCGZAmPA+/VlerFHnc9rh0YfM=; b=EPaF0s7Rg+j4z4JL3pU0TmMGgl3VmBwdKha0OLloMLBMzYxlhCtdSFhhWmmIUTSJwq 9IQ3xEE36Rj5zYTddc52HsrM3f9p9ffbfMVF8gIcJowFJKORH32PtjXCrd/doGxEQFw5 whOuQkVLJX9IekiBc9CzYaNxemi6xi99NJX0n8ExsqbF3uEhS/c27iRdrOG3EMz3nlxi 3nALd56ixQPNrf/2xH+1IjpxkElqRdl6nRAiUvQ9+qMpKhrC+ePyqgWk9SY1WDWN924v s1sJ4odadyoZWZ5ra09K+TF1tggVosB5a+OCfBeKW/Fos6IznYM1El16hK1POeYegY/L kwlg== MIME-Version: 1.0 Received: by 10.50.189.135 with SMTP id gi7mr8130401igc.8.1341322816777; Tue, 03 Jul 2012 06:40:16 -0700 (PDT) Received: by 10.50.106.198 with HTTP; Tue, 3 Jul 2012 06:40:16 -0700 (PDT) In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Tue, 3 Jul 2012 21:40:16 +0800 Message-ID: Subject: Re: EVPN: MAC age From: Lizhong Jin To: "Henderickx, Wim (Wim)" Content-Type: multipart/alternative; boundary=14dae934040b05ed8d04c3ed0ecf Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 13:40:17 -0000 --14dae934040b05ed8d04c3ed0ecf Content-Type: text/plain; charset=ISO-8859-1 Agree with the below statement now. Thanks Lizhong On Tue, Jul 3, 2012 at 9:17 PM, Henderickx, Wim (Wim) < wim.henderickx@alcatel-lucent.com> wrote: > See my reply to alex. The remote macs should controlled by bgp. The local > mac can either be preregistered via a protocol or learned in the dataplane. > For preregistration the protocol should take care of the aging while for > dataplane learning dataplane aging is required. > > Cheers, > Wim > _________________ > sent from blackberry > > > *From*: Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent*: Tuesday, July 03, 2012 03:10 PM > *To*: l2vpn@ietf.org ; Henderickx, Wim (Wim) > *Subject*: Re: EVPN: MAC age > > Hi Wim, > I have slightly different opinion about the aging. If the remote MAC > advertised by BGP is aged out by receiving node, how to learn the MAC > address again? Will the unknown unicast packet be broadcasted if aged out? > In my opinion, the control plane should maintain all the MAC address > advertised by BGP without aging, but the dataplane could maintain the > active MAC address only. When not matching for packet forwarding, lookup > the table in control plane, and install the corresponding active MAC entry > in dataplane. > > Jakob's question is to ask for adding an age time to the MAC NLRI. I do > not suggest to do that. If MAC address is aged out, how to handle the > potential unknow unicast packet? > > Lizhong > > > >> ------------------------------------- >> Message: 1 >> Date: Tue, 3 Jul 2012 10:28:38 +0200 >> From: "Henderickx, Wim (Wim)" >> To: "'Alexander.Vainshtein@ecitele.com'" >> , "' >> jakob.heitz@ericsson.com'" >> >> Cc: "'l2vpn@ietf.org'" >> Subject: Re: EVPN: MAC age >> Message-ID: >> < >> 14C7F4F06DB5814AB0DE29716C4F6D6702DF2171DD@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com >> > >> >> Content-Type: text/plain; charset="utf-8" >> >> For remote mac addresses you can rely on bgp withdraws or do aging >> locally based on activity or both. Now given that you provide multi-pathing >> it is best to rely on bgp withdraw for remote mac addresses to ensure >> consistency accross all mes(es). >> >> Cheers, >> Wim >> _________________ >> sent from blackberry >> >> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] >> Sent: Tuesday, July 03, 2012 10:19 AM >> To: Henderickx, Wim (Wim); Jakob Heitz >> Cc: l2vpn@ietf.org >> Subject: RE: EVPN: MAC age >> >> Hi all, >> I have doubts regarding the statement in Wim?s message ?Aging is done in >> the same way as VPLS.? >> >> AFAIK VPLS implementations that learn MCA addresses from traffic >> typically maintain ?usage state? for learned MAC addresses i their data >> path so that only MAC addresses that have learned once but not seen for a >> long time are aged out. >> >> To the best of my understanding, in EVPN this would still work for MAC >> addresses learned from the local ACs, but not for MAC addresses that have >> been installed via the control plane. Or do I miss something substantial >> here? >> >> Regards, >> Sasha >> >> >> Regards, >> Sasha >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Henderickx, Wim (Wim) >> Sent: Tuesday, July 03, 2012 10:11 AM >> To: Jakob Heitz; l2vpn@ietf.org >> Subject: RE: EVPN: MAC age >> >> Aging is done in the same way as VPLS. You have a local age timer and if >> it expires the MAC address is withdrawn from the EVPN. >> >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Jakob Heitz >> Sent: dinsdag 3 juli 2012 8:45 >> To: l2vpn@ietf.org >> Subject: EVPN: MAC age >> >> Is there a way to age out a MAC address in EVPN? >> Does the advertising MES just withdraw it when it ages out? >> Is there a possibility to add an age to the MAC NLRI? >> Or put an age into a BGP extended community? >> >> -- >> Jakob Heitz. >> >> --14dae934040b05ed8d04c3ed0ecf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with the below statement now.

=A0

Thanks

Lizhong

On Tue, Jul 3, 2012 at 9:17 PM, Henderickx, Wim = (Wim) <wim.henderickx@alcatel-lucent.com> wr= ote:

See my reply to = alex. The remote macs should controlled by bgp. The local mac can either be= preregistered via a protocol or learned in the dataplane. For preregistrat= ion the protocol should take care of the aging while for dataplane learning= dataplane aging is required.

Cheers,
Wim
_________________
sent from b= lackberry

=A0

From: Lizhong Jin [mail= to:lizho.jin@gmail= .com]
Sent: Tuesday, July 03, 2012 03:10 PM
To: l2vpn@ietf.org <l2vpn@ietf.org>; Henderickx, Wim= (Wim)

Subject: Re: EVPN: MAC age
= =A0

Hi Wim,

I have slightly different opinion about the aging. If the remote=A0MAC= advertised by BGP is aged out by receiving node, how to learn the MAC addr= ess again? Will the unknown unicast packet be broadcasted if aged out?
In my opinion, the control plane should maintain all the MAC address a= dvertised by BGP without aging, but the dataplane could maintain the active= MAC address only. When not matching for packet forwarding, lookup the tabl= e in control plane, and install the corresponding active MAC entry in datap= lane.

=A0

Jakob's question is to ask for=A0 adding an age time=A0to the MAC = NLRI. I do not suggest to do that. If MAC address=A0is aged out, how to han= dle the potential=A0unknow unicast packet?

=A0

Lizhong

=A0

-------------------------------------=
Message: 1
Date: Tue, 3 Jul 2012 10:28:38 +0200
From: "Hende= rickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "'Alexander.Vainshtein@ecitele.com'"
=A0 =A0 =A0 = =A0 <Alexander.Vainshtein@ecitele.com>, =A0 =A0 "'jakob.heitz@ericsson.com= '"
=A0 =A0 =A0 =A0 <jakob.heitz@ericsson.com>
Cc: "'l2vpn@ietf.org'" <l2vpn@ietf.org>
Subject: Re: EVPN: MAC age
Message-ID:
=A0 =A0 =A0 =A0 <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171D= D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>

Content-Type: text/plain; charset=3D"utf-8"

For remote= mac addresses you can rely on bgp withdraws or do aging locally based on a= ctivity or both. Now given that you provide multi-pathing it is best to rel= y on bgp withdraw for remote mac addresses to ensure consistency accross al= l mes(es).

Cheers,
Wim
_________________
sent from blackberry

From= : Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Tu= esday, July 03, 2012 10:19 AM
To: Henderickx, Wim (Wim); Jakob Heitz <jakob.heitz@ericsson.com>
Cc: l2vpn@ietf.org <l2vpn@ietf.org>
Subject: RE: EVPN: MAC age

Hi all,
I have doubts regarding the st= atement in Wim?s message ?Aging is done in the same way as VPLS.?

AF= AIK VPLS implementations that learn MCA addresses from traffic typically ma= intain ?usage state? for learned MAC addresses i their data path so that on= ly MAC addresses that have learned once but not seen for a long time are ag= ed out.

To the best of my understanding, in EVPN this would still work for MAC = addresses learned from the local ACs, but not for MAC addresses that have b= een installed via the control plane. Or do I miss something substantial her= e?

Regards,
=A0 =A0 =A0Sasha

Regards,
=A0 =A0 =A0Sasha
From: l2vp= n-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Henderickx, Wim (W= im)
Sent: Tuesday, July 03, 2012 10:11 AM
To: Jakob Heitz; l2vpn@ietf.org
Subject: RE: EVPN:= MAC age

Aging is done in the same way as VPLS. You have a local age= timer and if it expires the MAC address is withdrawn from the EVPN.

From: l2vpn= -bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent= : dinsdag 3 juli 2012 8:45
To: l2vpn@ietf.org<= br>Subject: EVPN: MAC age

Is there a way to age out a MAC address in= EVPN?
Does the advertising MES just withdraw it when it ages out?
Is= there a possibility to add an age to the MAC NLRI?
Or put an age into a BGP extended community?

--
Jakob Heitz.
<= br>

--14dae934040b05ed8d04c3ed0ecf-- From nabil.n.bitar@verizon.com Tue Jul 3 13:37:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7821F86C3 for ; Tue, 3 Jul 2012 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7L-+aYg7Ueb for ; Tue, 3 Jul 2012 13:37:38 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6421F87DC for ; Tue, 3 Jul 2012 13:37:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 03 Jul 2012 20:37:45 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.77,517,1336348800"; d="scan'208,217";a="293210962" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi02.verizon.com with ESMTP; 03 Jul 2012 20:37:44 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Tue, 3 Jul 2012 16:37:44 -0400 To: "l2vpn@ietf.org" Date: Tue, 3 Jul 2012 16:37:49 -0400 Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 84 - Vancouver Thread-Topic: [l2vpn] L2VPN Agenda Slot Call for IETF 84 - Vancouver Thread-Index: Ac1ZW7LqXlP+j6cwRAu7cIshwYHTug== 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.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC18CF15345D5nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 20:37:38 -0000 --_000_CC18CF15345D5nabilnbitarverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi L2VPN WG. Please let us know if you have a time-slot request for the L2VPN session at= IETF 84=96Vancouver. Please, email us your request by Sunday July 15, 201= 2 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Additional key dates to remember are: 2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PT (UTC -7) 2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT (U= TC -7) Thanks, Nabil and Giles --_000_CC18CF15345D5nabilnbitarverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi L2VPN WG.
<= span id=3D"OLK_SRC_BODY_SECTION">
Please let us know if you have a time-slot request for the L2VPN session at= IETF 84=96Vancouver. Please, email us your request by Sunday July 15= , 2012 along with the following information:
1) Draft title
2) Presenter name
3) Requested duration

Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter.

Additional key dates to remember are:
2012= -07-09 (Monday): Internet Draft Cut-off for initial document (-00)= submission by 17:00 PT (UTC -7)

2012-07-16 (Monday): Internet Draft fi= nal submission cut-off by 17:00 PT (UTC -7)
<= div style=3D"color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sa= ns-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-bre= ak: after-white-space; ">

Thanks,
Nabil and Giles
=
--_000_CC18CF15345D5nabilnbitarverizoncom_-- From ietf-ipr@ietf.org Fri Jul 6 10:10:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7777721F87BE; Fri, 6 Jul 2012 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 YgenNXlqFvSo; Fri, 6 Jul 2012 10:10:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5430721F8667; Fri, 6 Jul 2012 10:10:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bhupesh@cisco.com, kireeti@juniper.net, wim.henderickx@alcatel-lucent.be, florin.balus@alcatel-lucent.com, uttaro@att.com Subject: IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-vpls-multihoming-03 X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706171034.32068.47743.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:10:34 -0700 X-Mailman-Approved-At: Fri, 06 Jul 2012 10:13:07 -0700 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:10:39 -0000 Dear Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, James= Uttaro: An IPR disclosure that pertains to your Internet-Draft entitled "BGP based Multi-homing in Virtual Private LAN Service" (draft-ietf-l2vpn-vpls-multiho= ming) was submitted to the IETF Secretariat on 2012-07-05 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1809/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-vpls- multihoming-03.""); The IETF Secretariat From robert@raszuk.net Sat Jul 7 05:39:39 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F3021F860F for ; Sat, 7 Jul 2012 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 uueI4kSQuF9w for ; Sat, 7 Jul 2012 05:39:38 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 877CE21F8596 for ; Sat, 7 Jul 2012 05:39:38 -0700 (PDT) Received: (qmail 2593 invoked by uid 399); 7 Jul 2012 12:39:57 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.236.50) by mail1310.opentransfer.com with ESMTPM; 7 Jul 2012 12:39:57 -0000 X-Originating-IP: 83.31.236.50 Message-ID: <4FF82E1C.6000009@raszuk.net> Date: Sat, 07 Jul 2012 14:39:56 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "l2vpn@ietf.org" Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 12:39:39 -0000 I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. It proposed an interesting solution to apply algorithmically computed VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as option C is used. However I have a fundamental question .. from who the draft is protecting the inter-as service ? Who other then participating ISPs can spoof a value of VPN label ? If the solution is protecting from ISPs itself then I think it does not help at all as corresponding ISPs/SPs still have full access to their PEs and could inject packets to VPN sites at will. Moreover main issue with option C is not security (at least for the last 10+ years). Main issue with option C and MPLS is that participating providers need to inject into each other's network all of their participating PE's /32 addresses so the end to end MPLS LSP can be build. Originally that was recommended to be done by mutual redistribution to the IGP .. now the general recommendation is to use labeled BGP (both IBGP and EBGP). So fundamental question to the authors ... who is the potential attacker/spoofer this draft is aiming to protect from ? Best regards, R. From balajivenkat299@gmail.com Sat Jul 7 22:25:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB121F867B for ; Sat, 7 Jul 2012 22:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zhIqNx+CkMF for ; Sat, 7 Jul 2012 22:25:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8D3021F8679 for ; Sat, 7 Jul 2012 22:25:53 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so17606996pbc.31 for ; Sat, 07 Jul 2012 22:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=Vqg58J9H1P+KgPDxofMtzlt6i8R/+0Olqj6WTaFio98=; b=lkfA39A+cUhwWCUSg938Y+PBJopXMQA5P77Eq1Ly3kQRyTSVA2v8tx6p/HYTyCyy/Z F6ukyemwMalV/PJAovNY7JvfBx7eCgBaftBejYVS1c4l5NEXTKYIfoSUYWo/6Aicoqjr BPDzVnAUl7GHaP6TyRl7nsVSc9kUwRjgyO53bbGmpo44Q8n6KcaqhyXPa3SB98xn7boQ O70vMheCtL6GRJEmlKgDFKMI17sztdHwD4P8YrsLWdtvANNo6cc35dkwHz8yBYM9n+D9 oqydO8N/cqmEnBLmqLEx/gf2Gi9A7QSVqtF/5WXtRzgDm4Wbx2iRv3mjEYWo+QkIffY0 6r+g== Received: by 10.68.191.201 with SMTP id ha9mr49778196pbc.75.1341725174360; Sat, 07 Jul 2012 22:26:14 -0700 (PDT) Received: from [192.168.15.105] ([122.174.19.64]) by mx.google.com with ESMTPS id iu6sm25109048pbc.35.2012.07.07.22.26.11 (version=SSLv3 cipher=OTHER); Sat, 07 Jul 2012 22:26:13 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 08 Jul 2012 10:56:07 +0530 Subject: Re: L2vpn Digest, Vol 98, Issue 6 From: balaji venkat Venkataswami To: , "robert@raszuk.net" Message-ID: Thread-Topic: L2vpn Digest, Vol 98, Issue 6 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Shankar Raman M J X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 05:25:55 -0000 Dear Robert, This scheme is primarily to protect against attacks from within a network That intervenes the two providers that are participating in inter-provider Model C. While it is agreed that if the ISP itself sends packets then the whole situation Cannot be recovered from, we intend to use this scheme in places where the Intervening network between the two providers is compromised. Also if one or more Routers of the ISP have been compromised within the ISP's network then an intruder Trying to gain access to the VPN traffic would have a hard time guessing which Traffic belongs to which VPN with our scheme. We have added more data on why We think Model C has a bad protection with respect to its data plane. By increasing the label space to 40 bits the scheme we propose increases Guessing the right labels for the right VPNs to non-polynomial time. Also the following recommendation is usually advised for Model C. Never connect ASBRs over a shared Layer 2 infrastructure such as an Internet Exchange Point (IXP). Use a private connection, or at least a private VLAN. With our scheme this can be relaxed to a degree is what we feel. More on Data Plane insecurity in Model C : ========================================== The security of model C is considerably more open than in models A and B. On the data plane, the traffic exchanged between the ASBRs contains two labels: * VPN label? Is set by the ingress PE to identify the VPN * PE label? Specifies the LSP to the egress PE Model C is considerably more open in terms of security than the previous models, for the following reasons: * To be able to establish end-to-end LSPs, the service provider must be able to reach all PEs of the other AS, which hold connections of shared VPNs. This can be a considerable number of PEs, exposing important parts of the normally internal infrastructure of an AS to the other AS. This also means that considerations that are usually local to an AS in terms of addressing need to be coordinated with the other AS. It also means that traffic can be sent to a number of internal addresses from the outside, making possible attacks from the outside. The recommendation is to filter IP packets into the core as tightly as possible to prevent these issues. Labeled packets cannot be filtered currently. * The ASBR does not hold any VPN information. This is a scalability advantage, but at the same time it prevents the ASBR from checking the VPN label for its validity. This means that it is impossible to verify the VPN label in the data path. (In model B, the ASBR holds this information and can therefore validate the VPN label.) The egress PE cannot verify the packet anymore because at this point the origin of the packet can no longer be determined. Considering these reasons, a potential attack could be AS 1 sending labeled traffic into AS 2, where the top label represents the label to a valid egress PE in AS 2. AS 1 holds PE labels for all those PEs in AS 2, on which it has shared VPNs. However, because the VPN label cannot be checked by the ASBR, AS 1 could send packets with random VPN labels into AS 2 without AS 2 having a way to block this. AS 1 has an LSP to the egress PE in AS 2. This PE has two VPNs configured: VPN A, which is shared with AS 1, and VPN B, which is not shared with AS 1. By sending the packet with a VPN label for VPN B, the packet will be forwarded into VPN B. At the time of writing this draft there was no solution to this issue. First of all, AS 1 would need to know the VPN label for VPN B. The MPLS VPN network does not expose the label externally, so there are two ways of getting it: by espionage, or simply by trying the entire label space. A label has 20 bits, yielding 220 = 1,048,576 potential label values. Assuming a single packet attack with a 500-byte packet size, in the worst case an attacker would need to send 524 MB, which would take approximately 7 minutes on a 10 Mbps link, and 9 hours on a 128 k link. Note that in practice this number would be statistically smaller, and also, label numbering is not random, so intelligent guessing could reduce this number significantly. Then, a malicious user in AS 1 could only send traffic into the VPN, but not receive a reply. However, there are a large number of examples in the history of security where a single unidirectional packet was enough to propagate a worm, for example. So while this limits the scope of an attack, it does not rule it out. In any case, the potential attacker would not receive feedback as to whether the attack was successful. Therefore, it is not easy to carry out a sophisticated attack against a VPN from a given AS. But a single-packet unidirectional attack, as frequently used in the propagation of worms, is possible, even though statistically unlikely. Thanks and regards, Balaji and shankar On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" wrote: >If you have received this digest without all the individual message >attachments you will need to update your digest options in your list >subscription. To do so, go to > >https://www.ietf.org/mailman/listinfo/l2vpn > >Click the 'Unsubscribe or edit options' button, log in, and set "Get >MIME or Plain Text Digests?" to MIME. You can set this option >globally for all the list digests you receive at this point. > > > >Send L2vpn mailing list submissions to > l2vpn@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/l2vpn >or, via email, send a message with subject or body 'help' to > l2vpn-request@ietf.org > >You can reach the person managing the list at > l2vpn-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of L2vpn digest..." > > >Today's Topics: > > 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... > (Robert Raszuk) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 07 Jul 2012 14:39:56 +0200 >From: Robert Raszuk >To: "l2vpn@ietf.org" >Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >Message-ID: <4FF82E1C.6000009@raszuk.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. > >It proposed an interesting solution to apply algorithmically computed >VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >option C is used. > >However I have a fundamental question .. from who the draft is >protecting the inter-as service ? > >Who other then participating ISPs can spoof a value of VPN label ? If >the solution is protecting from ISPs itself then I think it does not >help at all as corresponding ISPs/SPs still have full access to their >PEs and could inject packets to VPN sites at will. > >Moreover main issue with option C is not security (at least for the last >10+ years). Main issue with option C and MPLS is that participating >providers need to inject into each other's network all of their >participating PE's /32 addresses so the end to end MPLS LSP can be >build. Originally that was recommended to be done by mutual >redistribution to the IGP .. now the general recommendation is to use >labeled BGP (both IBGP and EBGP). > >So fundamental question to the authors ... who is the potential >attacker/spoofer this draft is aiming to protect from ? > >Best regards, >R. > > > > > >------------------------------ > >_______________________________________________ >L2vpn mailing list >L2vpn@ietf.org >https://www.ietf.org/mailman/listinfo/l2vpn > > >End of L2vpn Digest, Vol 98, Issue 6 >************************************ From balajivenkat299@gmail.com Sat Jul 7 23:46:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F40121F8780 for ; Sat, 7 Jul 2012 23:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+hv+wdCDlc5 for ; Sat, 7 Jul 2012 23:46:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B510F21F877F for ; Sat, 7 Jul 2012 23:46:44 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so17685797pbc.31 for ; Sat, 07 Jul 2012 23:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=ONf37ar3S/gnxxDGsNdLcllHI6H7MGo5J8O/dzmAuZE=; b=bpVywwQLTjSAPGxMdHDq7tNsXohmVXEZAqpdgXO0b57FYWs+apg+ET2+7hNb8W/9IC QitIfuvbwzui1J2rLixRMbMhFIIUckxLQLjWI+m5nKnnV2zchP0n6XECfguZxW+QzpHF qD22wdvBzs/TI0xNldxENwojfnsEzQ5TWnUQfX7j74zS9FD0jQMTbKerUTXjuXRfn+A4 N431xK4sHJtXJLaKlXvZ/Sm2fY01miZ0iAkLaeE1TubmFpuLWcZ1GWdksQgONAqLrjwv VpolPeCXg1cREYVAfjZT1U7bJjs/BpLdulnQh0fYqmSp0OvdK0tmaIv2lMxX2L/kw9F7 Djkg== Received: by 10.68.238.232 with SMTP id vn8mr16365697pbc.78.1341730025847; Sat, 07 Jul 2012 23:47:05 -0700 (PDT) Received: from [192.168.15.105] ([122.174.11.144]) by mx.google.com with ESMTPS id sy3sm25226432pbc.18.2012.07.07.23.47.02 (version=SSLv3 cipher=OTHER); Sat, 07 Jul 2012 23:47:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 08 Jul 2012 12:16:58 +0530 Subject: Re: L2vpn Digest, Vol 98, Issue 6 From: balaji venkat Venkataswami To: , "robert@raszuk.net" Message-ID: Thread-Topic: L2vpn Digest, Vol 98, Issue 6 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 06:46:46 -0000 Dear Robert, As mentioned in the earlier mail the following restriction is imposed on the Model C deployment=8A The consequence of this is that in model C the service providers must trust each other also in areas that are not shared. Therefore, model C is most commonly used today where a single operator uses several ASs on the backbone. In this case, implicit trust exists between the ASs because they have the same operational control. In order to stretch this scheme to other Ases under different admin control this scheme helps out. Thanks and regards, Balaji venkat On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" wrote: >If you have received this digest without all the individual message >attachments you will need to update your digest options in your list >subscription. To do so, go to > >https://www.ietf.org/mailman/listinfo/l2vpn > >Click the 'Unsubscribe or edit options' button, log in, and set "Get >MIME or Plain Text Digests?" to MIME. You can set this option >globally for all the list digests you receive at this point. > > > >Send L2vpn mailing list submissions to > l2vpn@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/l2vpn >or, via email, send a message with subject or body 'help' to > l2vpn-request@ietf.org > >You can reach the person managing the list at > l2vpn-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of L2vpn digest..." > > >Today's Topics: > > 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... > (Robert Raszuk) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 07 Jul 2012 14:39:56 +0200 >From: Robert Raszuk >To: "l2vpn@ietf.org" >Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >Message-ID: <4FF82E1C.6000009@raszuk.net> >Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > >I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. > >It proposed an interesting solution to apply algorithmically computed >VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >option C is used. > >However I have a fundamental question .. from who the draft is >protecting the inter-as service ? > >Who other then participating ISPs can spoof a value of VPN label ? If >the solution is protecting from ISPs itself then I think it does not >help at all as corresponding ISPs/SPs still have full access to their >PEs and could inject packets to VPN sites at will. > >Moreover main issue with option C is not security (at least for the last >10+ years). Main issue with option C and MPLS is that participating >providers need to inject into each other's network all of their >participating PE's /32 addresses so the end to end MPLS LSP can be >build. Originally that was recommended to be done by mutual >redistribution to the IGP .. now the general recommendation is to use >labeled BGP (both IBGP and EBGP). > >So fundamental question to the authors ... who is the potential >attacker/spoofer this draft is aiming to protect from ? > >Best regards, >R. > > > > > >------------------------------ > >_______________________________________________ >L2vpn mailing list >L2vpn@ietf.org >https://www.ietf.org/mailman/listinfo/l2vpn > > >End of L2vpn Digest, Vol 98, Issue 6 >************************************ From jakob.heitz@ericsson.com Sun Jul 8 00:26:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2EC21F86D4 for ; Sun, 8 Jul 2012 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLRQ6mhC75Af for ; Sun, 8 Jul 2012 00:26:34 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 29E0F21F86D3 for ; Sun, 8 Jul 2012 00:26:33 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q687QsZZ007892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jul 2012 02:26:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.26]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 8 Jul 2012 03:26:54 -0400 From: Jakob Heitz To: "l2vpn@ietf.org" Date: Sun, 8 Jul 2012 03:26:55 -0400 Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1c2wruiCHNc0LOQk25cBXKChpJ9A== Message-ID: <2BB4A4BE-59FA-4CC6-A86D-CD96F6C2303E@ericsson.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF2171E9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <4FF82E1C.6000009@raszuk.net> In-Reply-To: <4FF82E1C.6000009@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 07:26:35 -0000 QW5vdGhlciBxdWVzdGlvbi4NCkhvdyBkb2VzIHRoaXMgaW50ZXJhY3Qgd2l0aCBFQ01QIGZsb3cg aGFzaGluZyBvbiBMU1JzLCByZmM2MzkxIGFuZCBkcmFmdC1pZXRmLW1wbHMtZW50cm9weS1sYWJl bD8NCg0KLS0NCkpha29iIEhlaXR6Lg0KDQoNCk9uIEp1bCA3LCAyMDEyLCBhdCA1OjQwIEFNLCAi Um9iZXJ0IFJhc3p1ayIgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5l dD4+IHdyb3RlOg0KDQoNCkkgaGF2ZSByZWFkIHRoZSBkcmFmdC1tanNyYW1hbi1sMnZwbi12cGxz LXRpY3RvYy1sYWJlbC1ob3AtMDAudHh0Lg0KDQpJdCBwcm9wb3NlZCBhbiBpbnRlcmVzdGluZyBz b2x1dGlvbiB0byBhcHBseSBhbGdvcml0aG1pY2FsbHkgY29tcHV0ZWQNClZQTiBsYWJsZSAoZm9y IEwyVlBOcywgYnV0IGFsc28gcG9zc2libGUgZm9yIEwzVlBOKSB3aGVyZSBpbnRlci1hcw0Kb3B0 aW9uIEMgaXMgdXNlZC4NCg0KSG93ZXZlciBJIGhhdmUgYSBmdW5kYW1lbnRhbCBxdWVzdGlvbiAu LiBmcm9tIHdobyB0aGUgZHJhZnQgaXMNCnByb3RlY3RpbmcgdGhlIGludGVyLWFzIHNlcnZpY2Ug Pw0KDQpXaG8gb3RoZXIgdGhlbiBwYXJ0aWNpcGF0aW5nIElTUHMgY2FuIHNwb29mIGEgdmFsdWUg b2YgVlBOIGxhYmVsID8gSWYNCnRoZSBzb2x1dGlvbiBpcyBwcm90ZWN0aW5nIGZyb20gSVNQcyBp dHNlbGYgdGhlbiBJIHRoaW5rIGl0IGRvZXMgbm90DQpoZWxwIGF0IGFsbCBhcyBjb3JyZXNwb25k aW5nIElTUHMvU1BzIHN0aWxsIGhhdmUgZnVsbCBhY2Nlc3MgdG8gdGhlaXINClBFcyBhbmQgY291 bGQgaW5qZWN0IHBhY2tldHMgdG8gVlBOIHNpdGVzIGF0IHdpbGwuDQoNCk1vcmVvdmVyIG1haW4g aXNzdWUgd2l0aCBvcHRpb24gQyBpcyBub3Qgc2VjdXJpdHkgKGF0IGxlYXN0IGZvciB0aGUgbGFz dA0KMTArIHllYXJzKS4gTWFpbiBpc3N1ZSB3aXRoIG9wdGlvbiBDIGFuZCBNUExTIGlzIHRoYXQg cGFydGljaXBhdGluZw0KcHJvdmlkZXJzIG5lZWQgdG8gaW5qZWN0IGludG8gZWFjaCBvdGhlcidz IG5ldHdvcmsgYWxsIG9mIHRoZWlyDQpwYXJ0aWNpcGF0aW5nIFBFJ3MgLzMyIGFkZHJlc3NlcyBz byB0aGUgZW5kIHRvIGVuZCBNUExTIExTUCBjYW4gYmUNCmJ1aWxkLiBPcmlnaW5hbGx5IHRoYXQg d2FzIHJlY29tbWVuZGVkIHRvIGJlIGRvbmUgYnkgbXV0dWFsDQpyZWRpc3RyaWJ1dGlvbiB0byB0 aGUgSUdQIC4uIG5vdyB0aGUgZ2VuZXJhbCByZWNvbW1lbmRhdGlvbiBpcyB0byB1c2UNCmxhYmVs ZWQgQkdQIChib3RoIElCR1AgYW5kIEVCR1ApLg0KDQpTbyBmdW5kYW1lbnRhbCBxdWVzdGlvbiB0 byB0aGUgYXV0aG9ycyAuLi4gd2hvIGlzIHRoZSBwb3RlbnRpYWwNCmF0dGFja2VyL3Nwb29mZXIg dGhpcyBkcmFmdCBpcyBhaW1pbmcgdG8gcHJvdGVjdCBmcm9tID8NCg0KQmVzdCByZWdhcmRzLA0K Ui4NCg0KDQoNCg== From robert@raszuk.net Sun Jul 8 04:01:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3312E21F86CA for ; Sun, 8 Jul 2012 04:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kj7WYZqbA0z for ; Sun, 8 Jul 2012 04:01:42 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 762A321F869F for ; Sun, 8 Jul 2012 04:01:42 -0700 (PDT) Received: (qmail 29823 invoked by uid 399); 8 Jul 2012 11:02:02 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.210.132) by mail1310.opentransfer.com with ESMTPM; 8 Jul 2012 11:02:02 -0000 X-Originating-IP: 83.9.210.132 Message-ID: <4FF968A8.7060806@raszuk.net> Date: Sun, 08 Jul 2012 13:02:00 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: balaji venkat Venkataswami Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shankar Raman M J X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 11:01:43 -0000 Hi Balaji, > Also if one or more Routers of the ISP have been compromised > within the ISP's network then an intruder Trying to gain > access to the VPN traffic would have a hard time guessing > which Traffic belongs to which VPN with our scheme. You are effectively saying that if intruder compromises any router in the ISP or between ISPs it is quite likely that it may get access to VPN label information which are pretty static today. That is actually true for L3VPN and L2VPN. It is the same in basic non inter-as service as well as with inter-as service option A, B & C. I do not see why in particular you are just focused on option C ? Do you have this case in mind: ISP1 -- ISP2 -- ISP3 where ISP2 is just an MPLS transit sitting with a sniffer and observing VPN labels in the data plane ? I do agree that any LxVPN using BGP does not protect from this type of attacks. It is in fact well understood since the early days of MPLS-VPN deployments that sites which require security place hardware encryption devices between or next to their CEs. In other words if your ISP network is so unsecure that it would allow to inject third party an MPLS encapsulated packets (not your trusted ISP option B or option C peer, but one of your customers or hackers) then I think all bet's are off as far as your services go. That is also why for CSC one of the first feature which was added was label validation. CE can not inject any other label then the label already advertised to it. Some implementations do it also for option B. While I like your solution in general I think it still needs to find a problem. For the problem presented IMHO ISP is much better to protect his PEs and his infrastructure rather then trying to make a VPN label a bit harder to guess. Best, R. From balajivenkat299@gmail.com Sun Jul 8 04:39:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFBA21F8703 for ; Sun, 8 Jul 2012 04:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBJdrtZMiApp for ; Sun, 8 Jul 2012 04:39:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C069D21F86B9 for ; Sun, 8 Jul 2012 04:39:28 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so17975516pbc.31 for ; Sun, 08 Jul 2012 04:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=DGJYIWELua0UNw/FU9ufM6jax/udG2dDD1MQIBwkZIU=; b=gxpzYNQDQtMkSvbzWQuvYrRhsys7PkR0IU/vJdrnmKq94wGfccShj4HjbcSs1FpKVr o8IxLEBjeSFJzyEpSUabBz4/1zc54olCNiNXt48fK3xJzJH4ulBM6daijoU181sEGGay f0IhlIePipC5f3zUy2jK+imk85GvWtkKrUK7sldjFYmV/FdCZHBof9ddbw0Wut0mQPDi dMprRxe+4aY+QASuZgqnvU67fS/+RWw6kzG8q2C5OsbfmJifQ21TkqdQAoTdBxQekbYz 6ATGC4FuibxtvYY4xXxLZVRjvBPdgvW0wcai9epsPsV6GpwNooI7FFMItyqfM1CRBydE LY4g== Received: by 10.66.76.103 with SMTP id j7mr58090766paw.60.1341747590436; Sun, 08 Jul 2012 04:39:50 -0700 (PDT) Received: from [192.168.15.105] ([122.164.38.100]) by mx.google.com with ESMTPS id tj4sm25586552pbc.33.2012.07.08.04.39.45 (version=SSLv3 cipher=OTHER); Sun, 08 Jul 2012 04:39:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 08 Jul 2012 17:09:41 +0530 Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: balaji venkat Venkataswami To: Message-ID: Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... In-Reply-To: <4FF968A8.7060806@raszuk.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: l2vpn@ietf.org, Shankar Raman M J X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 11:39:29 -0000 Dear Robert, Comments inline=8A. On 08/07/12 4:32 PM, "Robert Raszuk" wrote: >Hi Balaji, > >> Also if one or more Routers of the ISP have been compromised >> within the ISP's network then an intruder Trying to gain > > access to the VPN traffic would have a hard time guessing >> which Traffic belongs to which VPN with our scheme. > >You are effectively saying that if intruder compromises any router in >the ISP or between ISPs it is quite likely that it may get access to VPN >label information which are pretty static today. That is actually true >for L3VPN and L2VPN. It is the same in basic non inter-as service as >well as with inter-as service option A, B & C. We have another draft posted to the L3VPN group with regard To Option C to protect against spoofing attacks and specifically man-in-the-middle Attacks for Option C in L3-VPNs. It is quite basic that all inter-AS service Options may suffer from this problem but at least A and B options have a Capability to validate the inner label. Option C in the case of Inter-AS doesn't. That's why we focussed on Option C. Some of the references we Have quoted in the draft are testament to that. In the case of a non-inter-AS Case the service provider at least has control over the entire domain and doesn't have an intervening network like the inter-AS cases. > >I do not see why in particular you are just focused on option C ? > >Do you have this case in mind: > >ISP1 -- ISP2 -- ISP3 where ISP2 is just an MPLS transit sitting with a >sniffer and observing VPN labels in the data plane ? This is another case where our scheme can be used to protect the traffic >From being eavesdropped or attacked from the middle ISP or the intervening Networks between the ISPs. > >I do agree that any LxVPN using BGP does not protect from this type of >attacks. It is in fact well understood since the early days of MPLS-VPN >deployments that sites which require security place hardware encryption >devices between or next to their CEs. > >In other words if your ISP network is so unsecure that it would allow to >inject third party an MPLS encapsulated packets (not your trusted ISP >option B or option C peer, but one of your customers or hackers) then I >think all bet's are off as far as your services go. Our draft never covers the case where the label injected packets are injected >From the CE. It covers the case where the trusted or not so trusted ISP peer Has been not so diligent as the first provider and allows compromise of either A PE router or a P router or the intervening network between the providers. Attacks can range from spoofing attacks, unidirectional attacks causing worms To get in, or even DOS attacks that keep the router busy dropping these errant Packets. Our scheme takes care of the same. We do not bring into account or Consider the case where the label injection is happening from the Ces if hackers Are behind such a CE. To stress again Model C is relatively very easy to break if a man-in-the-middle Attack is undertaken as the Pes between the providers do not validate the label Hence the need for a solution here. Thanks and regards, Balaji venkat > >That is also why for CSC one of the first feature which was added was >label validation. CE can not inject any other label then the label >already advertised to it. Some implementations do it also for option B. > >While I like your solution in general I think it still needs to find a >problem. For the problem presented IMHO ISP is much better to protect >his PEs and his infrastructure rather then trying to make a VPN label a >bit harder to guess. > >Best, >R. > > > > > From balajivenkat299@gmail.com Sun Jul 8 05:18:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3221F860B for ; Sun, 8 Jul 2012 05:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0ycH-nkz+te for ; Sun, 8 Jul 2012 05:18:52 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C66AA21F85FD for ; Sun, 8 Jul 2012 05:18:52 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so18015803pbc.31 for ; Sun, 08 Jul 2012 05:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=i9N2/pYv1rLWzPySNqtsz9iiUQJtjtFjc2ASwktYNlg=; b=cLO2gy+dysiwWXcQdq7yziQHWRZSgiWfgAs37Em6Kho2mW/H/QjUd0Cs1/V39diUcU BdjCAM5bh57F0dYk8OKEIs6mRYFH397MLNv/FnhJed1KlggyIUY5WEqXRepuGysI6aMf 5LaCN3j4VLvTLKR1EXxED6Hfgf/Taxc1Sj+jyPzW/EsCPTPnK3H4RLGHMBKA5Qt3vVEr 8jmzE2cyKXRHe3pOie83PxDbLTQk/FSTawPNvLqySaNx8PutQCXJGgQi6JPeF+1c2ZHy nJkfrNlei4E3FrWmbmBE1VvkA7jriBTg4n4LWuEEB+EmW8gaFbyWRlAIkYdbdW7IVqfv tmGQ== MIME-Version: 1.0 Received: by 10.68.217.229 with SMTP id pb5mr51217968pbc.19.1341749953960; Sun, 08 Jul 2012 05:19:13 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Sun, 8 Jul 2012 05:19:13 -0700 (PDT) Date: Sun, 8 Jul 2012 17:49:13 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: jakob.heitz@ericsson.com Content-Type: multipart/alternative; boundary=047d7b2ed94562198d04c45081fd Cc: l2vpn@ietf.org, Shankar Raman M J , Bhargav Bhikkaji , robert@raszuk.net X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 12:18:53 -0000 --047d7b2ed94562198d04c45081fd Content-Type: text/plain; charset=ISO-8859-1 Another question. How does this interact with ECMP flow hashing on LSRs, rfc6391 and draft-ietf-mpls-entropy-label? -- Jakob Heitz. Dear Jakob, You are right. With respect to ECMP flow hashing on LSRs (for pseudowires in RFC 6391) we would have difficulty in providing a clean solution so that packets are not reordered between multiple ECMP paths. So is also the case with entropy label draft. We are in the process of working on this to see if a solution can be given and if so if it can be given then how elegantly we could give it. For now the draft proposal for label-hopping would break both of the above. Your inputs on this would be most useful. thanks and regards, balaji venkat --047d7b2ed94562198d04c45081fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another question.
How does this interact with ECMP flo= w hashing on LSRs, rfc6391 and draft-ietf-mpls-entropy-label?

--
Jakob Heitz.

Dear Jakob,=

You are right. Wit= h respect to ECMP flow hashing on LSRs (for pseudowires in RFC 6391) we wou= ld have difficulty in providing a clean solution so that packets are not re= ordered between multiple ECMP paths. So is also the case with entropy label= draft.

We are in the process of working on this to s= ee if a solution can be given and if so if it can be given then how elegant= ly we could give it.

For now the draft proposal for label-hopping = would break both of the above.

Your inputs on this would be most useful.

thanks and regards,

balaji venkat
--047d7b2ed94562198d04c45081fd-- From robert@raszuk.net Sun Jul 8 10:56:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E040921F85BB for ; Sun, 8 Jul 2012 10:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 MCQdWhiQ4oyb for ; Sun, 8 Jul 2012 10:56:55 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2721F85AF for ; Sun, 8 Jul 2012 10:56:55 -0700 (PDT) Received: (qmail 25903 invoked by uid 399); 8 Jul 2012 17:57:17 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.210.132) by mail1310.opentransfer.com with ESMTPM; 8 Jul 2012 17:57:17 -0000 X-Originating-IP: 83.9.210.132 Message-ID: <4FF9C9FA.2080902@raszuk.net> Date: Sun, 08 Jul 2012 19:57:14 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: balaji venkat Venkataswami Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shankar Raman M J X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 17:56:56 -0000 > We do not bring into account or > Consider the case where the label injection is happening from the Ces if > hackers are behind such a CE. If the hacker is not behind the CE where is it ? Are you saying that peering ISP itself will attack his partner's ISP VPNs ? It can still do it at will if the PE which attaches the VPN sites are compromised. Are you saying that your VPN label would not be see by any cli and show commands of the end to end participating PEs ? Then this is non starter IMHO. r. From balajivenkat299@gmail.com Sun Jul 8 21:45:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0521F883A for ; Sun, 8 Jul 2012 21:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9Qqn3sARwGq for ; Sun, 8 Jul 2012 21:45:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3590521F8838 for ; Sun, 8 Jul 2012 21:45:18 -0700 (PDT) Received: by ggnc4 with SMTP id c4so10640397ggn.31 for ; Sun, 08 Jul 2012 21:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QQpcxUQZ6QT++rZP7K9KHt72n+niC5lQGZFeN5+3tpw=; b=0oIWGITE6AproNOeKgu+CElevJrTYqUCYukp/nRiIl232807QAZv9lN07NUDX9exYP DfhddE4Ujhup14F/ShiQLDWN3ye1uGH7jYzYMGa2wyCyK5LT2bn2XQvaM5/LZS6arT/Y +PTO8oamiUMhoYGE6XYNXUHWuP7nCUxDM3Z72+a/ZpDXAv6jkRQsY/oLYMg0f77KdCWP CkZoEa7JNmrnaD1DYn44SxBJlTPpKIMxT7SxEQhaSAnRtvGFG8lIACjFthrB1t2MPHrJ I2atBTtJeBLiG+0SE/gnIyKpxhMLPX5Cvj4rrRjRBvbp7Ohz2mumF3R6pPtSSFSY3rK1 egVA== MIME-Version: 1.0 Received: by 10.66.75.202 with SMTP id e10mr63324108paw.55.1341809141409; Sun, 08 Jul 2012 21:45:41 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Sun, 8 Jul 2012 21:45:41 -0700 (PDT) In-Reply-To: <4FF9C9FA.2080902@raszuk.net> References: <4FF9C9FA.2080902@raszuk.net> Date: Mon, 9 Jul 2012 10:15:41 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: robert@raszuk.net Content-Type: multipart/alternative; boundary=f46d042dfd733ae7d104c45e497f Cc: l2vpn@ietf.org, Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 04:45:21 -0000 --f46d042dfd733ae7d104c45e497f Content-Type: text/plain; charset=ISO-8859-1 Dear Robert, We talking about the ASBRs between the two or more ISP networks. Consider the situation that the network / networks between the ASBRs is compromised or the ASBR itself is compromised then this scheme would apply. In the case of Model-C the ASBR bordering the ISP networks does not validate the inner label as it would in the case of Option A and B. (PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core network 2)----(PE) The above simple case shows that in the Model C the ASBR would not validate the inner label and hence it is susceptible to spoofing attacks/ unidirectional attacks etc... This is the situation that we are guarding against. Hope this helps. thanks and regards, balaji venkat On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk wrote: > > We do not bring into account or >> Consider the case where the label injection is happening from the Ces if >> hackers are behind such a CE. >> > > If the hacker is not behind the CE where is it ? > > Are you saying that peering ISP itself will attack his partner's ISP VPNs > ? It can still do it at will if the PE which attaches the VPN sites are > compromised. > > Are you saying that your VPN label would not be see by any cli and show > commands of the end to end participating PEs ? Then this is non starter > IMHO. > > r. > --f46d042dfd733ae7d104c45e497f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Robert,

We talking about the ASBRs between the two = or more ISP networks.

Consider the situation that = the network / networks between the ASBRs is compromised or the ASBR itself = is compromised then this scheme would apply.

In the case of Model-C the ASBR bordering the ISP netwo= rks does not validate the inner label as it would in the case of Option A a= nd B.

(PE)----(ISP core network 1) ---->(ASBR1)= -------(ASBR2)------(ISP core network 2)----(PE)

The above simple case shows that in the Model C the ASB= R would not validate the inner label and hence it is susceptible to spoofin= g attacks/ unidirectional attacks etc...

This is t= he situation that we are guarding against.

Hope this helps.

thanks and re= gards,
balaji venkat

On Sun, Ju= l 8, 2012 at 11:27 PM, Robert Raszuk <robert@raszuk.net> wro= te:

We do not bring into account or
Consider the case where the label injection is happening from the Ces if
hackers are behind such a CE.

If the hacker is not behind the CE where is it ?

Are you saying that peering ISP itself will attack his partner's ISP VP= Ns ? It can still do it at will if the PE which attaches the VPN sites are = compromised.

Are you saying that your VPN label would not be see by any cli and show com= mands of the end to end participating PEs ? Then this is non starter IMHO.<= span class=3D"HOEnZb">

r.

--f46d042dfd733ae7d104c45e497f-- From talmi@marvell.com Sun Jul 8 23:14:02 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5013A21F8683; Sun, 8 Jul 2012 23:14:02 -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=[AWL=0.000, 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 iiB3k7xMW4IN; Sun, 8 Jul 2012 23:14:01 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5F29821F8675; Sun, 8 Jul 2012 23:14:01 -0700 (PDT) From: Tal Mizrahi To: balaji venkat Venkataswami Date: Mon, 9 Jul 2012 09:14:20 +0300 Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1c/mgpbqQ+qAQeQhir8QieA7JhswAm1SNQ Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> References: <4FF968A8.7060806@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:14:02 -0000 Hi Balaji, A few clarification questions - I think it would be good to clarify these i= ssues in the draft: 1. Since the label hopping mechanism relies on PTP, I understand that PTP t= raffic itself does not use label hopping, right? 2. Is there something preventing the attacker from attacking PTP, thus caus= ing DoS to the data plane? 3. Is the "additional label" similar to an Integrity Check Value (ICV) comp= uted over part of the packet header?=20 4. Is there something in your approach that would prevent an attacker from = a replay attack? 5. Looking at "Algorithm 3" I was not sure: does the receiver check two con= sequent time slots? I could not see such a check. I am referring to a case = where the sender transmits at the end of a time slot, and the packet is rec= eived at the beginning of the next time slot. That would mean the receiver = has to be able to tolerate two concurrent time slots, right? 6. The security parameters K, TS, A, I are exchanged over a secure link, wh= ich basically assumes there is a pre-shared key between the peer PEs. A nai= ve question would be: how is your approach better than just using a standar= d ICV, based on the existing pre-shared key? Tal. From robert@raszuk.net Mon Jul 9 01:59:26 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06BB21F8804 for ; Mon, 9 Jul 2012 01:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGkisHKHuNzY for ; Mon, 9 Jul 2012 01:59:26 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id DF4A921F8803 for ; Mon, 9 Jul 2012 01:59:25 -0700 (PDT) Received: (qmail 18654 invoked by uid 399); 9 Jul 2012 08:59:48 -0000 Received: from unknown (HELO ?192.168.1.58?) (pbs:robert@raszuk.net@83.9.209.219) by mail1310.opentransfer.com with ESMTPM; 9 Jul 2012 08:59:48 -0000 X-Originating-IP: 83.9.209.219 Message-ID: <4FFA9D82.8090307@raszuk.net> Date: Mon, 09 Jul 2012 10:59:46 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Balaji venkat Venkataswami Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: <4FF9C9FA.2080902@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 08:59:26 -0000 Balaji, Many thx for clearly describing your target. I am of the opinion that your scheme does not protect from compromised ASBR as once hacker has control of the ASBR he can instantiate any vrf locally and inject data from the ASBR itself into any VPN using your scheme. For the link between ASBR yes you have a valid point. But note that over this link both ISPs exchange their precious infrastructure routes (addresses and labels to reach PEs) which if compromised can cause much more harm then injecting some packets into a VPN. Therefor for the case of ASBR to ASBR link being compromized I would much more see local link level security (ex: encryption) for both data and control planes rather then change of the VPN label allocation scheme in both L3VPN networks. Your scheme just makes the guess harder not that it eliminates the attacks. From the point of view of compromised inter-as link an attacker can sweep the VPN label range and still find the matching ones for some duration of time. Also I have a different question ... In each ISP there are 100s of PEs participating in given VPN and perhaps very few ASBRs with option C. Each PE iBGP peers with RR and advertised the VPN label. RR is advertising this label to other PEs in a given ISP domain as well as over eBGP multihop other RRs in other option C domian. Are you envisioning in your scheme direct BGP sessions between all participating in option C PEs ? Are you envisioning PTP full mesh between all PEs in all domains ? How PE if he has today a single IBGP session to vpnv4 RR is going to differentiate between VPN labels he want to advertise locally within his domain (as today) and those which would be used for Inter-AS option C ? Thx, R. > Dear Robert, > > We talking about the ASBRs between the two or more ISP networks. > > Consider the situation that the network / networks between the ASBRs is > compromised or the ASBR itself is compromised then this scheme would apply. > > In the case of Model-C the ASBR bordering the ISP networks does not > validate the inner label as it would in the case of Option A and B. > > (PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core > network 2)----(PE) > > The above simple case shows that in the Model C the ASBR would not > validate the inner label and hence it is susceptible to spoofing > attacks/ unidirectional attacks etc... > > This is the situation that we are guarding against. > > Hope this helps. > > thanks and regards, > balaji venkat > > On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk > wrote: > > > We do not bring into account or > Consider the case where the label injection is happening from > the Ces if > hackers are behind such a CE. > > > If the hacker is not behind the CE where is it ? > > Are you saying that peering ISP itself will attack his partner's ISP > VPNs ? It can still do it at will if the PE which attaches the VPN > sites are compromised. > > Are you saying that your VPN label would not be see by any cli and > show commands of the end to end participating PEs ? Then this is non > starter IMHO. > > r. > > From balajivenkat299@gmail.com Mon Jul 9 03:21:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FB321F86B4 for ; Mon, 9 Jul 2012 03:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMCtqCEIEtBw for ; Mon, 9 Jul 2012 03:21:35 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB8E421F86AB for ; Mon, 9 Jul 2012 03:21:34 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so19586286pbc.31 for ; Mon, 09 Jul 2012 03:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u8uP3sCMQome74ci3Ip8ZrcopnJtM8JW5z9OFe9Z3Bs=; b=xomfmgj+JFb2WqoNb5X2SbkXNVGf+W33aQ2kXyv3juKKxWjevxiTuJL5FBRxu5wg+L 24NOoZJYgMDZFi6+w0yYPPAqOzoY/D++e9Th3+5LzHcr4irHIv8hkKthwfatXwKYq7EL Xh9mS8ZXxHkReWh+Cn4K5plWlALHnbRTDYmf3of0fx3/2ghgjSiWu1caDEgIMzMUqnXz FMl19fRaBcfcEaSLyXkxAzi0PMh7T9vB7wYYmvapevU2jF/Wc8suFCcBpwKC3KfqhEM7 1R01JVyYkYWfsZz+WsfjRcDpyFPyafAjjqAUel0BlltKLJ1UM5YfiDF1brR8BLP728Uc up8g== MIME-Version: 1.0 Received: by 10.68.231.10 with SMTP id tc10mr5771391pbc.107.1341829319490; Mon, 09 Jul 2012 03:21:59 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 03:21:59 -0700 (PDT) In-Reply-To: <4FFA9D82.8090307@raszuk.net> References: <4FF9C9FA.2080902@raszuk.net> <4FFA9D82.8090307@raszuk.net> Date: Mon, 9 Jul 2012 15:51:59 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: robert@raszuk.net Content-Type: multipart/alternative; boundary=047d7b33d19eeffeb304c462fbc1 Cc: l2vpn@ietf.org, Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 10:21:36 -0000 --047d7b33d19eeffeb304c462fbc1 Content-Type: text/plain; charset=ISO-8859-1 Dear Robert, Comments inline On Mon, Jul 9, 2012 at 2:29 PM, Robert Raszuk wrote: > Balaji, > > Many thx for clearly describing your target. > > I am of the opinion that your scheme does not protect from compromised > ASBR as once hacker has control of the ASBR he can instantiate any vrf > locally and inject data from the ASBR itself into any VPN using your scheme. > I am of the opinion that an ASBR if it does not have peering relationships with CEs would not have the feature for label-hopping enabled on it and would have merely peering labels with PE loopback for the other ASBR. In that case the ASBR cannot use the label hopping feature to inject packets to the other ASBR into any VPN using the scheme. > > For the link between ASBR yes you have a valid point. But note that over > this link both ISPs exchange their precious infrastructure routes > (addresses and labels to reach PEs) which if compromised can cause much > more harm then injecting some packets into a VPN. > At least the VPN that employs this scheme will not be affected though it could harm the provider on the side to which such packets are injected. > > Therefor for the case of ASBR to ASBR link being compromized I would much > more see local link level security (ex: encryption) for both data and > control planes rather then change of the VPN label allocation scheme in > both L3VPN networks. > Agreed. But if such a thing happens then the scheme would protect the VPN deploying it to a higher level than it can be done right now with static labels. Guessing the right time to use the right label and distinguishing the right VPN to attack would take a lot more time and effort if the scheme described in the draft is deployed. > > Your scheme just makes the guess harder not that it eliminates the > attacks. From the point of view of compromised inter-as link an attacker > can sweep the VPN label range and still find the matching ones for some > duration of time. > > Sweeping the VPN label range with the Time varying label + the innermost label which is a hash digest on the labelled packet would be much harder since two factors have to be gotten right (a) The right label at the right time for the right VPN and (b) the inner label digest on the payload. So it would be pretty hard to break this scheme in the required time. Also I have a different question ... > > In each ISP there are 100s of PEs participating in given VPN and perhaps > very few ASBRs with option C. > > Each PE iBGP peers with RR and advertised the VPN label. RR is advertising > this label to other PEs in a given ISP domain as well as over eBGP multihop > other RRs in other option C domian. > > Are you envisioning in your scheme direct BGP sessions between all > participating in option C PEs ? Are you envisioning PTP full mesh between > all PEs in all domains ? How PE if he has today a single IBGP session to > vpnv4 RR is going to differentiate between VPN labels he want to advertise > locally within his domain (as today) and those which would be used for > Inter-AS option C ? > > This scheme could be deployed selectively only for those that require greater security. All VPN traffic need not be subjected to this scheme. So you wouldnt need a full PTP mesh between all PEs in all domains. By the fact that there are more than one labels and a time scheme to use them it would be possible for the RR and PE to decipher that this is a label-hopping scheme based on Tic-Toc (of course the Tic-Toc schedule also would be provided to discriminate this specifically as a Tic-Toc scheme) for option-C. If this were a distinguishing factor implied it would be possible to deploy this scheme for option-C alone. Or a suitable community attribute could specify this. Hope this helps in explaining to your questions. Your inputs would be most useful. thanks and regards, balaji and team > > Thx, > R. > > Dear Robert, >> >> We talking about the ASBRs between the two or more ISP networks. >> >> Consider the situation that the network / networks between the ASBRs is >> compromised or the ASBR itself is compromised then this scheme would >> apply. >> >> In the case of Model-C the ASBR bordering the ISP networks does not >> validate the inner label as it would in the case of Option A and B. >> >> (PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core >> network 2)----(PE) >> >> The above simple case shows that in the Model C the ASBR would not >> validate the inner label and hence it is susceptible to spoofing >> attacks/ unidirectional attacks etc... >> >> This is the situation that we are guarding against. >> >> Hope this helps. >> >> thanks and regards, >> balaji venkat >> >> On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk > > wrote: >> >> >> We do not bring into account or >> Consider the case where the label injection is happening from >> the Ces if >> hackers are behind such a CE. >> >> >> If the hacker is not behind the CE where is it ? >> >> Are you saying that peering ISP itself will attack his partner's ISP >> VPNs ? It can still do it at will if the PE which attaches the VPN >> sites are compromised. >> >> Are you saying that your VPN label would not be see by any cli and >> show commands of the end to end participating PEs ? Then this is non >> starter IMHO. >> >> r. >> >> >> > > --047d7b33d19eeffeb304c462fbc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Robert,

Comments inline

On Mon, Jul 9, 2012 at 2:29 PM, Robert Raszuk <= robert@raszuk.net> wrote:

Balaji,

Many thx for clearly describing your target.

I am of the opinion that your scheme does not protect from compromised ASBR= as once hacker has control of the ASBR he can instantiate any vrf locally = and inject data from the ASBR itself into any VPN using your scheme.

I am of the opinion that an ASBR if it doe= s not have peering relationships with CEs would not have the feature for la= bel-hopping enabled on it and would have merely peering labels with PE loop= back for the other ASBR. In that case the ASBR cannot use the label hopping= feature to inject packets to the other ASBR into any VPN using the scheme.= =A0

For the link between ASBR yes you have a valid point. But note that over th= is link both ISPs exchange their precious infrastructure routes (addresses = and labels to reach PEs) which if compromised can cause much more harm then= injecting some packets into a VPN.

=A0
At least the VPN that employs this scheme w= ill not be affected though it could harm the provider on the side to which = such packets are injected.

Therefor for the case of ASBR to ASBR link being compromized I would much m= ore see local link level security (ex: encryption) for both data and contro= l planes rather then change of the VPN label allocation scheme in both L3VP= N networks.

Agreed. But if such a thing happens then t= he scheme would protect the VPN deploying it to a higher level than it can = be done right now with static labels.

Guessing the= right time to use the right label and distinguishing the right VPN to atta= ck would take a lot more time and effort if the scheme described in the dra= ft is deployed.

Your scheme just makes the guess harder not that it eliminates the attacks.= From the point of view of compromised inter-as link an attacker can sweep = the VPN label range and still find the matching ones for some duration of t= ime.

Sweeping the VPN label range with the = Time varying label + the innermost label which is a hash digest on the labe= lled packet would be much harder since two factors have to be gotten right = (a) The right label at the right time for the right VPN and (b) the inner l= abel digest on the payload. So it would be pretty hard to break this scheme= in the required time.

Also I have a different question ...

In each ISP there are 100s of PEs participating in given VPN and perhaps ve= ry few ASBRs with option C.

Each PE iBGP peers with RR and advertised the VPN label. RR is advertising = this label to other PEs in a given ISP domain as well as over eBGP multihop= other RRs in other option C domian.

Are you envisioning in your scheme direct BGP sessions between all particip= ating in option C PEs ? Are you envisioning PTP full mesh between all PEs i= n all domains ? How PE if he has today a single IBGP session to vpnv4 RR is= going to differentiate between VPN labels he want to advertise locally wit= hin his domain (as today) and those which would be used for Inter-AS option= C ?

This scheme could be deployed selectiv= ely only for those that require greater security. All VPN traffic need not = be subjected to this scheme. So you wouldnt need a full PTP mesh between al= l PEs in all domains. By the fact that there are more than one labels and a= time scheme to use them it would be possible for the RR and PE to decipher= that this is a label-hopping scheme based on Tic-Toc (of course the Tic-To= c schedule also would be provided to discriminate this specifically as a Ti= c-Toc scheme) for option-C. If this were a distinguishing factor implied it= would be possible to deploy this scheme for option-C alone. Or a suitable = community attribute could specify this.

Hope this helps in explaining to your questions.
<= div>
Your inputs would be most useful.

thanks and regards,
balaji and team

Thx,
R.

Dear Robert,

We talking about the ASBRs between the two or more ISP networks.

Consider the situation that the network / networks between the ASBRs is
compromised or the ASBR itself is compromised then this scheme would apply.=

In the case of Model-C the ASBR bordering the ISP networks does not
validate the inner label as it would in the case of Option A and B.

(PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core<= br> network 2)----(PE)

The above simple case shows that in the Model C the ASBR would not
validate the inner label and hence it is susceptible to spoofing
attacks/ unidirectional attacks etc...

This is the situation that we are guarding against.

Hope this helps.

thanks and regards,
balaji venkat

On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=A0 =A0 =A0 =A0 We do not bring into account or
=A0 =A0 =A0 =A0 Consider the case where the label injection is happening fr= om
=A0 =A0 =A0 =A0 the Ces if
=A0 =A0 =A0 =A0 hackers are behind such a CE.

=A0 =A0 If the hacker is not behind the CE where is it ?

=A0 =A0 Are you saying that peering ISP itself will attack his partner'= s ISP
=A0 =A0 VPNs ? It can still do it at will if the PE which attaches the VPN<= br> =A0 =A0 sites are compromised.

=A0 =A0 Are you saying that your VPN label would not be see by any cli and<= br> =A0 =A0 show commands of the end to end participating PEs ? Then this is no= n
=A0 =A0 starter IMHO.

=A0 =A0 r.

--047d7b33d19eeffeb304c462fbc1-- From ju1738@att.com Mon Jul 9 04:34:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8821F861F for ; Mon, 9 Jul 2012 04:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxRlGQzhwE-i for ; Mon, 9 Jul 2012 04:34:37 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5047F21F85F8 for ; Mon, 9 Jul 2012 04:34:37 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 6e1caff4.73bbe940.161014.00-578.415923.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jul 2012 11:35:02 +0000 (UTC) X-MXL-Hash: 4ffac1e6738fc857-6109a15d76df534657d9a2d413a53bb15e787ae9 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ed1caff4.0.161004.00-433.415894.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jul 2012 11:34:56 +0000 (UTC) X-MXL-Hash: 4ffac1e007c047c7-9965ae465849507dd5411b788aed0b439f2efd76 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69BYrKN000309; Mon, 9 Jul 2012 04:34:53 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69BYdXq032667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 04:34:41 -0700 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 9 Jul 2012 04:34:16 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 07:34:16 -0400 From: "UTTARO, JAMES" To: "'Balaji venkat Venkataswami'" , "robert@raszuk.net" Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: AQHNXPkjkVWxthGAfEmFpss0jxEgQpcfhdWAgABpfACAALUtgIAALjeQ Date: Mon, 9 Jul 2012 11:34:15 +0000 Message-ID: References: <4FF9C9FA.2080902@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.155.252] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550FB32910MISOUT7MSGUSR9IIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=gE9O8Arr410A:10 a=wOlsRfkDYaIA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=ziNsr6a5nes0vla0Ia4A:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=lZB815dzVvQA:10 a=bDUki_mJ7DgA:10 a=qnsro] X-AnalysisOut: [asS5wlNr3Jf:21 a=xlc2B-dHbq3dhwBp:21 a=yMhMjlubAAAA:8 a=SS] X-AnalysisOut: [mOFEACAAAA:8 a=HllZdqc8cCXLaolXx5cA:9 a=gKO2Hq4RSVkA:10 a=] X-AnalysisOut: [UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=hQ7L] X-AnalysisOut: [Qt6uGEngFO5E:21 a=p9uMiLIgIy3he8qG:21] Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:34:38 -0000 --_000_B17A6910EEDD1F45980687268941550FB32910MISOUT7MSGUSR9IIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Balaji, I understand that the VPN Label that has been assigned is o= paque at the ASBRs in Option C or C-.. I still do not understand who is act= ually doing the attacking.. Can you describe the use case? How would the AS= BR link be attacked and by whom.. Thanks, Jim Uttaro From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= alaji venkat Venkataswami Sent: Monday, July 09, 2012 12:46 AM To: robert@raszuk.net Cc: l2vpn@ietf.org; Shankar Raman M J; Bhargav Bhikkaji Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Robert, We talking about the ASBRs between the two or more ISP networks. Consider the situation that the network / networks between the ASBRs is com= promised or the ASBR itself is compromised then this scheme would apply. In the case of Model-C the ASBR bordering the ISP networks does not validat= e the inner label as it would in the case of Option A and B. (PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core net= work 2)----(PE) The above simple case shows that in the Model C the ASBR would not validate= the inner label and hence it is susceptible to spoofing attacks/ unidirect= ional attacks etc... This is the situation that we are guarding against. Hope this helps. thanks and regards, balaji venkat On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk > wrote: We do not bring into account or Consider the case where the label injection is happening from the Ces if hackers are behind such a CE. If the hacker is not behind the CE where is it ? Are you saying that peering ISP itself will attack his partner's ISP VPNs ?= It can still do it at will if the PE which attaches the VPN sites are comp= romised. Are you saying that your VPN label would not be see by any cli and show com= mands of the end to end participating PEs ? Then this is non starter IMHO. r. --_000_B17A6910EEDD1F45980687268941550FB32910MISOUT7MSGUSR9IIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Balaji,=

<= /p>
&= nbsp; I underst= and that the VPN Label that has been assigned is opaque at the ASBRs in Opt= ion C or C-.. I still do not understand who is actually doing the attacking.. Can you describe the use case? How would the ASBR li= nk be attacked and by whom..

<= /p>
Thanks,=

&= nbsp; Jim Uttar= o

<= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balaji venkat Venkataswami
Sent: Monday, July 09, 2012 12:46 AM
To: robert@raszuk.net
Cc: l2vpn@ietf.org; Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Robert,

We talking about the ASBRs between the two or more I= SP networks.

Consider the situation that the network / networks b= etween the ASBRs is compromised or the ASBR itself is compromised then this= scheme would apply.

In the case of Model-C the ASBR bordering the ISP ne= tworks does not validate the inner label as it would in the case of Option = A and B.

(PE)----(ISP core network 1) ---->(ASBR1) -------= (ASBR2)------(ISP core network 2)----(PE)

The above simple case shows that in the Model C the = ASBR would not validate the inner label and hence it is susceptible to spoo= fing attacks/ unidirectional attacks etc...

This is the situation that we are guarding against.<= o:p>

Hope this helps.

thanks and regards,

balaji venkat

On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

We do not bring into account or
Consider the case where the label injection is happening from the Ces if

hackers are behind such a CE.

If the hacker is not behind the CE where is it ?

Are you saying that peering ISP itself will attack his partner's ISP VPNs ?= It can still do it at will if the PE which attaches the VPN sites are comp= romised.

Are you saying that your VPN label would not be see by any cli and show com= mands of the end to end participating PEs ? Then this is non starter IMHO.<= span style=3D"color:#888888">

r.

--_000_B17A6910EEDD1F45980687268941550FB32910MISOUT7MSGUSR9IIT_-- From balajivenkat299@gmail.com Mon Jul 9 04:59:30 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796A21F85D1 for ; Mon, 9 Jul 2012 04:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nczWrB0SxFdt for ; Mon, 9 Jul 2012 04:59:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C664921F85C5 for ; Mon, 9 Jul 2012 04:59:29 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so19717311pbc.31 for ; Mon, 09 Jul 2012 04:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DAX+jky5V+a+t+dreTwx39w7zYUvTo9wj3tCLR1h45w=; b=vYZzOiMZGNQh9A+PMkzqHTIUma5ZD3eY6mErUWVC/LVdUSQx7PbubIe2NcbBjWtWtP Mr/iy1QhHjgyCWNnVtBrHG4/S+Myz+2LuSPv2+WKO7RYuCPxNvzakQQQj/ug3y+BAuLd 0Tah2TrjwSceXpboAPKffe7WIxz+tU4NDhe/G6xu+qGfyt/PYwQthmsYvVt1gd43+rS7 Bofl7qQog63kHBwuGg229rOA4hyCX9UHAic0eeeW9Yuc5gNzqvY8NNEhLn7CNTkrMIZH mrLoiopbjFL6VKxy0j8W/zH+4/1M7cRXbCiV7BTKENsJIJFJlucyTB1ElTj3s1cUO9XX zutA== MIME-Version: 1.0 Received: by 10.68.211.193 with SMTP id ne1mr19388060pbc.142.1341835194390; Mon, 09 Jul 2012 04:59:54 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 04:59:54 -0700 (PDT) In-Reply-To: References: <4FF9C9FA.2080902@raszuk.net> Date: Mon, 9 Jul 2012 17:29:54 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=e89a8fb208e81bda7504c4645a3e Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:59:30 -0000 --e89a8fb208e81bda7504c4645a3e Content-Type: text/plain; charset=ISO-8859-1 Dear James, Consider the following situation. Consider two or more providers connecting to each other at an IXP through a high-end L2 switch that provides connectivity between providers. If the switch is tapped through either mirroring or through other means, the inner label can be easily deciphered by the tapper. Consider another situation where the ASBR of one provider is compromised and an interested eavesdropper is trying to look into the packets of a specific VPN (say the defence department or ministry of interior) traffic which is seeking services from the given ISPs in the inter-AS setup. In both these conditions the ASBR to ASBR link may be compromised if there was not a dedicated link connecting the two providers. If more than two providers are involved then the situation becomes more susceptible to spoofing, eavesdropping or unidirectional attacks (DoS, worm etc...). In such a case our scheme would help since it would confuse the tapper into thinking that static labels are involved and hence only a subset of packets of a flow which is using this scheme would be susceptible to such attacks. By changing the label (inner VPN label) over time it is possible to confuse the attacker and hence not give him the capability to eavesdrop, attack, spoof the specific VPN he thinks he is attacking. It would take more time and complexity for an algorithm to decipher this scheme, specifically the labels, the time instances where such labels are valid and the inner digest label that is payload dependent. Hope this helps. Your inputs would be most useful. thanks and regards, balaji venkat and team On Mon, Jul 9, 2012 at 5:04 PM, UTTARO, JAMES wrote: > Balaji,**** > > ** ** > > I understand that the VPN Label that has been assigned is > opaque at the ASBRs in Option C or C-.. I still do not understand who is > actually doing the attacking.. Can you describe the use case? How would the > ASBR link be attacked and by whom..**** > > ** ** > > Thanks,**** > > Jim Uttaro**** > > ** ** > > *From:* l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] *On Behalf > Of *Balaji venkat Venkataswami > *Sent:* Monday, July 09, 2012 12:46 AM > *To:* robert@raszuk.net > *Cc:* l2vpn@ietf.org; Shankar Raman M J; Bhargav Bhikkaji > *Subject:* Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...**** > > ** ** > > Dear Robert,**** > > ** ** > > We talking about the ASBRs between the two or more ISP networks.**** > > ** ** > > Consider the situation that the network / networks between the ASBRs is > compromised or the ASBR itself is compromised then this scheme would apply. > **** > > ** ** > > In the case of Model-C the ASBR bordering the ISP networks does not > validate the inner label as it would in the case of Option A and B.**** > > ** ** > > (PE)----(ISP core network 1) ---->(ASBR1) -------(ASBR2)------(ISP core > network 2)----(PE)**** > > ** ** > > The above simple case shows that in the Model C the ASBR would not > validate the inner label and hence it is susceptible to spoofing attacks/ > unidirectional attacks etc...**** > > ** ** > > This is the situation that we are guarding against.**** > > ** ** > > Hope this helps.**** > > ** ** > > thanks and regards,**** > > balaji venkat**** > > On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk wrote:* > *** > > ** ** > > We do not bring into account or > Consider the case where the label injection is happening from the Ces if** > ** > > hackers are behind such a CE.**** > > > If the hacker is not behind the CE where is it ? > > Are you saying that peering ISP itself will attack his partner's ISP VPNs > ? It can still do it at will if the PE which attaches the VPN sites are > compromised. > > Are you saying that your VPN label would not be see by any cli and show > commands of the end to end participating PEs ? Then this is non starter > IMHO. > > r.**** > > ** ** > --e89a8fb208e81bda7504c4645a3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear James,

Consider the following situation.
=
Consider two or more providers connecting to each other at a= n IXP through a high-end L2 switch that provides connectivity between provi= ders. If the switch is tapped through either mirroring or through other mea= ns, the inner label can be easily deciphered by the tapper.

Consider another situation where the ASBR of one provid= er is compromised and an interested eavesdropper is trying to look into the= packets of a specific VPN (say the defence department or ministry of inter= ior) traffic which is seeking services from the given =A0ISPs in the inter-= AS setup.

In both these conditions the ASBR to ASBR link may be c= ompromised if there was not a dedicated link connecting the two providers. = If more than two providers are involved then the situation becomes more sus= ceptible to spoofing, eavesdropping or unidirectional attacks (DoS, worm et= c...).=A0

In such a case our scheme would help since it would con= fuse the tapper into thinking that static labels are involved and hence onl= y a subset of packets of a flow which is using this scheme would be suscept= ible to such attacks. By changing the label (inner VPN label) over time it = is possible to confuse the attacker and hence not give him the capability t= o eavesdrop, attack, spoof the specific VPN he thinks he is attacking. It w= ould take more time and complexity for an algorithm to decipher this scheme= , specifically the labels, the time instances where such labels are valid a= nd the inner digest label that is payload dependent.

Hope this helps.

Your inputs w= ould be most useful.

thanks and regards,
balaji venkat and team

On Mon, Jul 9, 20= 12 at 5:04 PM, UTTARO, JAMES <ju1738@att.com> wrote:

Balaji,

=A0<= /p>
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 I understand that the VPN Label that has been assigne= d is opaque at the ASBRs in Option C or C-.. I still do not understand who = is actually doing the attacking.. Can you describe the use case? How would the ASBR li= nk be attacked and by whom..

=A0<= /p>
Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Jim Uttaro

=A0<= /p>

From: l2vpn-bounces@ietf.org= [mailto:l2= vpn-bounces@ietf.org] On Behalf Of Balaji venkat Venkataswami
Sent: Monday, July 09, 2012 12:46 AM
To: robert@ra= szuk.net
Cc: l2vpn@ietf.o= rg; Shankar Raman M J; Bhargav Bhikkaji
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

=A0

Dear Robert,

=A0

We talking about the ASBRs between the two or more I= SP networks.

=A0

Consider the situation that the network / networks b= etween the ASBRs is compromised or the ASBR itself is compromised then this= scheme would apply.

=A0

In the case of Model-C the ASBR bordering the ISP ne= tworks does not validate the inner label as it would in the case of Option = A and B.

=A0

(PE)----(ISP core network 1) ---->(ASBR1) -------= (ASBR2)------(ISP core network 2)----(PE)

=A0

The above simple case shows that in the Model C the = ASBR would not validate the inner label and hence it is susceptible to spoo= fing attacks/ unidirectional attacks etc...

=A0

This is the situation that we are guarding against.<= u>

=A0

Hope this helps.

=A0

thanks and regards,

balaji venkat<= u>

On Sun, Jul 8, 2012 at 11:27 PM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:

=A0

We do not bring into account or
Consider the case where the label injection is happening from the Ces if=

hackers are behind such a CE.

If the hacker is not behind the CE where is it ?

Are you saying that peering ISP itself will attack his partner's ISP VP= Ns ? It can still do it at will if the PE which attaches the VPN sites are = compromised.

Are you saying that your VPN label would not be see by any cli and show com= mands of the end to end participating PEs ? Then this is non starter IMHO.<= span style=3D"color:#888888">

r.

=A0

--e89a8fb208e81bda7504c4645a3e-- From robert@raszuk.net Mon Jul 9 06:18:35 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7260B11E8087 for ; Mon, 9 Jul 2012 06:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 YdhQ2E3B3Cik for ; Mon, 9 Jul 2012 06:18:35 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9D88711E807F for ; Mon, 9 Jul 2012 06:18:34 -0700 (PDT) Received: (qmail 26224 invoked by uid 399); 9 Jul 2012 13:18:59 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.219.81) by mail1310.opentransfer.com with ESMTPM; 9 Jul 2012 13:18:59 -0000 X-Originating-IP: 83.31.219.81 Message-ID: <4FFADA41.1070906@raszuk.net> Date: Mon, 09 Jul 2012 15:18:57 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Balaji venkat Venkataswami Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: <4FF9C9FA.2080902@raszuk.net> <4FFA9D82.8090307@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 13:18:35 -0000 Hi Balaji, > I am of the opinion that an ASBR if it does not have peering > relationships with CEs would not have the feature for label-hopping > enabled on it And based number of projects I have seen ASBR pretty much always is also acting as PE and have customers attached. ASBRs are just too expensive to place them in the network with just two interfaces hanging there. > Agreed. But if such a thing happens then the scheme would protect the > VPN deploying it to a higher level than it can be done right now with > static labels. Do you see any value of your proposal if one could do IPSec between PEs in hardware with any rate which is required by inter-AS option C customers ? Yes you compare this in the draft using one x86 generic compute platform. But if we assume that PEs used are capable of IPSec would you still deploy your scheme ? Note that there is another significant advantage of using IPSec between option C PEs .. it runs over IP. So no need to build hierarchy of MPLS labels for transport nor exchange all of those /32s loopbacks between any domains for constructing transport level LSP. Thx, R. From josh.rogers@twcable.com Mon Jul 9 07:21:57 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A571F11E8083 for ; Mon, 9 Jul 2012 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwiMmzSzsGvs for ; Mon, 9 Jul 2012 07:21:57 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5679011E8079 for ; Mon, 9 Jul 2012 07:21:56 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,552,1336363200"; d="scan'208";a="407071452" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jul 2012 10:21:14 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 9 Jul 2012 10:21:33 -0400 From: "Rogers, Josh" To: balaji venkat Venkataswami , "l2vpn@ietf.org" , "robert@raszuk.net" Date: Mon, 9 Jul 2012 10:21:34 -0400 Subject: Re: L2vpn Digest, Vol 98, Issue 6 Thread-Topic: L2vpn Digest, Vol 98, Issue 6 Thread-Index: Ac1d3iOdDjelgaQmQ8+qv1VIhIuU5w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:21:57 -0000 While I don't necessarily agree with this draft's approach ("security through obscurity" comes to mind), I'd like to point out that I do see a need to assuage concerns about using Option C between operators. In my part of the world, when I propose Option C to other operators, often the idea is met with concern/resistance, seemingly because the other operator has not done it before. Even internally, many of my colleagues are concerned about security and the trust model in general. It appears to me, to be no different than any other IP peering relationship, which requires some basic 'trust', albeit not implicit trust. I think Robert's suggestion of leveraging encryption is a more ironclad and reasonable solution to the problems presented here. However, I'd still like to see an informative 'best practices' document at some point that covered some basic policies that should be followed when peering with another ISP for LxVPN exchange. -Josh On 7/8/12 1:46 AM, "balaji venkat Venkataswami" wrote: >Dear Robert, > >As mentioned in the earlier mail the following restriction is imposed on >the >Model C deployment=A9 > >The consequence of this is that in model C the service providers must >trust each other also in areas that are not shared. Therefore, model C is >most commonly used today where a single operator uses several ASs on the >backbone. In this case, implicit trust exists between the ASs because they >have the same operational control. > > >In order to stretch this scheme to other Ases under different admin >control this scheme helps out. > >Thanks and regards, >Balaji venkat > >On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" >wrote: > >>If you have received this digest without all the individual message >>attachments you will need to update your digest options in your list >>subscription. To do so, go to >> >>https://www.ietf.org/mailman/listinfo/l2vpn >> >>Click the 'Unsubscribe or edit options' button, log in, and set "Get >>MIME or Plain Text Digests?" to MIME. You can set this option >>globally for all the list digests you receive at this point. >> >> >> >>Send L2vpn mailing list submissions to >> l2vpn@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/l2vpn >>or, via email, send a message with subject or body 'help' to >> l2vpn-request@ietf.org >> >>You can reach the person managing the list at >> l2vpn-owner@ietf.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of L2vpn digest..." >> >> >>Today's Topics: >> >> 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >> (Robert Raszuk) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Sat, 07 Jul 2012 14:39:56 +0200 >>From: Robert Raszuk >>To: "l2vpn@ietf.org" >>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>Message-ID: <4FF82E1C.6000009@raszuk.net> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> >> >>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. >> >>It proposed an interesting solution to apply algorithmically computed >>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >>option C is used. >> >>However I have a fundamental question .. from who the draft is >>protecting the inter-as service ? >> >>Who other then participating ISPs can spoof a value of VPN label ? If >>the solution is protecting from ISPs itself then I think it does not >>help at all as corresponding ISPs/SPs still have full access to their >>PEs and could inject packets to VPN sites at will. >> >>Moreover main issue with option C is not security (at least for the last >>10+ years). Main issue with option C and MPLS is that participating >>providers need to inject into each other's network all of their >>participating PE's /32 addresses so the end to end MPLS LSP can be >>build. Originally that was recommended to be done by mutual >>redistribution to the IGP .. now the general recommendation is to use >>labeled BGP (both IBGP and EBGP). >> >>So fundamental question to the authors ... who is the potential >>attacker/spoofer this draft is aiming to protect from ? >> >>Best regards, >>R. >> >> >> >> >> >>------------------------------ >> >>_______________________________________________ >>L2vpn mailing list >>L2vpn@ietf.org >>https://www.ietf.org/mailman/listinfo/l2vpn >> >> >>End of L2vpn Digest, Vol 98, Issue 6 >>************************************ > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ju1738@att.com Mon Jul 9 07:35:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87611E8099 for ; Mon, 9 Jul 2012 07:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.309 X-Spam-Level: X-Spam-Status: No, score=-106.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 a5JBN50vn5S9 for ; Mon, 9 Jul 2012 07:35:41 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A211E808F for ; Mon, 9 Jul 2012 07:35:40 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 65ceaff4.74fc0940.207638.00-586.546899.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jul 2012 14:36:06 +0000 (UTC) X-MXL-Hash: 4ffaec56132176b4-a2053a29ca1e2fdd19961adf3501066d2ad1ad11 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id e4ceaff4.0.207612.00-491.546817.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jul 2012 14:35:59 +0000 (UTC) X-MXL-Hash: 4ffaec4f3629999b-38561b0caf79031bd01e24946ab86493c40feeef Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69EZuaw005842; Mon, 9 Jul 2012 07:35:58 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69EZq1W005755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 07:35:54 -0700 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by fflint03.pst.cso.att.com (RSA Interceptor); Mon, 9 Jul 2012 07:35:33 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 10:35:32 -0400 From: "UTTARO, JAMES" To: "'Rogers, Josh'" , balaji venkat Venkataswami , "l2vpn@ietf.org" , "robert@raszuk.net" Subject: RE: L2vpn Digest, Vol 98, Issue 6 Thread-Topic: L2vpn Digest, Vol 98, Issue 6 Thread-Index: Ac1d3iOdVst3wH8vN0uvsrGUCI9bogAAKKdg Date: Mon, 9 Jul 2012 14:35:31 +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: [135.70.155.252] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=gE9O8Arr410A:10 a=9xHMEmg6Re4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=-CRmgG0JhlAA:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=2clOPd4PAAAA:8 a=pGLkceIS] X-AnalysisOut: [AAAA:8 a=NHGU_W0H71IkOvVAKAEA:9 a=jiObf9B0YAUA:10 a=lZB815] X-AnalysisOut: [dzVvQA:10 a=bDUki_mJ7DgA:10 a=MSl-tDqOz04A:10 a=19j6LRxnqm] X-AnalysisOut: [wKp53E:21 a=X__jf8Lwdhm1_Zpx:21] Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:35:42 -0000 Josh, Yes quite leery of building an Option C solution to other providers for a = number of reasons including trust, security but also others i.e RT Mapping,= Scale, Protected Infrastructure available to others, IGP Scale ( # of LBs = ), Pri/Back Selection of ASBR, attack on the PEs, etc... Actually the more = sophisticated the Option C solution the more alignment and possible risk.=20 I understand the ask that this draft is attempting to meet, but does it mak= e sense to do this without addressing the other facets of building an Optio= n C solution between different ISPs.. Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: Monday, July 09, 2012 10:22 AM To: balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszuk.net Cc: Shankar Raman M J; Bhargav Bhikkaji Subject: Re: L2vpn Digest, Vol 98, Issue 6 While I don't necessarily agree with this draft's approach ("security through obscurity" comes to mind), I'd like to point out that I do see a need to assuage concerns about using Option C between operators. In my part of the world, when I propose Option C to other operators, often the idea is met with concern/resistance, seemingly because the other operator has not done it before. Even internally, many of my colleagues are concerned about security and the trust model in general. It appears to me, to be no different than any other IP peering relationship, which requires some basic 'trust', albeit not implicit trust. I think Robert's suggestion of leveraging encryption is a more ironclad and reasonable solution to the problems presented here. However, I'd still like to see an informative 'best practices' document at some point that covered some basic policies that should be followed when peering with another ISP for LxVPN exchange. -Josh On 7/8/12 1:46 AM, "balaji venkat Venkataswami" wrote: >Dear Robert, > >As mentioned in the earlier mail the following restriction is imposed on >the >Model C deployment=A9 > >The consequence of this is that in model C the service providers must >trust each other also in areas that are not shared. Therefore, model C is >most commonly used today where a single operator uses several ASs on the >backbone. In this case, implicit trust exists between the ASs because they >have the same operational control. > > >In order to stretch this scheme to other Ases under different admin >control this scheme helps out. > >Thanks and regards, >Balaji venkat > >On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" >wrote: > >>If you have received this digest without all the individual message >>attachments you will need to update your digest options in your list >>subscription. To do so, go to >> >>https://www.ietf.org/mailman/listinfo/l2vpn >> >>Click the 'Unsubscribe or edit options' button, log in, and set "Get >>MIME or Plain Text Digests?" to MIME. You can set this option >>globally for all the list digests you receive at this point. >> >> >> >>Send L2vpn mailing list submissions to >> l2vpn@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/l2vpn >>or, via email, send a message with subject or body 'help' to >> l2vpn-request@ietf.org >> >>You can reach the person managing the list at >> l2vpn-owner@ietf.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of L2vpn digest..." >> >> >>Today's Topics: >> >> 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >> (Robert Raszuk) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Sat, 07 Jul 2012 14:39:56 +0200 >>From: Robert Raszuk >>To: "l2vpn@ietf.org" >>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>Message-ID: <4FF82E1C.6000009@raszuk.net> >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> >> >>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. >> >>It proposed an interesting solution to apply algorithmically computed >>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >>option C is used. >> >>However I have a fundamental question .. from who the draft is >>protecting the inter-as service ? >> >>Who other then participating ISPs can spoof a value of VPN label ? If >>the solution is protecting from ISPs itself then I think it does not >>help at all as corresponding ISPs/SPs still have full access to their >>PEs and could inject packets to VPN sites at will. >> >>Moreover main issue with option C is not security (at least for the last >>10+ years). Main issue with option C and MPLS is that participating >>providers need to inject into each other's network all of their >>participating PE's /32 addresses so the end to end MPLS LSP can be >>build. Originally that was recommended to be done by mutual >>redistribution to the IGP .. now the general recommendation is to use >>labeled BGP (both IBGP and EBGP). >> >>So fundamental question to the authors ... who is the potential >>attacker/spoofer this draft is aiming to protect from ? >> >>Best regards, >>R. >> >> >> >> >> >>------------------------------ >> >>_______________________________________________ >>L2vpn mailing list >>L2vpn@ietf.org >>https://www.ietf.org/mailman/listinfo/l2vpn >> >> >>End of L2vpn Digest, Vol 98, Issue 6 >>************************************ > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From josh.rogers@twcable.com Mon Jul 9 07:39:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6E21F8573 for ; Mon, 9 Jul 2012 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdK3HbqAtACf for ; Mon, 9 Jul 2012 07:39:38 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B721F859A for ; Mon, 9 Jul 2012 07:39:37 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.77,552,1336363200"; d="scan'208";a="407085806" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jul 2012 10:39:43 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 9 Jul 2012 10:40:02 -0400 From: "Rogers, Josh" To: "UTTARO, JAMES" , balaji venkat Venkataswami , "l2vpn@ietf.org" , "robert@raszuk.net" Date: Mon, 9 Jul 2012 10:40:03 -0400 Subject: Re: L2vpn Digest, Vol 98, Issue 6 Thread-Topic: L2vpn Digest, Vol 98, Issue 6 Thread-Index: Ac1d4LiUFrc7vk4nQiCBpAKv6Ip8Kw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:39:38 -0000 I would propose tabling this draft, and attempting to create a document outlining 1) how best to establish option C peering with other SP's, and 2) outstanding caveats/exposures that are not addressed with available technology/standards. Having such a document would better frame any subsequent 'solution' drafts that address concerns not currently addressable with good policy/practice. -josh On 7/9/12 9:35 AM, "UTTARO, JAMES" wrote: >Josh, > > Yes quite leery of building an Option C solution to other providers= for >a number of reasons including trust, security but also others i.e RT >Mapping, Scale, Protected Infrastructure available to others, IGP Scale ( ># of LBs ), Pri/Back Selection of ASBR, attack on the PEs, etc... >Actually the more sophisticated the Option C solution the more alignment >and possible risk. > >I understand the ask that this draft is attempting to meet, but does it >make sense to do this without addressing the other facets of building an >Option C solution between different ISPs.. > >Jim Uttaro > > > > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Monday, July 09, 2012 10:22 AM >To: balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszuk.net >Cc: Shankar Raman M J; Bhargav Bhikkaji >Subject: Re: L2vpn Digest, Vol 98, Issue 6 > >While I don't necessarily agree with this draft's approach ("security >through obscurity" comes to mind), I'd like to point out that I do see a >need to assuage concerns about using Option C between operators. In my >part of the world, when I propose Option C to other operators, often the >idea is met with concern/resistance, seemingly because the other operator >has not done it before. Even internally, many of my colleagues are >concerned about security and the trust model in general. It appears to >me, to be no different than any other IP peering relationship, which >requires some basic 'trust', albeit not implicit trust. > >I think Robert's suggestion of leveraging encryption is a more ironclad >and reasonable solution to the problems presented here. However, I'd >still like to see an informative 'best practices' document at some point >that covered some basic policies that should be followed when peering with >another ISP for LxVPN exchange. > >-Josh > > > >On 7/8/12 1:46 AM, "balaji venkat Venkataswami" > wrote: > >>Dear Robert, >> >>As mentioned in the earlier mail the following restriction is imposed on >>the >>Model C deployment=A9 >> >>The consequence of this is that in model C the service providers must >>trust each other also in areas that are not shared. Therefore, model C is >>most commonly used today where a single operator uses several ASs on the >>backbone. In this case, implicit trust exists between the ASs because >>they >>have the same operational control. >> >> >>In order to stretch this scheme to other Ases under different admin >>control this scheme helps out. >> >>Thanks and regards, >>Balaji venkat >> >>On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" >>wrote: >> >>>If you have received this digest without all the individual message >>>attachments you will need to update your digest options in your list >>>subscription. To do so, go to >>> >>>https://www.ietf.org/mailman/listinfo/l2vpn >>> >>>Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>MIME or Plain Text Digests?" to MIME. You can set this option >>>globally for all the list digests you receive at this point. >>> >>> >>> >>>Send L2vpn mailing list submissions to >>> l2vpn@ietf.org >>> >>>To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/l2vpn >>>or, via email, send a message with subject or body 'help' to >>> l2vpn-request@ietf.org >>> >>>You can reach the person managing the list at >>> l2vpn-owner@ietf.org >>> >>>When replying, please edit your Subject line so it is more specific >>>than "Re: Contents of L2vpn digest..." >>> >>> >>>Today's Topics: >>> >>> 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>> (Robert Raszuk) >>> >>> >>>---------------------------------------------------------------------- >>> >>>Message: 1 >>>Date: Sat, 07 Jul 2012 14:39:56 +0200 >>>From: Robert Raszuk >>>To: "l2vpn@ietf.org" >>>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>>Message-ID: <4FF82E1C.6000009@raszuk.net> >>>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >>> >>>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. >>> >>>It proposed an interesting solution to apply algorithmically computed >>>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >>>option C is used. >>> >>>However I have a fundamental question .. from who the draft is >>>protecting the inter-as service ? >>> >>>Who other then participating ISPs can spoof a value of VPN label ? If >>>the solution is protecting from ISPs itself then I think it does not >>>help at all as corresponding ISPs/SPs still have full access to their >>>PEs and could inject packets to VPN sites at will. >>> >>>Moreover main issue with option C is not security (at least for the last >>>10+ years). Main issue with option C and MPLS is that participating >>>providers need to inject into each other's network all of their >>>participating PE's /32 addresses so the end to end MPLS LSP can be >>>build. Originally that was recommended to be done by mutual >>>redistribution to the IGP .. now the general recommendation is to use >>>labeled BGP (both IBGP and EBGP). >>> >>>So fundamental question to the authors ... who is the potential >>>attacker/spoofer this draft is aiming to protect from ? >>> >>>Best regards, >>>R. >>> >>> >>> >>> >>> >>>------------------------------ >>> >>>_______________________________________________ >>>L2vpn mailing list >>>L2vpn@ietf.org >>>https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>>End of L2vpn Digest, Vol 98, Issue 6 >>>************************************ >> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From balajivenkat299@gmail.com Mon Jul 9 08:09:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02EF11E80A4 for ; Mon, 9 Jul 2012 08:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07i2shzJen2a for ; Mon, 9 Jul 2012 08:09:57 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE25811E80A1 for ; Mon, 9 Jul 2012 08:09:56 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11171763ggn.31 for ; Mon, 09 Jul 2012 08:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s5DYlj3Y6dxHUgNLSRr4qDy2QA6X3dQ8T+1PzxzPaSQ=; b=Ii5fJPcLXGyzOlyFeHJaPbckQlYCEfrxsXXLkrXP1718j0TIG9tlkLSKMWfozitIxt 5KdeTAPTHuBQWIWOk37JPEcKwIW95m/+USGeYrDZzngNm1HwCRU9uAS5rvQ59iy10e9C LybwdWItvYVKSmG5WASHRqrm9Reg2F721OBpsfxBGjV+fXIbLtJ1BFw3HL52Qp3UKmHh rS+N79XFgRJ25kl8oJUdDoIvBScHTOUFk2Bw10ocbjz5U9ns3taHT2BYPw1nBDL9E0H0 9xHs38FItyAy8ePTe7nnoJf3ivAcbvV5O6NHmrKg4qZnaPN+2CPmtLhPhaxqn++fktRV E7GQ== MIME-Version: 1.0 Received: by 10.68.211.193 with SMTP id ne1mr20721203pbc.142.1341846620571; Mon, 09 Jul 2012 08:10:20 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 08:10:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jul 2012 20:40:20 +0530 Message-ID: Subject: Re: L2vpn Digest, Vol 98, Issue 6 From: Balaji venkat Venkataswami To: "Rogers, Josh" Content-Type: multipart/alternative; boundary=e89a8fb208e8298a4404c4670393 Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:09:58 -0000 --e89a8fb208e8298a4404c4670393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Josh, Robert, We had considered the option of IPsec. With respect to encrypting and decrypting at data rates that high we saw issues with respect to computation and power and time as well. While this may be ok for today's network speeds the higher speeds that would be achieved in future would effectively create the above complexity issues if it was done on the PE router (ingress and egress). While the CE based encryption might work, spoofing attacks and other unidirectional attacks may send garbled packets which will be sought to be decrypted thereby DOSing any decryptor. This would be counterproductive. Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be encrypted. If found to belong to a specific VPN that is of interest to the tapper/eavesdropper he can still take the traffic based on that label and decrypt it later on. The proposed scheme in the internet draft makes it difficult to even identify which label belongs to which VPN. Even if identified for a label amongst the set of labels, in order for the tapper to get all the traffic he / she has to guess all the labels, their respective time slices and in addition the innermost label which is digest whose algorithm has to be again guessed. So the proposed scheme provides several lines of defence against spoofing, unidirectional attacks and even eavesdropping. thanks and regards, balaji, shankar and bhargav On Mon, Jul 9, 2012 at 7:51 PM, Rogers, Josh wrote= : > While I don't necessarily agree with this draft's approach ("security > through obscurity" comes to mind), I'd like to point out that I do see a > need to assuage concerns about using Option C between operators. In my > part of the world, when I propose Option C to other operators, often the > idea is met with concern/resistance, seemingly because the other operator > has not done it before. Even internally, many of my colleagues are > concerned about security and the trust model in general. It appears to > me, to be no different than any other IP peering relationship, which > requires some basic 'trust', albeit not implicit trust. > > I think Robert's suggestion of leveraging encryption is a more ironclad > and reasonable solution to the problems presented here. However, I'd > still like to see an informative 'best practices' document at some point > that covered some basic policies that should be followed when peering wit= h > another ISP for LxVPN exchange. > > -Josh > > > > On 7/8/12 1:46 AM, "balaji venkat Venkataswami" > wrote: > > >Dear Robert, > > > >As mentioned in the earlier mail the following restriction is imposed on > >the > >Model C deployment=C5=A0 > > > >The consequence of this is that in model C the service providers must > >trust each other also in areas that are not shared. Therefore, model C i= s > >most commonly used today where a single operator uses several ASs on the > >backbone. In this case, implicit trust exists between the ASs because th= ey > >have the same operational control. > > > > > >In order to stretch this scheme to other Ases under different admin > >control this scheme helps out. > > > >Thanks and regards, > >Balaji venkat > > > >On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" > >wrote: > > > >>If you have received this digest without all the individual message > >>attachments you will need to update your digest options in your list > >>subscription. To do so, go to > >> > >>https://www.ietf.org/mailman/listinfo/l2vpn > >> > >>Click the 'Unsubscribe or edit options' button, log in, and set "Get > >>MIME or Plain Text Digests?" to MIME. You can set this option > >>globally for all the list digests you receive at this point. > >> > >> > >> > >>Send L2vpn mailing list submissions to > >> l2vpn@ietf.org > >> > >>To subscribe or unsubscribe via the World Wide Web, visit > >> https://www.ietf.org/mailman/listinfo/l2vpn > >>or, via email, send a message with subject or body 'help' to > >> l2vpn-request@ietf.org > >> > >>You can reach the person managing the list at > >> l2vpn-owner@ietf.org > >> > >>When replying, please edit your Subject line so it is more specific > >>than "Re: Contents of L2vpn digest..." > >> > >> > >>Today's Topics: > >> > >> 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... > >> (Robert Raszuk) > >> > >> > >>---------------------------------------------------------------------- > >> > >>Message: 1 > >>Date: Sat, 07 Jul 2012 14:39:56 +0200 > >>From: Robert Raszuk > >>To: "l2vpn@ietf.org" > >>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... > >>Message-ID: <4FF82E1C.6000009@raszuk.net> > >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > >> > >> > >>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. > >> > >>It proposed an interesting solution to apply algorithmically computed > >>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as > >>option C is used. > >> > >>However I have a fundamental question .. from who the draft is > >>protecting the inter-as service ? > >> > >>Who other then participating ISPs can spoof a value of VPN label ? If > >>the solution is protecting from ISPs itself then I think it does not > >>help at all as corresponding ISPs/SPs still have full access to their > >>PEs and could inject packets to VPN sites at will. > >> > >>Moreover main issue with option C is not security (at least for the las= t > >>10+ years). Main issue with option C and MPLS is that participating > >>providers need to inject into each other's network all of their > >>participating PE's /32 addresses so the end to end MPLS LSP can be > >>build. Originally that was recommended to be done by mutual > >>redistribution to the IGP .. now the general recommendation is to use > >>labeled BGP (both IBGP and EBGP). > >> > >>So fundamental question to the authors ... who is the potential > >>attacker/spoofer this draft is aiming to protect from ? > >> > >>Best regards, > >>R. > >> > >> > >> > >> > >> > >>------------------------------ > >> > >>_______________________________________________ > >>L2vpn mailing list > >>L2vpn@ietf.org > >>https://www.ietf.org/mailman/listinfo/l2vpn > >> > >> > >>End of L2vpn Digest, Vol 98, Issue 6 > >>************************************ > > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --e89a8fb208e8298a4404c4670393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Josh, Robert,

We had considered the option of IPsec= . With respect to encrypting and decrypting at data rates that high we saw = issues with respect to computation and power and time as well. While this m= ay be ok for today's network speeds the higher speeds that would be ach= ieved in future would effectively create the above complexity issues if it = was done on the PE router (ingress and egress). While the CE based encrypti= on might work, spoofing attacks and other unidirectional attacks may send g= arbled packets which will be sought to be decrypted thereby DOSing any decr= yptor. This would be counterproductive.

Also the inner label of a Option-C inter-AS MPLS VPN pa= cket cannot be encrypted. If found to belong to a specific VPN that is of i= nterest to the tapper/eavesdropper he can still take the traffic based on t= hat label and decrypt it later on.

The proposed scheme in the internet draft makes it diff= icult to even identify which label belongs to which VPN. Even if identified= for a label amongst the set of labels, in order for the tapper to get all = the traffic he / she has to guess all the labels, their respective time sli= ces and in addition the innermost label which is digest whose algorithm has= to be again guessed. So the proposed scheme provides several lines of defe= nce against spoofing, unidirectional attacks and even eavesdropping.

thanks and regards,
balaji, shankar and bhargav

On Mon, Jul 9, 2012 at 7:51 PM, Rogers, Josh <j= osh.rogers@twcable.com> wrote:

While I don't necessarily agree with thi= s draft's approach ("security
through obscurity" comes to mind), I'd like to point out that I do= see a
need to assuage concerns about using Option C between operators. =C2=A0In m= y
part of the world, when I propose Option C to other operators, often the idea is met with concern/resistance, seemingly because the other operator has not done it before. =C2=A0Even internally, many of my colleagues are concerned about security and the trust model in general. =C2=A0It appears t= o
me, to be no different than any other IP peering relationship, which
requires some basic 'trust', albeit not implicit trust.

I think Robert's suggestion of leveraging encryption is a more ironclad=
and reasonable solution to the problems presented here. =C2=A0However, I= 9;d
still like to see an informative 'best practices' document at some = point
that covered some basic policies that should be followed when peering with<= br> another ISP for LxVPN exchange.

-Josh

On 7/8/12 1:46 AM, "balaji venkat Venkataswami"

<bal= ajivenkat299@gmail.com> wrote:

>Dear Robert,
>
>As mentioned in the earlier mail the following restriction is imposed o= n
>the
>Model C deployment=C5=A0
>
>The consequence of this is that in model C the service providers must >trust each other also in areas that are not shared. Therefore, model C = is
>most commonly used today where a single operator uses several ASs on th= e
>backbone. In this case, implicit trust exists between the ASs because t= hey
>have the same operational control.
>
>
>In order to stretch this scheme to other Ases under different admin
>control this scheme helps out.
>
>Thanks and regards,
>Balaji venkat
>
>On 08/07/12 12:30 AM, "l= 2vpn-request@ietf.org" <l2vpn-request@ietf.org>
>wrote:
>
>>If you have received this digest without all the individual message=
>>attachments you will need to update your digest options in your lis= t
>>subscription. =C2=A0To do so, go to
>>
>>https://www.ietf.org/mailman/listinfo/l2vpn
>>
>>Click the 'Unsubscribe or edit options' button, log in, and= set "Get
>>MIME or Plain Text Digests?" to MIME. =C2=A0You can set this o= ption
>>globally for all the list digests you receive at this point.
>>
>>
>>
>>Send L2vpn mailing list submissions to
>> =C2=A0 =C2=A0 =C2=A0l2vpn@ietf.o= rg
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>> =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/l2vpn=
>>or, via email, send a message with subject or body 'help' t= o
>> =C2=A0 =C2=A0 =C2=A0l2vp= n-request@ietf.org
>>
>>You can reach the person managing the list at
>> =C2=A0 =C2=A0 =C2=A0l2vpn-= owner@ietf.org
>>
>>When replying, please edit your Subject line so it is more specific=
>>than "Re: Contents of L2vpn digest..."
>>
>>
>>Today's Topics:
>>
>> =C2=A0 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >> =C2=A0 =C2=A0 =C2=A0(Robert Raszuk)
>>
>>
>>-------------------------------------------------------------------= ---
>>
>>Message: 1
>>Date: Sat, 07 Jul 2012 14:39:56 +0200
>>From: Robert Raszuk <robert= @raszuk.net>
>>To: "l2vpn@ietf.org"= ; <l2vpn@ietf.org>
>>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...
>>Message-ID: <4FF8= 2E1C.6000009@raszuk.net>
>>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>>
>>
>>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt.<= br> >>
>>It proposed an interesting solution to apply algorithmically comput= ed
>>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as<= br> >>option C is used.
>>
>>However I have a fundamental question .. from who the draft is
>>protecting the inter-as service ?
>>
>>Who other then participating ISPs can spoof a value of VPN label ? = If
>>the solution is protecting from ISPs itself then I think it does no= t
>>help at all as corresponding ISPs/SPs still have full access to the= ir
>>PEs and could inject packets to VPN sites at will.
>>
>>Moreover main issue with option C is not security (at least for the= last
>>10+ years). Main issue with option C and MPLS is that participating=
>>providers need to inject into each other's network all of their=
>>participating PE's /32 addresses so the end to end MPLS LSP can= be
>>build. Originally that was recommended to be done by mutual
>>redistribution to the IGP .. now the general recommendation is to u= se
>>labeled BGP (both IBGP and EBGP).
>>
>>So fundamental question to the authors ... who is the potential
>>attacker/spoofer this draft is aiming to protect from ?
>>
>>Best regards,
>>R.
>>
>>
>>
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>L2vpn mailing list
>>L2vpn@ietf.org
>>https://www.ietf.org/mailman/listinfo/l2vpn
>>
>>
>>End of L2vpn Digest, Vol 98, Issue 6
>>************************************
>
>

This E-mail and any of its attachments may contain Time Warner = Cable proprietary information, which is privileged, confidential, or subjec= t to copyright belonging to Time Warner Cable. This E-mail is intended sole= ly for the use of the individual or entity to which it is addressed. If you= are not the intended recipient of this E-mail, you are hereby notified tha= t any dissemination, distribution, copying, or action taken in relation to = the contents of and attachments to this E-mail is strictly prohibited and m= ay be unlawful. If you have received this E-mail in error, please notify th= e sender immediately and permanently delete the original and any copy of th= is E-mail and any printout.

--e89a8fb208e8298a4404c4670393-- From balajivenkat299@gmail.com Mon Jul 9 08:46:43 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596AF11E80E6; Mon, 9 Jul 2012 08:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+gnc634ta8J; Mon, 9 Jul 2012 08:46:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3C11E80E1; Mon, 9 Jul 2012 08:46:42 -0700 (PDT) Received: by yhq56 with SMTP id 56so12796079yhq.31 for ; Mon, 09 Jul 2012 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v84J3gYn1WKSMDFsLG6o/9fE8IR9D+Tsc0NsH4i178c=; b=VKGJt9oCtI5/Hdyz6NAM2ed40ZlMrYXGmFZDdeFJ5fzGwVQWFMZNJrIZlNudu4lSVL 8Y0hs7+641xl0dcFljOyaKOPWGZRWIFVOedTinNGes1zpZ4MRIhRxFAskG/HRp4jUXgn cNh8k8ygnQ3JpZW8OAKO5crRr3Jt+SQO0GtZ99aFdZsZ3WS3olZynOnxygF3AvWw1C0i kGR2w4nyTnY/Qw5YpI6nlr6ipPxQOTtjgPeB3Ns2ppYoOBGz/9pJkd6brZLy6N1acCSM CLYXhId9KOLdPXeqcAVhGaJ+womH0/TcSHRPcZigKgs6NPzmPD1c/LDSYgQG2AxL2MEU 7yuA== MIME-Version: 1.0 Received: by 10.68.195.198 with SMTP id ig6mr61976472pbc.92.1341848826698; Mon, 09 Jul 2012 08:47:06 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 08:47:06 -0700 (PDT) In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> Date: Mon, 9 Jul 2012 21:17:06 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: Tal Mizrahi Content-Type: multipart/alternative; boundary=047d7b10c8a7a85e1a04c467867d Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:46:43 -0000 --047d7b10c8a7a85e1a04c467867d Content-Type: text/plain; charset=ISO-8859-1 Dear Tal, Comments inline On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi wrote: > Hi Balaji, > > A few clarification questions - I think it would be good to clarify these > issues in the draft: > 1. Since the label hopping mechanism relies on PTP, I understand that > PTP traffic itself does not use label hopping, right? > The PTP traffic itself does not use label hopping. > 2. Is there something preventing the attacker from attacking PTP, > thus causing DoS to the data plane? > It would be difficult for the attacker to identify which LSP is the PTP LSP for a specific VPN traffic (flow / set of flows) that is protected by this scheme. There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffic protected by this scheme. 3. Is the "additional label" similar to an Integrity Check Value (ICV) > computed over part of the packet header? > It serves as a digest from which certain specific bits are chosen to become the innermost label. Which bits are chosen depends upon the bitmask exchanged during the control plane. > 4. Is there something in your approach that would prevent an attacker > from a replay attack? > For a reply attack to succeed, the replay should time the labels correctly otherwise the traffic gets rejected. 5. Looking at "Algorithm 3" I was not sure: does the receiver check > two consequent time slots? I could not see such a check. I am referring to > a case where the sender transmits at the end of a time slot, and the packet > is received at the beginning of the next time slot. That would mean the > receiver has to be able to tolerate two concurrent time slots, right? > Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. Maybe a little more fine tuning is required on this. > 6. The security parameters K, TS, A, I are exchanged over a secure > link, which basically assumes there is a pre-shared key between the peer > PEs. A naive question would be: how is your approach better than just using > a standard ICV, based on the existing pre-shared key? > While the ICV may protect against modification of the inner payload one cannot prevent spoofing attacks if the algorithm for the ICV is deduced. Our scheme provides facility to change the labels from time slice to time slice so that guessing what packet belongs to which VPN traffic itself becomes difficult. This is the first line of defense. If we provide ICV alone we protect against modification but not with replay attacks. The proposed scheme protects against VPN traffic identification (so replay attacks cannot be made) and modification as well through the ICV which is the innermost label. thanks and regards, balaji , shankar and bhargav > > Tal. > > --047d7b10c8a7a85e1a04c467867d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <talmi@marvell.com>= ; wrote:

Hi Balaji,

A few clarification questions - I think it would be good to clarify these i= ssues in the draft:
1. =A0 =A0 =A0Since the label hopping mechanism relies on PTP, I understand= that PTP traffic itself does not use label hopping, right?

The PTP traffic itself does not use label hopping.
=A0
2. =A0 =A0 =A0Is there something preventing the attacker from attacking PTP= , thus causing DoS to the data plane?

I= t would be difficult for the attacker to identify which LSP is the PTP LSP = for a specific VPN traffic (flow / set of flows) that is protected by this = scheme. There is no information except on the ingress and egress PEs that i= dentifies which is the PTP LSP for a particular VPN traffic protected by th= is scheme.=A0

3. =A0 =A0 =A0Is the "additional label" similar to an Integrity C= heck Value (ICV) computed over part of the packet header?
<= div>
It serves as a digest from which certain specific bits a= re chosen to become the innermost label. Which bits are chosen depends upon= the bitmask exchanged during the control plane.

=A0
4. =A0 =A0 =A0Is there something in your approach that would prevent an att= acker from a replay attack?

For a reply= attack to succeed, the replay should time the labels correctly otherwise t= he traffic gets rejected.

5. =A0 =A0 =A0Looking at "Algorithm 3" I was not sure: does the r= eceiver check two consequent time slots? I could not see such a check. I am= referring to a case where the sender transmits at the end of a time slot, = and the packet is received at the beginning of the next time slot. That wou= ld mean the receiver has to be able to tolerate two concurrent time slots, = right?

Yes. It is available as +or- 1 unit (usual= ly seconds) in the algorithm. Maybe a little more fine tuning is required o= n this.
=A0
6. =A0 =A0 =A0The security parameters K, TS, A, I are exchanged over a secu= re link, which basically assumes there is a pre-shared key between the peer= PEs. A naive question would be: how is your approach better than just usin= g a standard ICV, based on the existing pre-shared key?

While the ICV may protect against modifica= tion of the inner payload one cannot prevent spoofing attacks if the algori= thm for the ICV is deduced. Our scheme provides facility to change the labe= ls from time slice to time slice so that guessing what packet belongs to wh= ich VPN traffic itself becomes difficult. This is the first line of defense= . If we provide ICV alone we protect against modification but not with repl= ay attacks. The proposed scheme protects against VPN traffic identification= (so replay attacks cannot be made) and modification as well through the IC= V which is the innermost label.

thanks and regards,
balaji , shankar and bhar= gav

Tal.

--047d7b10c8a7a85e1a04c467867d-- From robert@raszuk.net Mon Jul 9 08:47:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6911E80F2 for ; Mon, 9 Jul 2012 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 RatPjVB5BwuG for ; Mon, 9 Jul 2012 08:47:00 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 31D9D11E80F3 for ; Mon, 9 Jul 2012 08:47:00 -0700 (PDT) Received: (qmail 32133 invoked by uid 399); 9 Jul 2012 15:47:25 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.219.81) by mail1310.opentransfer.com with ESMTPM; 9 Jul 2012 15:47:25 -0000 X-Originating-IP: 83.31.219.81 Message-ID: <4FFAFD0B.4070102@raszuk.net> Date: Mon, 09 Jul 2012 17:47:23 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Balaji venkat Venkataswami Subject: Re: L2vpn Digest, Vol 98, Issue 6 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 15:47:01 -0000 Hi Balaji, > Dear Josh, Robert, > > We had considered the option of IPsec. With respect to encrypting and > decrypting at data rates that high we saw issues with respect to > computation and power and time as well. While this may be ok for today's > network speeds the higher speeds that would be achieved in future would > effectively create the above complexity issues if it was done on the PE > router (ingress and egress). While the CE based encryption might work, > spoofing attacks and other unidirectional attacks may send garbled > packets which will be sought to be decrypted thereby DOSing any > decryptor. This would be counterproductive. The ASBR - ASBR local link encryption does not suffer from any of the above. > Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be > encrypted. If found to belong to a specific VPN that is of interest to > the tapper/eavesdropper he can still take the traffic based on that > label and decrypt it later on. > > The proposed scheme in the internet draft makes it difficult to even > identify which label belongs to which VPN. Even if identified for a > label amongst the set of labels, in order for the tapper to get all the > traffic he / she has to guess all the labels, their respective time > slices and in addition the innermost label which is digest whose > algorithm has to be again guessed. So the proposed scheme provides > several lines of defence against spoofing, unidirectional attacks and > even eavesdropping. In the same time the proposed scheme makes the troubleshooting impossible. How ISPs would decode that for some option C VPNs their customer packets go via ASBR to ASBR link or not ? Same for billing. To the best of my knowledge ISPs charge differently for the portion of inter-as service. There is need to provide on a per VPN stats from ASBR router. How in this scheme per VPN granularity of traffic statistics will be accomplished for billing purposes ? That's actually one of the key reasons for option B popularity today. Thx, R. > > thanks and regards, > balaji, shankar and bhargav From balajivenkat299@gmail.com Mon Jul 9 09:00:07 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE18B11E80B3 for ; Mon, 9 Jul 2012 09:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URZ14BXjDtlX for ; Mon, 9 Jul 2012 09:00:05 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3AE11E8097 for ; Mon, 9 Jul 2012 09:00:05 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11234577ggn.31 for ; Mon, 09 Jul 2012 09:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ldAHv1k4vHyeUbHJMfRWjbw9XnGv6SY82EaQ1jt2+EQ=; b=Ao2K7pjIaxvVuaE4CKPKtlLKksqaoVbnOe9MRmH+iS26ALKyfEiyWc8UzEZckgHQqC PAYKP91OkHG+nb1r2eze2A3rM4Ix7EtrcSifok5DqIqBhoN9ClrxIOdb81zQ/SusxM3X 8p+WV6y8KX9/AOyzp41sy0zaNK2dVOdKq7HDOesAbOcXZHUIPs2WMJVqB+QW7BhMOuoN eFiGtwW7pVbj6IXfLn+f/0KsY/t1CGKshjGbjy2XjMmx+6HKVRYzY84GEFyarOBkn+lk nTA1htgQQR8Rah22lCoHmv1w8X3zhfgpLw0KHV5ryP2uSmx16FkNSQHMhQAi3B7+LT2Y Ekbg== MIME-Version: 1.0 Received: by 10.68.134.201 with SMTP id pm9mr62598539pbb.49.1341849629948; Mon, 09 Jul 2012 09:00:29 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 09:00:29 -0700 (PDT) In-Reply-To: <4FFAFD0B.4070102@raszuk.net> References: <4FFAFD0B.4070102@raszuk.net> Date: Mon, 9 Jul 2012 21:30:29 +0530 Message-ID: Subject: Re: L2vpn Digest, Vol 98, Issue 6 From: Balaji venkat Venkataswami To: robert@raszuk.net Content-Type: multipart/alternative; boundary=047d7b10d02188fc0704c467b652 Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:00:07 -0000 --047d7b10d02188fc0704c467b652 Content-Type: text/plain; charset=ISO-8859-1 Dear Robert, Comments inline On Mon, Jul 9, 2012 at 9:17 PM, Robert Raszuk wrote: > Hi Balaji, > > > > Dear Josh, Robert, > >> >> We had considered the option of IPsec. With respect to encrypting and >> decrypting at data rates that high we saw issues with respect to >> computation and power and time as well. While this may be ok for today's >> network speeds the higher speeds that would be achieved in future would >> effectively create the above complexity issues if it was done on the PE >> router (ingress and egress). While the CE based encryption might work, >> spoofing attacks and other unidirectional attacks may send garbled >> packets which will be sought to be decrypted thereby DOSing any >> decryptor. This would be counterproductive. >> > > The ASBR - ASBR local link encryption does not suffer from any of the > above. If specific set of VPNs alone are to be subject to the scheme then the ASBR which encrypts on the local link between ASBR and ASBR will not know which VPN inner label whose traffic is to be subjected to encryption. Otherwise it would have to encrypt all traffic since it finds that some of the VPNs are subject to this scheme. This would be an overkill. > > > Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be >> encrypted. If found to belong to a specific VPN that is of interest to >> the tapper/eavesdropper he can still take the traffic based on that >> label and decrypt it later on. >> >> The proposed scheme in the internet draft makes it difficult to even >> identify which label belongs to which VPN. Even if identified for a >> label amongst the set of labels, in order for the tapper to get all the >> traffic he / she has to guess all the labels, their respective time >> slices and in addition the innermost label which is digest whose >> algorithm has to be again guessed. So the proposed scheme provides >> several lines of defence against spoofing, unidirectional attacks and >> even eavesdropping. >> > > > In the same time the proposed scheme makes the troubleshooting impossible. > How ISPs would decode that for some option C VPNs their customer packets go > via ASBR to ASBR link or not ? > Could you please explain a bit more on this. We assume that all Option-C traffic has to go through ASBR to ASBR link. > > Same for billing. To the best of my knowledge ISPs charge differently for > the portion of inter-as service. There is need to provide on a per VPN > stats from ASBR router. How in this scheme per VPN granularity of traffic > statistics will be accomplished for billing purposes ? That's actually one > of the key reasons for option B popularity today. > > The billing can be done as follows. Collect the traffic statistics for all VPN labels as if they were separate VPN labels each for a specific VPN. At the egress PE collate statistics coming towards it based on a set of labels instead of a single label in the regular case. Collate this data with the ASBR statistics (identifying the egress PE by the outer label) and do the billing. Hope this helps. Your inputs would be most useful. thanks and regards, balaji venkat > Thx, > > R. > > > > > > > > >> thanks and regards, >> balaji, shankar and bhargav >> > > > --047d7b10d02188fc0704c467b652 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Robert,

Comments inline

On Mon, Jul 9, 2012 at 9:17 PM, Robert Raszuk <= robert@raszuk.net> wrote:

Hi Balaji,

> Dear Josh, Robert,

We had considered the option of IPsec. With respect to encrypting and
decrypting at data rates that high we saw issues with respect to
computation and power and time as well. While this may be ok for today'= s
network speeds the higher speeds that would be achieved in future would
effectively create the above complexity issues if it was done on the PE
router (ingress and egress). While the CE based encryption might work,
spoofing attacks and other unidirectional attacks may send garbled
packets which will be sought to be decrypted thereby DOSing any
decryptor. This would be counterproductive.

The ASBR - ASBR local link encryption does not suffer from any of the above= .

If specific set of VPNs alone are to be s= ubject to the scheme then the ASBR which encrypts on the local link between= ASBR and ASBR will not know which VPN inner label whose traffic is to be s= ubjected to encryption. Otherwise it would have to encrypt all traffic sinc= e it finds that some of the VPNs are subject to this scheme. This would be = an overkill.

Also the inner label of a Option-C inter-AS MPLS VPN packet cannot be
encrypted. If found to belong to a specific VPN that is of interest to
the tapper/eavesdropper he can still take the traffic based on that
label and decrypt it later on.

The proposed scheme in the internet draft makes it difficult to even
identify which label belongs to which VPN. Even if identified for a
label amongst the set of labels, in order for the tapper to get all the
traffic he / she has to guess all the labels, their respective time
slices and in addition the innermost label which is digest whose
algorithm has to be again guessed. So the proposed scheme provides
several lines of defence against spoofing, unidirectional attacks and
even eavesdropping.

In the same time the proposed scheme makes the troubleshooting impossible. = How ISPs would decode that for some option C VPNs their customer packets go= via ASBR to ASBR link or not ?

Could y= ou please explain a bit more on this. We assume that all Option-C traffic h= as to go through ASBR to ASBR link.=A0

=A0

Same for billing. To the best of my knowledge ISPs charge differently for t= he portion of inter-as service. There is need to provide on a per VPN stats= from ASBR router. How in this scheme per VPN granularity of traffic statis= tics will be accomplished for billing purposes ? That's actually one of= the key reasons for option B popularity today.

The billing can be done as follows. Co= llect the traffic statistics for all VPN labels as if they were separate VP= N labels each for a specific VPN. At the egress PE collate statistics comin= g towards it based on a set of labels instead of a single label in the regu= lar case. Collate this data with the ASBR statistics (identifying the egres= s PE by the outer label) and do the billing.=A0

Hope this helps.

Your inputs w= ould be most useful.

thanks and regards,
balaji venkat
=A0
Thx,

R.

thanks and regards,
balaji, shankar and bhargav

--047d7b10d02188fc0704c467b652-- From robert@raszuk.net Mon Jul 9 09:13:45 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD87621F8618 for ; Mon, 9 Jul 2012 09:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 iJF9uVOyWo0H for ; Mon, 9 Jul 2012 09:13:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5C21F85F7 for ; Mon, 9 Jul 2012 09:13:43 -0700 (PDT) Received: (qmail 2567 invoked by uid 399); 9 Jul 2012 16:14:08 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:robert@raszuk.net@83.31.219.81) by mail1310.opentransfer.com with ESMTPM; 9 Jul 2012 16:14:08 -0000 X-Originating-IP: 83.31.219.81 Message-ID: <4FFB034F.3080302@raszuk.net> Date: Mon, 09 Jul 2012 18:14:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Balaji venkat Venkataswami Subject: Re: L2vpn Digest, Vol 98, Issue 6 References: <4FFAFD0B.4070102@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:13:45 -0000 > If specific set of VPNs alone are to be subject to the scheme I don't think this is for specific VPNs. It would be applicable for all VPNs using option C on a given link between pair of peering ASBRs. > encryption. Otherwise it would have to encrypt all traffic since it > finds that some of the VPNs are subject to this scheme. This would be an > overkill. I do not think so. If there is any risk that my link is insecure between trusted parties it seems wise to make it secure for all control plane and data plane traffic which traverses such link. > In the same time the proposed scheme makes the troubleshooting > impossible. How ISPs would decode that for some option C VPNs their > customer packets go via ASBR to ASBR link or not ? > > Could you please explain a bit more on this. We assume that all Option-C > traffic has to go through ASBR to ASBR link. So do I. Let's assume customer X reports that he can not ping his remote sites. Today NOC does: - Logs into PE and see what VPN label his remote PE peer advertised - Enabled filter on the ASBR and issues a vrf ping on the PE or CE - Has ability to see or not his customer packets With your scheme such filtering becomes impossible. So does the troubleshooting. > Same for billing. To the best of my knowledge ISPs charge > differently for the portion of inter-as service. There is need to > provide on a per VPN stats from ASBR router. How in this scheme per > VPN granularity of traffic statistics will be accomplished for > billing purposes ? That's actually one of the key reasons for option > B popularity today. > > > The billing can be done as follows. Collect the traffic statistics for > all VPN labels as if they were separate VPN labels each for a specific > VPN. At the egress PE collate statistics coming towards it based on a > set of labels instead of a single label in the regular case. Collate > this data with the ASBR statistics (identifying the egress PE by the > outer label) and do the billing. If there are many PEs and their labels restart that is a lot of additional complexity and data correlation as compared with today. Many thx, R. From balajivenkat299@gmail.com Mon Jul 9 09:46:18 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951811E814D for ; Mon, 9 Jul 2012 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSrE+I7w3Y3y for ; Mon, 9 Jul 2012 09:46:17 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 206CC11E814C for ; Mon, 9 Jul 2012 09:46:17 -0700 (PDT) Received: by ghbg16 with SMTP id g16so11311320ghb.31 for ; Mon, 09 Jul 2012 09:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=B8M7oY+bR2W3wkt6O1pPYahOJMcUBkGTirJoqcqVS+U=; b=JrRKdBB/zjJ6fZi4JhcSM2jEnkB4/lAFbAJwTUQLV95f1nn/L9o+BV/dhe9B3w2gTP vVffpkmAM2cAqNu9QF1YGsy+TFlYzVpTPkWe32s5VYnIDJK901aPqX1QzPbtbWMv6pSU 8+B8+RfwhdOLWCxxOJ835PVqscp9uB1MEo99YzFfhMop/JmPBLjQCeSete/G3OuTW25t NzVbxDL0RiOothKQ7yVyFh6WJClP47drDnULsma6fZZe7eFCuiRXenrNos7oa1Jo304t YOgeLfH+Cyi9r+zh9GkTUdTYW0CPwS20krbjUn68WKkWgU+o8BwkO+bFNQSD4AcPDN74 t74Q== MIME-Version: 1.0 Received: by 10.66.77.71 with SMTP id q7mr66970829paw.0.1341852401425; Mon, 09 Jul 2012 09:46:41 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Mon, 9 Jul 2012 09:46:41 -0700 (PDT) Date: Mon, 9 Jul 2012 22:16:41 +0530 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Balaji venkat Venkataswami To: l2vpn@ietf.org, Robert Raszuk Content-Type: multipart/alternative; boundary=f46d042f9decba5c8004c4685b7f Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:46:18 -0000 --f46d042f9decba5c8004c4685b7f Content-Type: text/plain; charset=ISO-8859-1 Dear Robert, Message: 4 Date: Mon, 09 Jul 2012 18:14:07 +0200 From: Robert Raszuk To: Balaji venkat Venkataswami Cc: "l2vpn@ietf.org" , Shankar Raman M J , Bhargav Bhikkaji Subject: Re: L2vpn Digest, Vol 98, Issue 6 Message-ID: <4FFB034F.3080302@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed > If specific set of VPNs alone are to be subject to the scheme I don't think this is for specific VPNs. It would be applicable for all VPNs using option C on a given link between pair of peering ASBRs. This is where the scheme proposed differs. One can select a specific VPN or set of VPNs carried over Option-C to be subject to this scheme. Also it may be possible that Option-A and B are deployed over the same ASBR. How do we distinguish which is A and B Options and which is C ? We would find ourselves in a quandry there. > encryption. Otherwise it would have to encrypt all traffic since it > finds that some of the VPNs are subject to this scheme. This would be an > overkill. I do not think so. If there is any risk that my link is insecure between trusted parties it seems wise to make it secure for all control plane and data plane traffic which traverses such link. Worried about the scalability aspects here. Line rates between ASBRs are high, how would one cope with so much cycles of encryption and decryption ? > In the same time the proposed scheme makes the troubleshooting > impossible. How ISPs would decode that for some option C VPNs their > customer packets go via ASBR to ASBR link or not ? > > Could you please explain a bit more on this. We assume that all Option-C > traffic has to go through ASBR to ASBR link. So do I. Let's assume customer X reports that he can not ping his remote sites. Today NOC does: - Logs into PE and see what VPN label his remote PE peer advertised - Enabled filter on the ASBR and issues a vrf ping on the PE or CE - Has ability to see or not his customer packets With your scheme such filtering becomes impossible. So does the troubleshooting. One possibility is to actually use a certain fixed label for vrf ping alone. This can be done without too much complexity. Reachability can be tested this way. > Same for billing. To the best of my knowledge ISPs charge > differently for the portion of inter-as service. There is need to > provide on a per VPN stats from ASBR router. How in this scheme per > VPN granularity of traffic statistics will be accomplished for > billing purposes ? That's actually one of the key reasons for option > B popularity today. > > > The billing can be done as follows. Collect the traffic statistics for > all VPN labels as if they were separate VPN labels each for a specific > VPN. At the egress PE collate statistics coming towards it based on a > set of labels instead of a single label in the regular case. Collate > this data with the ASBR statistics (identifying the egress PE by the > outer label) and do the billing. If there are many PEs and their labels restart that is a lot of additional complexity and data correlation as compared with today. This happens for single labels anyways but this is a small price to pay for more security I guess. Besides we are doing this for select VPN customers only. Hope this helps. thanks and regards, balaji venkat Many thx, R. --f46d042f9decba5c8004c4685b7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Robert,

Message: 4
Date: Mon, 09 Jul 2012 18:14:07 +0200
From: Robert Raszuk <robert@raszuk.net>
To: Balaji venkat Venkataswami <balajivenkat299@gmail.com>
Cc: "l= 2vpn@ietf.org" <l2vpn@ietf.org>, Shankar Raman M J
=A0 =A0 =A0 =A0 <mjsraman@gmail.com>, =A0 Bhargav Bhikkaji <bharbhi@gmail.com= >
Subject: Re: L2vpn Digest, Vol 98, Issue 6
Message-ID: <4FFB034F.3080302@raszuk.net>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed=

> If specific set of VPNs alone are to be subject to the sche= me

I don't think this is for specific VPNs. It would be applicable= for all
VPNs using option C on a given link between pair of peering ASBRs.

<balajivenkat> This is where the scheme proposed differs. One can= select
a specific VPN or set of VPNs carried over Option-C to be subje= ct to this scheme.
Also it may be possible that Option-A and B ar= e deployed over the same ASBR.

How do we distinguish which is A and B Options and which is C ?
<= div>We would find ourselves in a quandry there.

> e= ncryption. Otherwise it would have to encrypt all traffic since it > finds that some of the VPNs are subject to this scheme. This woul= d be an
> overkill.

I do not think so. If there is any risk that my link is insecure be= tween
trusted parties it seems wise to make it secure for all control plane<= /span>
and data plane traffic which traverses such link.

<balajivenkat> Worried about the scalability aspects here. Line r= ates between
ASBRs are high, how would one cope with so much cycl= es of encryption and
decryption ?

> =A0 =A0= In the same time the proposed scheme makes the troubleshooting
> =A0 =A0 impossible. How ISPs would decode that for some option C = VPNs their
> =A0 =A0 customer packets go via ASBR to ASBR link or not ?=
>
> Could you please explain a bit more on this. We assume that all O= ption-C
> traffic has to go through ASBR to ASBR link.

So do I.

Let's assume customer X reports that he can not ping his remote= sites.

Today NOC does:

- Logs into PE and see what VPN label his remote PE peer advertised=
- Enabled filter on the ASBR and issues a vrf ping on the PE or CE
- Has ability to see or not his customer packets

With your scheme such filtering becomes impossible. So does the
troubleshooting.

<balajivenkat> One possibility is to actually use a certain fixed= label for
vrf ping alone. This can be done without too much comp= lexity. Reachability
can be tested this way.

> = =A0 =A0 Same for billing. To the best of my knowledge ISPs charge > =A0 =A0 differently for the portion of inter-as service. There is= need to
> =A0 =A0 provide on a per VPN stats from ASBR router. How in this = scheme per
> =A0 =A0 VPN granularity of traffic statistics will be accomplishe= d for
> =A0 =A0 billing purposes ? That's actually one of the key rea= sons for option
> =A0 =A0 B popularity today.
>
>
> The billing can be done as follows. Collect the traffic statistic= s for
> all VPN labels as if they were separate VPN labels each for a spe= cific
> VPN. At the egress PE collate statistics coming towards it based = on a
> set of labels instead of a single label in the regular case. Coll= ate
> this data with the ASBR statistics (identifying the egress PE by = the
> outer label) and do the billing.

If there are many PEs and their labels restart that is a lot of
additional complexity and data correlation as compared with today.

<balajivenkat> This happens for single labels anyways but this is= a small
price to pay for more security I guess. Besides we are d= oing this for select
VPN customers only.

Hope this helps.

thanks and regards,
balaji venkat

Many thx,
R.
--f46d042f9decba5c8004c4685b7f-- From gregimirsky@gmail.com Mon Jul 9 10:45:12 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128DB11E81B4; Mon, 9 Jul 2012 10:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YfAMaQ4eOgF; Mon, 9 Jul 2012 10:45:11 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D349811E81AB; Mon, 9 Jul 2012 10:45:10 -0700 (PDT) Received: by ghbg16 with SMTP id g16so11383974ghb.31 for ; Mon, 09 Jul 2012 10:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SiSsbeTZdOPf05Nj2YDoB454DqsvArNVa1fwIUBXdKU=; b=G7rgmMDM/NF04EApbm5ejEpd5ag1zF3Q/VJLF22sG1Vux/Nfw61oCI6U6Pf/C8/ypN h2JyMYp4LMgxFLOP75q+m4pZniEMhHnqvvCrPt78p6wDNJEWHThHAWB7bUfZ5n5GLvYy PECdWOWbdi4CnO+U5jIPZWIuh9K9sDA7hmC3+GrS0TyYKoLlLtS2XWDoy6exMCWb0TU2 LQdky7w40TjNOcUqpQuqV8OeoQZuYVer0zYBv3c6HuDXI3c1g2MXZapV4LfmNhTzFmSF 7cWriig2QK91YdyEDx4IyIhP12buv6aIHNqE03vs4GJdWuOajis9qlA6FIMTEJx4xyPm NMrw== MIME-Version: 1.0 Received: by 10.236.186.101 with SMTP id v65mr29269456yhm.23.1341855936064; Mon, 09 Jul 2012 10:45:36 -0700 (PDT) Received: by 10.100.89.5 with HTTP; Mon, 9 Jul 2012 10:45:35 -0700 (PDT) In-Reply-To: References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> Date: Mon, 9 Jul 2012 10:45:35 -0700 Message-ID: Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... From: Greg Mirsky To: Balaji venkat Venkataswami Content-Type: multipart/alternative; boundary=20cf3054a0af68abeb04c4692e80 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "robert@raszuk.net" , "tictoc@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:45:12 -0000 --20cf3054a0af68abeb04c4692e80 Content-Type: text/plain; charset=ISO-8859-1 Dear Balaji, you've said " There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffic protected by this scheme." AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP updates. Would that compromise your method? Regards, Greg On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami < balajivenkat299@gmail.com> wrote: > Dear Tal, > > Comments inline > > On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi wrote: > >> Hi Balaji, >> >> A few clarification questions - I think it would be good to clarify these >> issues in the draft: >> 1. Since the label hopping mechanism relies on PTP, I understand >> that PTP traffic itself does not use label hopping, right? >> > > The PTP traffic itself does not use label hopping. > > >> 2. Is there something preventing the attacker from attacking PTP, >> thus causing DoS to the data plane? >> > > It would be difficult for the attacker to identify which LSP is the PTP > LSP for a specific VPN traffic (flow / set of flows) that is protected by > this scheme. There is no information except on the ingress and egress PEs > that identifies which is the PTP LSP for a particular VPN traffic protected > by this scheme. > > 3. Is the "additional label" similar to an Integrity Check Value >> (ICV) computed over part of the packet header? >> > > It serves as a digest from which certain specific bits are chosen to > become the innermost label. Which bits are chosen depends upon the bitmask > exchanged during the control plane. > > >> 4. Is there something in your approach that would prevent an >> attacker from a replay attack? >> > > For a reply attack to succeed, the replay should time the labels correctly > otherwise the traffic gets rejected. > > 5. Looking at "Algorithm 3" I was not sure: does the receiver check >> two consequent time slots? I could not see such a check. I am referring to >> a case where the sender transmits at the end of a time slot, and the packet >> is received at the beginning of the next time slot. That would mean the >> receiver has to be able to tolerate two concurrent time slots, right? >> > > Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. > Maybe a little more fine tuning is required on this. > > >> 6. The security parameters K, TS, A, I are exchanged over a secure >> link, which basically assumes there is a pre-shared key between the peer >> PEs. A naive question would be: how is your approach better than just using >> a standard ICV, based on the existing pre-shared key? >> > > While the ICV may protect against modification of the inner payload one > cannot prevent spoofing attacks if the algorithm for the ICV is deduced. > Our scheme provides facility to change the labels from time slice to time > slice so that guessing what packet belongs to which VPN traffic itself > becomes difficult. This is the first line of defense. If we provide ICV > alone we protect against modification but not with replay attacks. The > proposed scheme protects against VPN traffic identification (so replay > attacks cannot be made) and modification as well through the ICV which is > the innermost label. > > thanks and regards, > balaji , shankar and bhargav > >> >> Tal. >> >> > --20cf3054a0af68abeb04c4692e80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Balaji,
you've said " There is no information except on th= e ingress and egress PEs that=20 identifies which is the PTP LSP for a particular VPN traffic protected=20 by this scheme."
AFAIK, notion of PTP LSP is not limited to PE'= s but to all P's that get PTP updates. Would that compromise your metho= d?

Regards,
Greg

On Mon, Jul 9,= 2012 at 8:47 AM, Balaji venkat Venkataswami <balajivenkat299@gma= il.com> wrote:

Dear Tal,

Comments inline=

On Mon, Jul 9, 2012 at= 11:44 AM, Tal Mizrahi <talmi@marvell.com> wrote:

Hi Balaji,

A few clarification questions - I think it would be good to clarify these i= ssues in the draft:
1. =A0 =A0 =A0Since the label hopping mechanism relies on PTP, I understand= that PTP traffic itself does not use label hopping, right?

The PTP traffic itself does not use label hoppin= g.

=A0
2. =A0 =A0 =A0Is there something preventing the attacker from attacking PTP= , thus causing DoS to the data plane?

=
It would be difficult for the attacker to identify which LSP is the PT= P LSP for a specific VPN traffic (flow / set of flows) that is protected by= this scheme. There is no information except on the ingress and egress PEs = that identifies which is the PTP LSP for a particular VPN traffic protected= by this scheme.=A0

3. =A0 =A0 =A0Is the "additional label" similar to an Integrity C= heck Value (ICV) computed over part of the packet header?
<= div>
It serves as a digest from which certain specific = bits are chosen to become the innermost label. Which bits are chosen depend= s upon the bitmask exchanged during the control plane.

=A0
4. =A0 =A0 =A0Is there something in your approach that would prevent an att= acker from a replay attack?

For a= reply attack to succeed, the replay should time the labels correctly other= wise the traffic gets rejected.

5. =A0 =A0 =A0Looking at "Algorithm 3" I was not sure: does the r= eceiver check two consequent time slots? I could not see such a check. I am= referring to a case where the sender transmits at the end of a time slot, = and the packet is received at the beginning of the next time slot. That wou= ld mean the receiver has to be able to tolerate two concurrent time slots, = right?

Yes. It is available as +or- 1 unit = (usually seconds) in the algorithm. Maybe a little more fine tuning is requ= ired on this.
=A0
6. =A0 =A0 =A0The security parameters K, TS, A, I are exchanged over a secu= re link, which basically assumes there is a pre-shared key between the peer= PEs. A naive question would be: how is your approach better than just usin= g a standard ICV, based on the existing pre-shared key?

While the ICV may protect against mo= dification of the inner payload one cannot prevent spoofing attacks if the = algorithm for the ICV is deduced. Our scheme provides facility to change th= e labels from time slice to time slice so that guessing what packet belongs= to which VPN traffic itself becomes difficult. This is the first line of d= efense. If we provide ICV alone we protect against modification but not wit= h replay attacks. The proposed scheme protects against VPN traffic identifi= cation (so replay attacks cannot be made) and modification as well through = the ICV which is the innermost label.

thanks and regards,
balaji , shankar and bhar= gav

Tal.

--20cf3054a0af68abeb04c4692e80-- From ju1738@att.com Mon Jul 9 10:56:46 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1D11E81A9 for ; Mon, 9 Jul 2012 10:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 TBlcCJjXf3H2 for ; Mon, 9 Jul 2012 10:56:45 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA011E8162 for ; Mon, 9 Jul 2012 10:56:45 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 67b1bff4.2aaafbe52940.1227980.00-510.3293136.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jul 2012 17:57:10 +0000 (UTC) X-MXL-Hash: 4ffb1b760ac9215d-58eb564dffee94f209dd2eb694252bfca908b83e Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 27b1bff4.0.1227961.00-399.3293076.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jul 2012 17:57:07 +0000 (UTC) X-MXL-Hash: 4ffb1b731a65550f-933fbefef1bac8114181e5e8cc54ccdc5394e9ef Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69Hv6VD009713; Mon, 9 Jul 2012 13:57:06 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q69Hv3a0009698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 13:57:03 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Mon, 9 Jul 2012 13:56:52 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 13:56:51 -0400 From: "UTTARO, JAMES" To: "'Rogers, Josh'" , balaji venkat Venkataswami , "l2vpn@ietf.org" , "robert@raszuk.net" Subject: RE: L2vpn Digest, Vol 98, Issue 6 Thread-Topic: L2vpn Digest, Vol 98, Issue 6 Thread-Index: Ac1d3iOdVst3wH8vN0uvsrGUCI9bogAAKKdgAAjeloAAAYQN8A== Date: Mon, 9 Jul 2012 17:56:51 +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: [135.70.155.252] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=gE9O8Arr410A:10 a=9xHMEmg6Re4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=-CRmgG0JhlAA:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=ahv8dbORAAAA:8 a=48vgC7mUAAAA:8 a=2clOPd4P] X-AnalysisOut: [AAAA:8 a=zQP7CpKOAAAA:8 a=pGLkceISAAAA:8 a=bu-4PJRAI4fuBXv] X-AnalysisOut: [7cYIA:9 a=jiObf9B0YAUA:10 a=BDsChg1p1CEA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=bDUki_mJ7DgA:10 a=Hz7IrDYlS0cA:10 a=MSl-tDqOz04A:10 ] X-AnalysisOut: [a=UIcTdWks-MRqePm4:21 a=UXk42QkqMWjFuIZr:21] Cc: Shankar Raman M J , Bhargav Bhikkaji X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:56:47 -0000 +1 -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Monday, July 09, 2012 10:40 AM To: UTTARO, JAMES; balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszu= k.net Cc: Shankar Raman M J; Bhargav Bhikkaji Subject: Re: L2vpn Digest, Vol 98, Issue 6 I would propose tabling this draft, and attempting to create a document outlining 1) how best to establish option C peering with other SP's, and 2) outstanding caveats/exposures that are not addressed with available technology/standards. Having such a document would better frame any subsequent 'solution' drafts that address concerns not currently addressable with good policy/practice. -josh On 7/9/12 9:35 AM, "UTTARO, JAMES" wrote: >Josh, > > Yes quite leery of building an Option C solution to other providers= for >a number of reasons including trust, security but also others i.e RT >Mapping, Scale, Protected Infrastructure available to others, IGP Scale ( ># of LBs ), Pri/Back Selection of ASBR, attack on the PEs, etc... >Actually the more sophisticated the Option C solution the more alignment >and possible risk. > >I understand the ask that this draft is attempting to meet, but does it >make sense to do this without addressing the other facets of building an >Option C solution between different ISPs.. > >Jim Uttaro > > > > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Rogers, Josh >Sent: Monday, July 09, 2012 10:22 AM >To: balaji venkat Venkataswami; l2vpn@ietf.org; robert@raszuk.net >Cc: Shankar Raman M J; Bhargav Bhikkaji >Subject: Re: L2vpn Digest, Vol 98, Issue 6 > >While I don't necessarily agree with this draft's approach ("security >through obscurity" comes to mind), I'd like to point out that I do see a >need to assuage concerns about using Option C between operators. In my >part of the world, when I propose Option C to other operators, often the >idea is met with concern/resistance, seemingly because the other operator >has not done it before. Even internally, many of my colleagues are >concerned about security and the trust model in general. It appears to >me, to be no different than any other IP peering relationship, which >requires some basic 'trust', albeit not implicit trust. > >I think Robert's suggestion of leveraging encryption is a more ironclad >and reasonable solution to the problems presented here. However, I'd >still like to see an informative 'best practices' document at some point >that covered some basic policies that should be followed when peering with >another ISP for LxVPN exchange. > >-Josh > > > >On 7/8/12 1:46 AM, "balaji venkat Venkataswami" > wrote: > >>Dear Robert, >> >>As mentioned in the earlier mail the following restriction is imposed on >>the >>Model C deployment=A9 >> >>The consequence of this is that in model C the service providers must >>trust each other also in areas that are not shared. Therefore, model C is >>most commonly used today where a single operator uses several ASs on the >>backbone. In this case, implicit trust exists between the ASs because >>they >>have the same operational control. >> >> >>In order to stretch this scheme to other Ases under different admin >>control this scheme helps out. >> >>Thanks and regards, >>Balaji venkat >> >>On 08/07/12 12:30 AM, "l2vpn-request@ietf.org" >>wrote: >> >>>If you have received this digest without all the individual message >>>attachments you will need to update your digest options in your list >>>subscription. To do so, go to >>> >>>https://www.ietf.org/mailman/listinfo/l2vpn >>> >>>Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>MIME or Plain Text Digests?" to MIME. You can set this option >>>globally for all the list digests you receive at this point. >>> >>> >>> >>>Send L2vpn mailing list submissions to >>> l2vpn@ietf.org >>> >>>To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/l2vpn >>>or, via email, send a message with subject or body 'help' to >>> l2vpn-request@ietf.org >>> >>>You can reach the person managing the list at >>> l2vpn-owner@ietf.org >>> >>>When replying, please edit your Subject line so it is more specific >>>than "Re: Contents of L2vpn digest..." >>> >>> >>>Today's Topics: >>> >>> 1. draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>> (Robert Raszuk) >>> >>> >>>---------------------------------------------------------------------- >>> >>>Message: 1 >>>Date: Sat, 07 Jul 2012 14:39:56 +0200 >>>From: Robert Raszuk >>>To: "l2vpn@ietf.org" >>>Subject: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... >>>Message-ID: <4FF82E1C.6000009@raszuk.net> >>>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >>> >>>I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt. >>> >>>It proposed an interesting solution to apply algorithmically computed >>>VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as >>>option C is used. >>> >>>However I have a fundamental question .. from who the draft is >>>protecting the inter-as service ? >>> >>>Who other then participating ISPs can spoof a value of VPN label ? If >>>the solution is protecting from ISPs itself then I think it does not >>>help at all as corresponding ISPs/SPs still have full access to their >>>PEs and could inject packets to VPN sites at will. >>> >>>Moreover main issue with option C is not security (at least for the last >>>10+ years). Main issue with option C and MPLS is that participating >>>providers need to inject into each other's network all of their >>>participating PE's /32 addresses so the end to end MPLS LSP can be >>>build. Originally that was recommended to be done by mutual >>>redistribution to the IGP .. now the general recommendation is to use >>>labeled BGP (both IBGP and EBGP). >>> >>>So fundamental question to the authors ... who is the potential >>>attacker/spoofer this draft is aiming to protect from ? >>> >>>Best regards, >>>R. >>> >>> >>> >>> >>> >>>------------------------------ >>> >>>_______________________________________________ >>>L2vpn mailing list >>>L2vpn@ietf.org >>>https://www.ietf.org/mailman/listinfo/l2vpn >>> >>> >>>End of L2vpn Digest, Vol 98, Issue 6 >>>************************************ >> >> > > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From talmi@marvell.com Mon Jul 9 12:06:21 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005D811E8165; Mon, 9 Jul 2012 12:06:21 -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=[AWL=-0.000, 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 6coVAEMcIlL4; Mon, 9 Jul 2012 12:06:18 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id E289011E814F; Mon, 9 Jul 2012 12:06:10 -0700 (PDT) From: Tal Mizrahi To: Balaji venkat Venkataswami Date: Mon, 9 Jul 2012 22:06:29 +0300 Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1d6hqW9ssineDjRymcI0+sUBeL5QAGlYJg Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F8743E91@IL-MB01.marvell.com> References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F8743E91ILMB01marve_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:06:21 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F8743E91ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balaji, Thanks for the prompt and detailed response. Please see inline. Regards, Tal. From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] Sent: Monday, July 09, 2012 6:47 PM To: Tal Mizrahi Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Tal, Comments inline On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi > wrote: Hi Balaji, A few clarification questions - I think it would be good to clarify these i= ssues in the draft: 1. Since the label hopping mechanism relies on PTP, I understand that = PTP traffic itself does not use label hopping, right? The PTP traffic itself does not use label hopping. 2. Is there something preventing the attacker from attacking PTP, thus= causing DoS to the data plane? It would be difficult for the attacker to identify which LSP is the PTP LSP= for a specific VPN traffic (flow / set of flows) that is protected by this= scheme. There is no information except on the ingress and egress PEs that = identifies which is the PTP LSP for a particular VPN traffic protected by t= his scheme. 3. Is the "additional label" similar to an Integrity Check Value (ICV)= computed over part of the packet header? It serves as a digest from which certain specific bits are chosen to become= the innermost label. Which bits are chosen depends upon the bitmask exchan= ged during the control plane. [TM] Right. Unless I am missing something, that sounds like a variant of an= ICV: it basically produces a label which is a function(packet payload, pre= -shared secret). That is essentially what an ICV does, unless I am missing = something? 4. Is there something in your approach that would prevent an attacker = from a replay attack? For a reply attack to succeed, the replay should time the labels correctly = otherwise the traffic gets rejected. [TM] Right, so assuming the attacker is "fast enough", the attacker can rep= lay during the time slice (which is ~seconds)? 5. Looking at "Algorithm 3" I was not sure: does the receiver check tw= o consequent time slots? I could not see such a check. I am referring to a = case where the sender transmits at the end of a time slot, and the packet i= s received at the beginning of the next time slot. That would mean the rece= iver has to be able to tolerate two concurrent time slots, right? Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. May= be a little more fine tuning is required on this. 6. The security parameters K, TS, A, I are exchanged over a secure lin= k, which basically assumes there is a pre-shared key between the peer PEs. = A naive question would be: how is your approach better than just using a st= andard ICV, based on the existing pre-shared key? While the ICV may protect against modification of the inner payload one can= not prevent spoofing attacks if the algorithm for the ICV is deduced. Our s= cheme provides facility to change the labels from time slice to time slice = so that guessing what packet belongs to which VPN traffic itself becomes di= fficult. This is the first line of defense. If we provide ICV alone we prot= ect against modification but not with replay attacks. The proposed scheme p= rotects against VPN traffic identification (so replay attacks cannot be mad= e) and modification as well through the ICV which is the innermost label. [TM] Since an ICV uses a pre-shared key, even if the algorithm is well-know= n to the attacker, the attacker cannot forge/spoof it, assuming that the at= tacker is not exposed to the key. ICV mechanisms typically support anti rep= lay, e.g., the IPsec AH. thanks and regards, balaji , shankar and bhargav Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F8743E91ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Balaji= ,
=
Thanks for the prompt and detailed response= .
Please see inline.<= /o:p>

Regards,
Tal.

From: Balaji venkat Venkataswami [mailto:ba= lajivenkat299@gmail.com]
Sent: Monday, July 09, 2012 6:47 PM
= To: Tal Mizrahi
Cc: l2vpn@ietf.org; Shankar Raman M J; tic= toc@ietf.org; robert@raszuk.net
Subject: Re: draft-mjsraman-l2vpn= -vpls-tictoc-label-hop-00.txt ...

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <talmi@marvell.com> wrote:<= /o:p>
Hi Balaji,

A few clarification questio= ns - I think it would be good to clarify these issues in the draft:
1. &= nbsp; Since the label hopping mechanism relies on PTP, I under= stand that PTP traffic itself does not use label hopping, right?=

The PTP traffic itself does not use label hopping.

2. &n= bsp;Is there something preventing the attacker from attacking PTP, thus cau= sing DoS to the data plane?

It would be diff= icult for the attacker to identify which LSP is the PTP LSP for a specific = VPN traffic (flow / set of flows) that is protected by this scheme. There i= s no information except on the ingress and egress PEs that identifies which= is the PTP LSP for a particular VPN traffic protected by this scheme. = ;

=
3.= Is the "additional label" similar to an Inte= grity Check Value (ICV) computed over part of the packet header?=

=
It serves as a digest from which certain specific bits= are chosen to become the innermost label. Which bits are chosen depends up= on the bitmask exchanged during the control plane.
[TM] Right. Unless I am missing something, that s= ounds like a variant of an ICV: it basically produces a label which is a fu= nction(packet payload, pre-shared secret). That is essentially what an ICV = does, unless I am missing something?

4. &nb= sp; Is there something in your approach that would prevent an attacke= r from a replay attack?

For a reply attack t= o succeed, the replay should time the labels correctly otherwise the traffi= c gets rejected.
[TM] Right= , so assuming the attacker is “fast enough”, the attacker can r= eplay during the time slice (which is ~seconds)?

= 5. Looking at "Algorithm 3" I was not sure: d= oes the receiver check two consequent time slots? I could not see such a ch= eck. I am referring to a case where the sender transmits at the end of a ti= me slot, and the packet is received at the beginning of the next time slot.= That would mean the receiver has to be able to tolerate two concurrent tim= e slots, right?
&= nbsp;
Yes. It is available as +or-= 1 unit (usually seconds) in the algorithm. Maybe a little more fine tuning= is required on this.
<= o:p>
6. The security parameters K, TS, A, = I are exchanged over a secure link, which basically assumes there is a pre-= shared key between the peer PEs. A naive question would be: how is your app= roach better than just using a standard ICV, based on the existing pre-shar= ed key?

While the ICV may protect against mo= dification of the inner payload one cannot prevent spoofing attacks if the = algorithm for the ICV is deduced. Our scheme provides facility to change th= e labels from time slice to time slice so that guessing what packet belongs= to which VPN traffic itself becomes difficult. This is the first line of d= efense. If we provide ICV alone we protect against modification but not wit= h replay attacks. The proposed scheme protects against VPN traffic identifi= cation (so replay attacks cannot be made) and modification as well through = the ICV which is the innermost label.

[TM] Since an ICV uses a pre-shared key, even if the algorithm i= s well-known to the attacker, the attacker cannot forge/spoof it, assuming = that the attacker is not exposed to the key. ICV mechanisms typically suppo= rt anti replay, e.g., the IPsec AH.=

thanks and regards,

balaji , shankar and bhargav

Tal.<= /span>

= --_000_74470498B659FA4687F0B0018C19A89C01A0F8743E91ILMB01marve_-- From bhargav@force10networks.com Mon Jul 9 15:44:42 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3721F85F3; Mon, 9 Jul 2012 15:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, 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 qd5vFLrf3+Et; Mon, 9 Jul 2012 15:44:41 -0700 (PDT) Received: from mx.force10networks.com (207.47.62.31.static.nextweb.net [207.47.62.31]) by ietfa.amsl.com (Postfix) with ESMTP id 976FC21F85F2; Mon, 9 Jul 2012 15:44:41 -0700 (PDT) Received: from EX07-SJC-MBX1.force10networks.com ([fe80:0000:0000:0000:30d7:5b59:107.47.36.196]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Mon, 9 Jul 2012 15:45:07 -0700 From: Bhargav Bhikkaji To: Greg Mirsky , Balaji venkat Venkataswami Date: Mon, 9 Jul 2012 15:45:04 -0700 Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1d+re2OFQ5p2bbRUasmakqZL+VkwAKPAjw Message-ID: References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EB72E43FE49DA8449253018A9FA7422706AAC3C613EX07SJCMBX1fo_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 22:44:42 -0000 --_000_EB72E43FE49DA8449253018A9FA7422706AAC3C613EX07SJCMBX1fo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Greg, As per the PTP over MPLS draft, all intervening LSRs need not be 1588-aware= . If we use the EF-PHB with green as drop probability all P routers need not = know about the PTP LSP. This has been stated in the PTP over MPLS draft. Even if we were to use the 1588 aware LSRs the actual binding between a PTP= LSP and the VPN which is protected by it is known only to the ingress and = egress PE and not anywhere else. The PTP LSP would have to be tied into the= labels only at the ingress and egress PE and this binding / tying up is kn= own only to them. Hence even if the PTP LSP timing is elicited the time sli= ces when the labels have to be used is known only to the ingress and egres= s PEs. Thanks From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Monday, July 09, 2012 10:46 AM To: Balaji venkat Venkataswami Cc: l2vpn@ietf.org; Shankar Raman M J; robert@raszuk.net; tictoc@ietf.org Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Balaji, you've said " There is no information except on the ingress and egress PEs = that identifies which is the PTP LSP for a particular VPN traffic protected= by this scheme." AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP= updates. Would that compromise your method? Regards, Greg On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami > wrote: Dear Tal, Comments inline On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi > wrote: Hi Balaji, A few clarification questions - I think it would be good to clarify these i= ssues in the draft: 1. Since the label hopping mechanism relies on PTP, I understand that = PTP traffic itself does not use label hopping, right? The PTP traffic itself does not use label hopping. 2. Is there something preventing the attacker from attacking PTP, thus= causing DoS to the data plane? It would be difficult for the attacker to identify which LSP is the PTP LSP= for a specific VPN traffic (flow / set of flows) that is protected by this= scheme. There is no information except on the ingress and egress PEs that = identifies which is the PTP LSP for a particular VPN traffic protected by t= his scheme. 3. Is the "additional label" similar to an Integrity Check Value (ICV)= computed over part of the packet header? It serves as a digest from which certain specific bits are chosen to become= the innermost label. Which bits are chosen depends upon the bitmask exchan= ged during the control plane. 4. Is there something in your approach that would prevent an attacker = from a replay attack? For a reply attack to succeed, the replay should time the labels correctly = otherwise the traffic gets rejected. 5. Looking at "Algorithm 3" I was not sure: does the receiver check tw= o consequent time slots? I could not see such a check. I am referring to a = case where the sender transmits at the end of a time slot, and the packet i= s received at the beginning of the next time slot. That would mean the rece= iver has to be able to tolerate two concurrent time slots, right? Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. May= be a little more fine tuning is required on this. 6. The security parameters K, TS, A, I are exchanged over a secure lin= k, which basically assumes there is a pre-shared key between the peer PEs. = A naive question would be: how is your approach better than just using a st= andard ICV, based on the existing pre-shared key? While the ICV may protect against modification of the inner payload one can= not prevent spoofing attacks if the algorithm for the ICV is deduced. Our s= cheme provides facility to change the labels from time slice to time slice = so that guessing what packet belongs to which VPN traffic itself becomes di= fficult. This is the first line of defense. If we provide ICV alone we prot= ect against modification but not with replay attacks. The proposed scheme p= rotects against VPN traffic identification (so replay attacks cannot be mad= e) and modification as well through the ICV which is the innermost label. thanks and regards, balaji , shankar and bhargav Tal. --_000_EB72E43FE49DA8449253018A9FA7422706AAC3C613EX07SJCMBX1fo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Greg,

<= /p>

As per the PTP over MPLS draft, all intervening LSRs need not be 1588-aware.

<= /p>

If we use the EF-PHB with green as drop probability all P routers need not know about the PTP LSP. Th= is has been stated in the PTP over MPLS draft.

<= /p>

Even if we were to use th= e 1588 aware LSRs the actual binding between a PTP LSP and the VPN which is p= rotected by it is known only to the ingress and egress PE and not anywhere else. The= PTP LSP would have to be tied into the labels only at the ingress and egress PE= and this binding / tying up is known only to them. Hence even if the PTP LSP ti= ming is elicited the time slices when the labels have to be used is known only t= o the ingress and egress PEs.

Thanks

From: l2vpn-bounces= @ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, July 09, 2012 10:46 AM
To: Balaji venkat Venkataswami
Cc: l2vpn@ietf.org; Shankar Raman M J; robert@raszuk.net; tictoc@ietf.org
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Balaji,
you've said " There is no information except on the ingress and egress= PEs that identifies which is the PTP LSP for a particular VPN traffic protected= by this scheme."
AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP updates. Would that compromise your method?

Regards,
Greg

On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkatas= wami <balajive= nkat299@gmail.com> wrote:

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Hi Balaji,

A few clarification questions - I think it would be good to clarify these issues in the draft:
1. Since the label hopping mechanism relies on PTP, I understand that PTP traffic itself does not use label hopping, right?<= /o:p>

The PTP traffic itself does not use label hopping.

2. Is there something preventing t= he attacker from attacking PTP, thus causing DoS to the data plane?=

It would be difficult for the attacker to identify whi= ch LSP is the PTP LSP for a specific VPN traffic (flow / set of flows) that is protected by this scheme. There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffi= c protected by this scheme.

3. Is the "additional label&q= uot; similar to an Integrity Check Value (ICV) computed over part of the packet header?

It serves as a digest from which certain specific bits= are chosen to become the innermost label. Which bits are chosen depends upon th= e bitmask exchanged during the control plane.

4. Is there something in your appr= oach that would prevent an attacker from a replay attack?

For a reply attack to succeed, the replay should time = the labels correctly otherwise the traffic gets rejected.

5. Looking at "Algorithm 3&qu= ot; I was not sure: does the receiver check two consequent time slots? I could no= t see such a check. I am referring to a case where the sender transmits at th= e end of a time slot, and the packet is received at the beginning of the next time slot. That would mean the receiver has to be able to tolerate two concurrent time slots, right?

Yes. It is available as +or- 1 unit (usually seconds) = in the algorithm. Maybe a little more fine tuning is required on this.<= /p>

6. The security parameters K, TS, = A, I are exchanged over a secure link, which basically assumes there is a pre-sh= ared key between the peer PEs. A naive question would be: how is your approach better than just using a standard ICV, based on the existing pre-shared key= ?

While the ICV may protect against modification of the = inner payload one cannot prevent spoofing attacks if the algorithm for the ICV is deduced. Our scheme provides facility to change the labels from time slice = to time slice so that guessing what packet belongs to which VPN traffic itself becomes difficult. This is the first line of defense. If we provide ICV alo= ne we protect against modification but not with replay attacks. The proposed scheme protects against VPN traffic identification (so replay attacks canno= t be made) and modification as well through the ICV which is the innermost label= .

thanks and regards,

balaji , shankar and bhargav

Tal.

--_000_EB72E43FE49DA8449253018A9FA7422706AAC3C613EX07SJCMBX1fo_-- From gregory.mirsky@ericsson.com Mon Jul 9 16:09:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972511E80FD; Mon, 9 Jul 2012 16:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvWIsQglXj7z; Mon, 9 Jul 2012 16:09:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEDE11E80F7; Mon, 9 Jul 2012 16:09:27 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q69N9k4t013946; Mon, 9 Jul 2012 18:09:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Jul 2012 19:09:48 -0400 From: Gregory Mirsky To: Bhargav Bhikkaji , Greg Mirsky , Balaji venkat Venkataswami Date: Mon, 9 Jul 2012 19:09:45 -0400 Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1d+re2OFQ5p2bbRUasmakqZL+VkwAKPAjwAADwL9A= Message-ID: References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D7192037EUSAACMS0715e_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:09:28 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D7192037EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Bhargav, thank you for your expedient reply to my question. Yes, technically, PTP LSP can run through LSRs that are not 1588-aware. But= that is very unlikely IMHO. Then I need to note that the http://tools.ietf.org/html/draft-ietf-tictoc-1= 588overmpls-02 had expired last April. Regards, Greg ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of B= hargav Bhikkaji Sent: Monday, July 09, 2012 3:45 PM To: Greg Mirsky; Balaji venkat Venkataswami Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Greg, As per the PTP over MPLS draft, all intervening LSRs need not be 1588-aware= . If we use the EF-PHB with green as drop probability all P routers need not = know about the PTP LSP. This has been stated in the PTP over MPLS draft. Even if we were to use the 1588 aware LSRs the actual binding between a PTP= LSP and the VPN which is protected by it is known only to the ingress and = egress PE and not anywhere else. The PTP LSP would have to be tied into the= labels only at the ingress and egress PE and this binding / tying up is kn= own only to them. Hence even if the PTP LSP timing is elicited the time sli= ces when the labels have to be used is known only to the ingress and egres= s PEs. Thanks From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Monday, July 09, 2012 10:46 AM To: Balaji venkat Venkataswami Cc: l2vpn@ietf.org; Shankar Raman M J; robert@raszuk.net; tictoc@ietf.org Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Balaji, you've said " There is no information except on the ingress and egress PEs = that identifies which is the PTP LSP for a particular VPN traffic protected= by this scheme." AFAIK, notion of PTP LSP is not limited to PE's but to all P's that get PTP= updates. Would that compromise your method? Regards, Greg On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkataswami > wrote: Dear Tal, Comments inline On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi > wrote: Hi Balaji, A few clarification questions - I think it would be good to clarify these i= ssues in the draft: 1. Since the label hopping mechanism relies on PTP, I understand that = PTP traffic itself does not use label hopping, right? The PTP traffic itself does not use label hopping. 2. Is there something preventing the attacker from attacking PTP, thus= causing DoS to the data plane? It would be difficult for the attacker to identify which LSP is the PTP LSP= for a specific VPN traffic (flow / set of flows) that is protected by this= scheme. There is no information except on the ingress and egress PEs that = identifies which is the PTP LSP for a particular VPN traffic protected by t= his scheme. 3. Is the "additional label" similar to an Integrity Check Value (ICV)= computed over part of the packet header? It serves as a digest from which certain specific bits are chosen to become= the innermost label. Which bits are chosen depends upon the bitmask exchan= ged during the control plane. 4. Is there something in your approach that would prevent an attacker = from a replay attack? For a reply attack to succeed, the replay should time the labels correctly = otherwise the traffic gets rejected. 5. Looking at "Algorithm 3" I was not sure: does the receiver check tw= o consequent time slots? I could not see such a check. I am referring to a = case where the sender transmits at the end of a time slot, and the packet i= s received at the beginning of the next time slot. That would mean the rece= iver has to be able to tolerate two concurrent time slots, right? Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. May= be a little more fine tuning is required on this. 6. The security parameters K, TS, A, I are exchanged over a secure lin= k, which basically assumes there is a pre-shared key between the peer PEs. = A naive question would be: how is your approach better than just using a st= andard ICV, based on the existing pre-shared key? While the ICV may protect against modification of the inner payload one can= not prevent spoofing attacks if the algorithm for the ICV is deduced. Our s= cheme provides facility to change the labels from time slice to time slice = so that guessing what packet belongs to which VPN traffic itself becomes di= fficult. This is the first line of defense. If we provide ICV alone we prot= ect against modification but not with replay attacks. The proposed scheme p= rotects against VPN traffic identification (so replay attacks cannot be mad= e) and modification as well through the ICV which is the innermost label. thanks and regards, balaji , shankar and bhargav Tal. --_000_FE60A4E52763E84B935532D7D9294FF137D7192037EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Bhargav,

thank you for your expedient reply to my=20 question.

Yes, technically, PTP LSP can run through LSRs t= hat are=20 not 1588-aware. But that is very unlikely IMHO.

Then I need to note that the http:= //tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02 had=20 expired last April.

Regards,

=20 Greg

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bhargav=20 Bhikkaji
Sent: Monday, July 09, 2012 3:45 PM
To: Greg=20 Mirsky; Balaji venkat Venkataswami
Cc: l2vpn@ietf.org; Shankar Ra= man M=20 J; tictoc@ietf.org; robert@raszuk.net
Subject: RE:=20 draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear=20 Greg,<= /SPAN>

As=20 per the PTP over MPLS draft, all intervening LSRs need not be=20 1588-aware.

If=20 we use the EF-PHB with green as drop probability all P routers need not kno= w=20 about the PTP LSP. This has been stated in the PTP over MPLS=20 draft.

Even=20 if we were to use the 1588 aware LSRs the actual binding between a PTP LSP = and=20 the VPN which is protected by it is known only to the ingress and egress PE= and=20 not anywhere else. The PTP LSP would have to be tied into the labels only a= t the=20 ingress and egress PE and this binding / tying up is known only to them. He= nce=20 even if the PTP LSP timing is elicited the time slices when the labels have= to=20 be used is known only to the ingress and egress PEs.

Thanks

From:<= /B>=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Greg=20 Mirsky
Sent: Monday, July 09, 2012 10:46 AM
To: Balaji= =20 venkat Venkataswami
Cc: l2vpn@ietf.org; Shankar Raman M J;=20 robert@raszuk.net; tictoc@ietf.org
Subject: Re:=20 draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt=20 ...

Dear Balaji,
you've s= aid "=20 There is no information except on the ingress and egress PEs that identifie= s=20 which is the PTP LSP for a particular VPN traffic protected by this=20 scheme."
AFAIK, notion of PTP LSP is not limited to PE's but to all P's = that=20 get PTP updates. Would that compromise your=20 method?

Regards,
Greg

On Mon, Jul 9, 2012 at 8:47 AM, Balaji venkat Venkatas= wami=20 <balajivenkat299@gmail.com> wrote:

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <talmi@marvell.com>= =20 wrote:

Hi Balaji,

A few clarification questions - I th= ink it=20 would be good to clarify these issues in the draft:
1. =20 Since the label hopping mechanism relies on PTP, I understand that PT= P=20 traffic itself does not use label hopping, right?

The PTP traffic itself does not use label=20 hopping.

2. Is there something preventing= the=20 attacker from attacking PTP, thus causing DoS to the data=20 plane?

It would be difficult for the attacker to identify whi= ch LSP=20 is the PTP LSP for a specific VPN traffic (flow / set of flows) that is=20 protected by this scheme. There is no information except on the ingress and= =20 egress PEs that identifies which is the PTP LSP for a particular VPN traffi= c=20 protected by this scheme.

3. Is the "additional label" sim= ilar to=20 an Integrity Check Value (ICV) computed over part of the packet=20 header?

It serves as a digest from which certain specific bits= are=20 chosen to become the innermost label. Which bits are chosen depends upon th= e=20 bitmask exchanged during the control plane.

4. Is there something in your ap= proach=20 that would prevent an attacker from a replay attack?

For a reply attack to succeed, the replay should time = the=20 labels correctly otherwise the traffic gets rejected.

5. Looking at "Algorithm 3" I wa= s not=20 sure: does the receiver check two consequent time slots? I could not see = such=20 a check. I am referring to a case where the sender transmits at the end o= f a=20 time slot, and the packet is received at the beginning of the next time s= lot.=20 That would mean the receiver has to be able to tolerate two concurrent ti= me=20 slots, right?

Yes. It is available as +or- 1 unit (usually seconds) = in the=20 algorithm. Maybe a little more fine tuning is required on=20 this.

6. The security parameters K, TS= , A, I=20 are exchanged over a secure link, which basically assumes there is a=20 pre-shared key between the peer PEs. A naive question would be: how is yo= ur=20 approach better than just using a standard ICV, based on the existing=20 pre-shared key?

While the ICV may protect against modification of the = inner=20 payload one cannot prevent spoofing attacks if the algorithm for the ICV is= =20 deduced. Our scheme provides facility to change the labels from time slice = to=20 time slice so that guessing what packet belongs to which VPN traffic itself= =20 becomes difficult. This is the first line of defense. If we provide ICV alo= ne we=20 protect against modification but not with replay attacks. The proposed sche= me=20 protects against VPN traffic identification (so replay attacks cannot be ma= de)=20 and modification as well through the ICV which is the innermost=20 label.

thanks and regards,

balaji , shankar and bhargav

Tal.

--_000_FE60A4E52763E84B935532D7D9294FF137D7192037EUSAACMS0715e_-- From bhargav@force10networks.com Mon Jul 9 19:58:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057D511E80A1; Mon, 9 Jul 2012 19:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, 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 b5v3ecdDz9Yk; Mon, 9 Jul 2012 19:58:48 -0700 (PDT) Received: from mx.force10networks.com (207.47.62.31.static.nextweb.net [207.47.62.31]) by ietfa.amsl.com (Postfix) with ESMTP id 43C6D11E80F1; Mon, 9 Jul 2012 19:58:48 -0700 (PDT) Received: from EX07-SJC-MBX1.force10networks.com ([fe80:0000:0000:0000:30d7:5b59:107.47.36.196]) by exch7-sjc-fe.force10networks.com ([10.11.0.87]) with mapi; Mon, 9 Jul 2012 19:59:14 -0700 From: Bhargav Bhikkaji To: Tal Mizrahi , Balaji venkat Venkataswami Date: Mon, 9 Jul 2012 19:59:12 -0700 Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Topic: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Thread-Index: Ac1d6hqW9ssineDjRymcI0+sUBeL5QAGlYJgABDKUVA= Message-ID: References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> <74470498B659FA4687F0B0018C19A89C01A0F8743E91@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F8743E91@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EB72E43FE49DA8449253018A9FA7422706AAC3C65CEX07SJCMBX1fo_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , Shankar Raman M J , "tictoc@ietf.org" , "robert@raszuk.net" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 02:58:51 -0000 --_000_EB72E43FE49DA8449253018A9FA7422706AAC3C65CEX07SJCMBX1fo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tal, Thanks for your comments. Pls see inline [BB] for response -Bhargav From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of T= al Mizrahi Sent: Monday, July 09, 2012 12:06 PM To: Balaji venkat Venkataswami Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Hi Balaji, Thanks for the prompt and detailed response. Please see inline. Regards, Tal. From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] Sent: Monday, July 09, 2012 6:47 PM To: Tal Mizrahi Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... Dear Tal, Comments inline On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi > wrote: Hi Balaji, A few clarification questions - I think it would be good to clarify these i= ssues in the draft: 1. Since the label hopping mechanism relies on PTP, I understand that = PTP traffic itself does not use label hopping, right? The PTP traffic itself does not use label hopping. 2. Is there something preventing the attacker from attacking PTP, thus= causing DoS to the data plane? It would be difficult for the attacker to identify which LSP is the PTP LSP= for a specific VPN traffic (flow / set of flows) that is protected by this= scheme. There is no information except on the ingress and egress PEs that = identifies which is the PTP LSP for a particular VPN traffic protected by t= his scheme. 3. Is the "additional label" similar to an Integrity Check Value (ICV)= computed over part of the packet header? It serves as a digest from which certain specific bits are chosen to become= the innermost label. Which bits are chosen depends upon the bitmask exchan= ged during the control plane. [TM] Right. Unless I am missing something, that sounds like a variant of an= ICV: it basically produces a label which is a function(packet payload, pre= -shared secret). That is essentially what an ICV does, unless I am missing = something? [BB]: Agreed, the scheme we proposed is a of ICV scheme. 4. Is there something in your approach that would prevent an attacker = from a replay attack? For a reply attack to succeed, the replay should time the labels correctly = otherwise the traffic gets rejected. [TM] Right, so assuming the attacker is "fast enough", the attacker can rep= lay during the time slice (which is ~seconds)? 5. Looking at "Algorithm 3" I was not sure: does the receiver check tw= o consequent time slots? I could not see such a check. I am referring to a = case where the sender transmits at the end of a time slot, and the packet i= s received at the beginning of the next time slot. That would mean the rece= iver has to be able to tolerate two concurrent time slots, right? Yes. It is available as +or- 1 unit (usually seconds) in the algorithm. May= be a little more fine tuning is required on this. 6. The security parameters K, TS, A, I are exchanged over a secure lin= k, which basically assumes there is a pre-shared key between the peer PEs. = A naive question would be: how is your approach better than just using a st= andard ICV, based on the existing pre-shared key? While the ICV may protect against modification of the inner payload one can= not prevent spoofing attacks if the algorithm for the ICV is deduced. Our s= cheme provides facility to change the labels from time slice to time slice = so that guessing what packet belongs to which VPN traffic itself becomes di= fficult. This is the first line of defense. If we provide ICV alone we prot= ect against modification but not with replay attacks. The proposed scheme p= rotects against VPN traffic identification (so replay attacks cannot be mad= e) and modification as well through the ICV which is the innermost label. [TM] Since an ICV uses a pre-shared key, even if the algorithm is well-know= n to the attacker, the attacker cannot forge/spoof it, assuming that the at= tacker is not exposed to the key. ICV mechanisms typically support anti rep= lay, e.g., the IPsec AH. [BB]: We had submitted a draft where certain bits of IPSec digital signatur= e is used as "additional label". This would help to identify forged/spoofed= packet. http://tools.ietf.org/html/draft-bhargav-l3vpn-inter-provider-optcsec-01 thanks and regards, balaji , shankar and bhargav Tal. --_000_EB72E43FE49DA8449253018A9FA7422706AAC3C65CEX07SJCMBX1fo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tal,

Thanks for your comments. Pls see inline [BB] for response

-Bhargav

From: l2vpn-bounces= @ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Monday, July 09, 2012 12:06 PM
To: Balaji venkat Venkataswami
Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net
Subject: RE: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Hi Balaji,

Thanks for the prompt and detailed response.

Please see inline.

Regards,

Tal.

From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
Sent: Monday, July 09, 2012 6:47 PM
To: Tal Mizrahi
Cc: l2vpn@ietf.org; Shankar Raman M J; tictoc@ietf.org; robert@raszuk.net
Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ...

Dear Tal,

Comments inline

On Mon, Jul 9, 2012 at 11:44 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Hi Balaji,

A few clarification questions - I think it would be good to clarify these issues in the draft:
1. Since the label hopping mechanism relies on PTP, I understand that PTP traffic itself does not use label hopping, right?<= /o:p>

The PTP traffic itself does not use label hopping.

2. Is there something preventing t= he attacker from attacking PTP, thus causing DoS to the data plane?=

It would be difficult for the attacker to identify whi= ch LSP is the PTP LSP for a specific VPN traffic (flow / set of flows) that is protected by this scheme. There is no information except on the ingress and egress PEs that identifies which is the PTP LSP for a particular VPN traffi= c protected by this scheme.

3. Is the "additional label&q= uot; similar to an Integrity Check Value (ICV) computed over part of the packet header?

It serves as a digest from which certain specific bits= are chosen to become the innermost label. Which bits are chosen depends upon th= e bitmask exchanged during the control plane.

[TM] Right. Unless I am missing something, that sounds like = a variant of an ICV: it basically produces a label which is a function(packet payload, pre-shared secret). That is essentially what an ICV does, unless I= am missing something?

[BB]: Agreed, the scheme we proposed is a of ICV scheme.

4. Is there something in your appr= oach that would prevent an attacker from a replay attack?

For a reply attack to succeed, the replay should time = the labels correctly otherwise the traffic gets rejected.

[TM] Right, so assuming the attacker is “fast enough&#= 8221;, the attacker can replay during the time slice (which is ~seconds)?

5. Looking at "Algorithm 3&qu= ot; I was not sure: does the receiver check two consequent time slots? I could no= t see such a check. I am referring to a case where the sender transmits at th= e end of a time slot, and the packet is received at the beginning of the next time slot. That would mean the receiver has to be able to tolerate two concurrent time slots, right?

Yes. It is available as +or- 1 unit (usually seconds) = in the algorithm. Maybe a little more fine tuning is required on this.<= /p>

6. The security parameters K, TS, = A, I are exchanged over a secure link, which basically assumes there is a pre-sh= ared key between the peer PEs. A naive question would be: how is your approach better than just using a standard ICV, based on the existing pre-shared key= ?

While the ICV may protect against modification of the = inner payload one cannot prevent spoofing attacks if the algorithm for the ICV is deduced. Our scheme provides facility to change the labels from time slice = to time slice so that guessing what packet belongs to which VPN traffic itself becomes difficult. This is the first line of defense. If we provide ICV alo= ne we protect against modification but not with replay attacks. The proposed scheme protects against VPN traffic identification (so replay attacks canno= t be made) and modification as well through the ICV which is the innermost label= .

[TM] Since an ICV uses a pre-shared key, even if the algorit= hm is well-known to the attacker, the attacker cannot forge/spoof it, assuming that the attacker is not exposed to the key. ICV mechanisms typically suppo= rt anti replay, e.g., the IPsec AH.

[BB]: We had submitted a draft where certain bits of IPSec digital signature is u= sed as "additional label". This would help to identify forged/spoofed packet.

http://tools.ietf.org/html/draft-bhargav-l3vpn-inter-provi= der-optcsec-01

thanks and regards,

balaji , shankar and bhargav

Tal.

--_000_EB72E43FE49DA8449253018A9FA7422706AAC3C65CEX07SJCMBX1fo_-- From stbryant@cisco.com Tue Jul 10 01:07:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7F21F8608; Tue, 10 Jul 2012 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkei95qS1-y7; Tue, 10 Jul 2012 01:07:13 -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 B235921F8607; Tue, 10 Jul 2012 01:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2627; q=dns/txt; s=iport; t=1341907661; x=1343117261; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=AKj8McmM/euHYOeY4ho48cLa6zOpPyflEcwv+UQALSY=; b=WMiQsf2aGRSxRnIrbamb+enIH3wzYVWIWMPIQkLSQs2MSMeMWnLscbrk mKfl8Wukrw/KAhE8vLa335dhv+WEuPmwjeNUMuFYXigBDJ5R7CmJG3Wch yiVTMLE+t5uN+L9h7H+S2H580MFjzE4BIVCw89cDTwhK5liol33+gEbh4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFLi+0+rRDoI/2dsb2JhbABFgkq1MoEHgiABAQEDARIBAmMBBQsLBAEcFg8JAwIBAgFFBg0BBwEBHodlBQGcN4NIEJxskWIDlTaOH4EEYoJg X-IronPort-AV: E=Sophos;i="4.77,558,1336348800"; d="scan'208,217";a="51439940" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 Jul 2012 08:07:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6A87cB1029980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 08:07:40 GMT Received: from dhcp-10-61-110-150.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q6A87Zgt001995; Tue, 10 Jul 2012 09:07:36 +0100 (BST) Message-ID: <4FFBE2C7.4040202@cisco.com> Date: Tue, 10 Jul 2012 09:07:35 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bhargav Bhikkaji Subject: Re: draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt ... References: <4FF968A8.7060806@raszuk.net> <74470498B659FA4687F0B0018C19A89C01A0F8743C0A@IL-MB01.marvell.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060106000206020609000401" Cc: "l2vpn@ietf.org" , "robert@raszuk.net" , Shankar Raman M J , Balaji venkat Venkataswami , "tictoc@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:07:14 -0000 This is a multi-part message in MIME format. --------------060106000206020609000401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > If we use the EF-PHB with green as drop probability all P routers need > not know about the PTP LSP. This has been stated in the PTP over MPLS > draft. > Given that forwarders are work conserving, a packet that has already started will go to completion, so a high priority packet arriving after the transmit decision has been taken by the forwarder waits. The now devalued timing packet goes ahead of all other packets, some of which are less devalued by the delay. I am worried that giving timing packet priority degrades the network without achieving anything for the timing system. Do we have any measured evidence that sending timing packets with a high priority is actually beneficial? If so can someone please point me at it. Thanks Stewart --------------060106000206020609000401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

If we use the EF-PHB with green as drop probability all P routers need not know about the PTP LSP. This has been stated in the PTP over MPLS draft.

Given that forwarders are work conserving, a packet that has already started will go to completion, so a high priority packet arriving after the transmit decision has been taken by the forwarder waits. The now devalued timing packet goes ahead of all other packets, some of which are less devalued by the delay. I am worried that giving timing packet priority degrades the network without achieving anything for the timing system.

Do we have any measured evidence that sending timing packets with a high priority is actually beneficial? If so can someone please point me at it.

Thanks

Stewart

--------------060106000206020609000401-- From Internet-Drafts@ietf.org Wed Jul 11 08:53:17 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B6221F853B; Wed, 11 Jul 2012 08:53:17 -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 O1eTewAv0xS0; Wed, 11 Jul 2012 08:53:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9950821F8532; Wed, 11 Jul 2012 08:53:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-vpls-mcast-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120711155314.24816.62516.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 08:53:14 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:53:17 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Multicast in VPLS Author(s) : R. Aggarwal, et al Filename : draft-ietf-l2vpn-vpls-mcast Pages : 47 Date : July 11, 2012 This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-07-11085314.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Sun Jul 15 22:27:36 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4821F85C2; Sun, 15 Jul 2012 22:27:36 -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.084, 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 3yMCBV0U-iqO; Sun, 15 Jul 2012 22:27:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9B521F85C5; Sun, 15 Jul 2012 22:27:35 -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 Subject: I-D Action: draft-ietf-l2vpn-evpn-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716052735.29514.10923.idtracker@ietfa.amsl.com> Date: Sun, 15 Jul 2012 22:27:35 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 05:27:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : BGP MPLS Based Ethernet VPN Author(s) : Ali Sajassi Rahul Aggarwal Wim Henderickx Florin Balus Aldrin Isaac James Uttaro Filename : draft-ietf-l2vpn-evpn-01.txt Pages : 43 Date : 2012-07-15 Abstract: This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-evpn-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-evpn-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 08:12:55 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139DC21F8760; Mon, 16 Jul 2012 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUe8+GaIKlfF; Mon, 16 Jul 2012 08:12:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF5A21F8707; Mon, 16 Jul 2012 08:12:54 -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 Subject: I-D Action: draft-ietf-l2vpn-vpls-pim-snooping-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716151254.26553.97170.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 08:12:54 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:12:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : PIM Snooping over VPLS Author(s) : Olivier Dornon Jayant Kotalwar Jeffrey Zhang Venu Hemige Filename : draft-ietf-l2vpn-vpls-pim-snooping-02.txt Pages : 39 Date : 2012-07-16 Abstract: In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Networks, the switches simply flood multicast traffic on all ports in the LAN by default. IGMP Snooping is commonly deployed to ensure multicast traffic is not forwarded on ports without IGMP receivers. The procedures and recommendations for IGMP Snooping are defined in [IGMP-SNOOP]. But when any protocol other than IGMP is used, the common practice is to simply flood multicast traffic to all ports. PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM Snooping procedures are important to restrict multicast traffic to only the routers interested in receiving such traffic. While most of the PIM Snooping procedures defined here also apply to IEEE Bridged Networks, VPLS demands certain special procedures due to the split-horizon rules that require the Provider Edge (PE) devices to co-operate. This document describes the procedures and recommendations for PIM-Snooping in VPLS to facilitate replication to only those ports behind which there are interested PIM routers and/or IGMP hosts. This document also describes procedures for PIM Proxy. PIM Proxy is required on PEs for VPLS Multicast to work correctly when Join suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS Multicast much better than just PIM Snooping. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-pim-snooping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pim-snooping-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-pim-snooping-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nabil.n.bitar@verizon.com Mon Jul 16 10:49:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B198911E8276 for ; Mon, 16 Jul 2012 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RwIvjcHuIyY for ; Mon, 16 Jul 2012 10:49:55 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF5811E8275 for ; Mon, 16 Jul 2012 10:49:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 16 Jul 2012 17:50:40 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208,217";a="299268027" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi03.verizon.com with ESMTP; 16 Jul 2012 17:50:39 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([166.68.45.45]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Mon, 16 Jul 2012 13:50:39 -0400 To: "l2vpn@ietf.org" Date: Mon, 16 Jul 2012 13:50:37 -0400 Subject: [l2vpn] IETF-84 Vancouver: Internet Draft final submission deadline today (July 16) by 17:00 PT Thread-Topic: [l2vpn] IETF-84 Vancouver: Internet Draft final submission deadline today (July 16) by 17:00 PT Thread-Index: Ac1je4KjuREMjkPZQj2YwFfXBTZfYQ== 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.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC29CB6B36E32nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:49:56 -0000 --_000_CC29CB6B36E32nabilnbitarverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Just a reminder that the deadline is today (July 16) by 17:00 PT for draft = final submission. Thanks, Nabil and Giles From: "Bitar, Nabil N" > Date: Tue, 3 Jul 2012 16:37:49 -0400 To: "l2vpn@ietf.org" > Cc: Giles Heron > Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 84 - Vancouver Hi L2VPN WG. Please let us know if you have a time-slot request for the L2VPN session at= IETF 84=96Vancouver. Please, email us your request by Sunday July 15, 201= 2 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Additional key dates to remember are: 2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PT (UTC -7) 2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT (U= TC -7) Thanks, Nabil and Giles --_000_CC29CB6B36E32nabilnbitarverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,
Just a reminder t= hat the deadline is today (July 16) by 17:00 PT for draft final submission.=

Thanks,
Nabil and Giles

<= /div>

From: &qu= ot;Bitar, Nabil N" <nabil.n.bitar@one.verizon.com>
Date: Tue, 3 Jul 2012 16:37:49 -0400
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Giles Heron <giheron@cisco.com>
Subject: [l2vpn] L2VPN Agenda Slot Call for IETF 84 - Vanco= uver

Hi L2VPN WG.
<= div>
Please let us know if you have a time-slot request for the L2VPN session at= IETF 84=96Vancouver. Please, email us your request by Sunday July 15= , 2012 along with the following information:
1) Draft title
2) Presenter name
3) Requested duration

Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter.

Additional key dates to remember are:
2012= -07-09 (Monday): Internet Draft Cut-off for initial document (-00)= submission by 17:00 PT (UTC -7)

2012-07-16 (Monday): Internet Draft fi= nal submission cut-off by 17:00 PT (UTC -7)
<= div style=3D"color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sa= ns-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-bre= ak: after-white-space; ">

Thanks,
Nabil and Giles
=
--_000_CC29CB6B36E32nabilnbitarverizoncom_-- From internet-drafts@ietf.org Mon Jul 16 14:46:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0559711E8115; Mon, 16 Jul 2012 14:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 I+tJPlHxQ13n; Mon, 16 Jul 2012 14:46:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163E311E810B; Mon, 16 Jul 2012 14:46:00 -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 Subject: I-D Action: draft-ietf-l2vpn-ipls-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716214600.7891.80482.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:46:00 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:46:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : IP-Only LAN Service (IPLS) Author(s) : Himanshu Shah Eric Rosen Francois Le Faucheur Giles Heron Filename : draft-ietf-l2vpn-ipls-10.txt Pages : 25 Date : 2012-07-16 Abstract: A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-ipls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-ipls-10 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-ipls-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From giles.heron@gmail.com Wed Jul 18 11:28:08 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE6911E8157 for ; Wed, 18 Jul 2012 11:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjL06B94vl2D for ; Wed, 18 Jul 2012 11:28:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCF011E813B for ; Wed, 18 Jul 2012 11:28:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3084663pbc.31 for ; Wed, 18 Jul 2012 11:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=d5y+MQJVaPtjAyHt177T5WrLTL321koc0X3VX74dkFg=; b=QpyLSvJSyqkCMGxmt8wOnRoB2AbKju2OY7MwP0ZqTAhlwwJWjUKyIkK3cWw/OU8h8W 8UgBAXjMoA8NMIzMSGYNY3cc6Wb9+0CYk0FtNlZOqJucX0EyWRRL2s7/4DBECheSPRhY LQbFNIsS/pmWTMm65AC037on0Qnx3a3WP9fPyZg/32zLwc5C8NEMkEGJJ0RalMC8pJoH HpAHInC3b3jhZ9ZeJjfYg0cGSGAo8g6y9r5PegpD5DXwiHBzguoD96D7dHZtCHdSbN0H 8qDhpgF34Bm3TAQJ9lkEGQ+QNxvbjtGSzx+1fBekXkFgQNYtIuOVVtrZL3zBrMfd9MqP 4mrA== Received: by 10.68.224.39 with SMTP id qz7mr9364811pbc.127.1342636138479; Wed, 18 Jul 2012 11:28:58 -0700 (PDT) Received: from dhcp-10-155-68-159.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id he9sm58343pbc.68.2012.07.18.11.28.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 11:28:57 -0700 (PDT) From: Giles Heron Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IETF 84 Agenda Date: Wed, 18 Jul 2012 19:28:53 +0100 Message-Id: <1244B2AF-8E1D-4C48-A141-8A32AB5C7FFB@gmail.com> To: l2vpn@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:28:08 -0000 Hi all, I've uploaded a first cut of the L2VPN agenda for IETF84 at: http://datatracker.ietf.org/meeting/84/agenda/l2vpn please do let me and Nabil know if there are any errors/omissions. Giles From giles.heron@gmail.com Thu Jul 19 08:59:18 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59E421F8714 for ; Thu, 19 Jul 2012 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbG8KCGnWQAc for ; Thu, 19 Jul 2012 08:59:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6467721F8681 for ; Thu, 19 Jul 2012 08:59:16 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4743277pbc.31 for ; Thu, 19 Jul 2012 09:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UeggJnaLto5rCGtGlp70FSG2P/TjCdkHzzIKs96dq0E=; b=yZRneB/JaWAyl5Zj68gNytF8+2ZWuQy5M8TKxtsPRAlBwaF7gpWstVRgLkGx3EqY/m 5p/gDk+4mlvUx2zKwX1HyOl4QplQBaT4trqLvLqMR92TkUjxKfMLCXYRau7CByfHSoIZ tHSXY327BfuUFO75SOIEC8Jmcn+JqU8KAEQ9V3oiospyaIZ+XrurNyqg7z0SRe9B0WJV Nn/Ycre8kUXyWYkjq+F9Iw3NU4007fH/9cYUJhKx5+oP7mutP4BHGw4JXe5k+csMAvAm aPSXYgyNcipLEbVOmDENOkTK6FUhuc8NRRflCQPv0q2eLINJEJI3r99YU8PaMNzodD1F SZMg== Received: by 10.68.196.228 with SMTP id ip4mr6232584pbc.82.1342713609900; Thu, 19 Jul 2012 09:00:09 -0700 (PDT) Received: from [10.155.80.70] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id hz10sm2025119pbc.32.2012.07.19.09.00.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 09:00:09 -0700 (PDT) Subject: Re: IETF 84 Agenda Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Giles Heron In-Reply-To: <1244B2AF-8E1D-4C48-A141-8A32AB5C7FFB@gmail.com> Date: Thu, 19 Jul 2012 17:00:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38E75CFF-21FE-41C6-A843-9D0EA9AEF7AD@gmail.com> References: <1244B2AF-8E1D-4C48-A141-8A32AB5C7FFB@gmail.com> To: l2vpn@ietf.org X-Mailer: Apple Mail (2.1278) X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 15:59:18 -0000 Hi again, I've updated the agenda to add in one or two slots that we missed or = that came in as late requests. The agenda is now 100% full - and please note that all speakers have 10 = minutes even if they asked for more. I'd encourage speakers to keep = their "presentation" to 5 minutes to leave half the time free for = discussion. We're going to have to be ruthless about shutting the mic = down at the end of the 10 minute slot, so I'd also encourage attendees = to keep questions short, sweet and to the point. As with David Sinicrope's mail on the PWE3 list I'd ask those listed on = the agenda to send an email to Nabil and me noting what objectives and = issues need to be discussed and resolved via the presentation. It'd be = helpful if you could include your slides with that email (we need to = have slides by 9am Vancouver time on Wednesday 1st August at the very = very latest). Also I'd like to ask now if we could please have a volunteer to take = notes, and another to jabber scribe. Thanks! Giles On 18 Jul 2012, at 19:28, Giles Heron wrote: > Hi all, >=20 > I've uploaded a first cut of the L2VPN agenda for IETF84 at: >=20 > http://datatracker.ietf.org/meeting/84/agenda/l2vpn >=20 > please do let me and Nabil know if there are any errors/omissions. >=20 > Giles From lucy.yong@huawei.com Mon Jul 23 16:54:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE5911E80F4 for ; Mon, 23 Jul 2012 16:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in9VfH98xE0z for ; Mon, 23 Jul 2012 16:54:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5B11E80F1 for ; Mon, 23 Jul 2012 16:54:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG94372; Mon, 23 Jul 2012 19:54:03 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 16:51:48 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 23 Jul 2012 16:51:50 -0700 From: Lucy yong To: "l2vpn@ietf.org" Subject: IPR on draft-sajassi-l2vpn-evpn-etree-00 Thread-Topic: IPR on draft-sajassi-l2vpn-evpn-etree-00 Thread-Index: Ac1pLh+agWCd4WbIRceObqnMe6edFA== Date: Mon, 23 Jul 2012 23:51:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D447E3A56@dfweml506-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.194] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D447E3A56dfweml506mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 23:54:05 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D447E3A56dfweml506mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there an IPR related to this solution? Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D447E3A56dfweml506mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there an IPR related to this solution?=

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D447E3A56dfweml506mbx_-- From sajassi@cisco.com Mon Jul 23 17:28:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2811E80FA for ; Mon, 23 Jul 2012 17:28:49 -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 ErT9AtDvD-l6 for ; Mon, 23 Jul 2012 17:28:48 -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 2A00B11E80F6 for ; Mon, 23 Jul 2012 17:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sajassi@cisco.com; l=4025; q=dns/txt; s=iport; t=1343089721; x=1344299321; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=XpeSpE+FJICAQhFPRr+yyJeiicSKZE1RKGyDtAz2Pb8=; b=QtoJbfvJJ6hAPS+VHyRq0V1GXxlbX+Q6CQqfU6DpIiBBlf568pCBupA2 uN5Trxt+fnVuhBdkt1SeT7HFbvHPffTUQN4hQI5a7uyq79gzjWqEvj4Ks b/SmsyTfQNDKqIfFK26QKh3+XTiLt73yYKMe1KiCS8wo/hPI40DDsMJik Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAI7rDVCtJV2d/2dsb2JhbABFgkqCYbQ3gQeCIAECBBIBGl4BCAQNAwECKDkUCQgBAQQBEhsHh2sBnDigDYtNhlMDlUmOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,641,1336348800"; d="scan'208,217";a="104575186" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 24 Jul 2012 00:28:40 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6O0SeCV027119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 00:28:40 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 19:28:40 -0500 From: "Ali Sajassi (sajassi)" To: Lucy yong , "l2vpn@ietf.org" Subject: Re: IPR on draft-sajassi-l2vpn-evpn-etree-00 Thread-Topic: IPR on draft-sajassi-l2vpn-evpn-etree-00 Thread-Index: Ac1pLh+agWCd4WbIRceObqnMe6edFP//6MMA Date: Tue, 24 Jul 2012 00:28:39 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D447E3A56@dfweml506-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.212.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.001 x-tm-as-result: No--24.321200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC333896811Fsajassiciscocom_" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 00:28:49 -0000 --_000_CC333896811Fsajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, there is no IPR on this draft and it was intended as such to come up wi= th a simple solution with no IPR on it. Cheers, Ali From: Lucy yong > Date: Monday, July 23, 2012 4:51 PM To: "l2vpn@ietf.org" > Subject: IPR on draft-sajassi-l2vpn-evpn-etree-00 Is there an IPR related to this solution? Lucy --_000_CC333896811Fsajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

No, there is no IPR on this draft and it was intended as such to come = up with a simple solution with no IPR on it.

Cheers,

Ali

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday, July 23, 2012 4:51 PM=
To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: IPR on draft-sajassi-l2vpn= -evpn-etree-00

Is there an IPR related to this solution?=

Lucy

--_000_CC333896811Fsajassiciscocom_-- From internet-drafts@ietf.org Sun Jul 29 23:34:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4163811E812C; Sun, 29 Jul 2012 23:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FUZZY_VLIUM=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 JfKV9DVPpLZt; Sun, 29 Jul 2012 23:34:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C504911E811A; Sun, 29 Jul 2012 23:34:31 -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 Subject: I-D Action: draft-ietf-l2vpn-ldp-vpls-broadcast-exten-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730063431.2665.2171.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2012 23:34:31 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 06:34:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : Extension to LDP-VPLS for Ethernet Broadcast and Multica= st Author(s) : Frederic Jounay Yuji Kamite Zhihua Liu Manuel Paul Ruediger Kunze Mach(Guoyi) Chen Lizhong Jin Filename : draft-ietf-l2vpn-ldp-vpls-broadcast-exten-04.txt Pages : 20 Date : 2012-07-29 Abstract: This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-ldp-vpls-broadcast-exten There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-ldp-vpls-broadcast-exten-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-ldp-vpls-broadcast-ex= ten-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 30 00:49:20 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271B521F85DB; Mon, 30 Jul 2012 00:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0lTmzAIwUaf7; Mon, 30 Jul 2012 00:49:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21E21F85F3; Mon, 30 Jul 2012 00:49:19 -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 Subject: I-D Action: draft-ietf-l2vpn-etree-frwk-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730074919.14402.43131.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 00:49:19 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 07:49:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : A Framework for E-Tree Service over MPLS Network Author(s) : Simon Delord Frederic Jounay Lucy Yong Lizhong Jin Yuji Kamite Wim Henderickx Filename : draft-ietf-l2vpn-etree-frwk-01.txt Pages : 29 Date : 2012-07-30 Abstract: This document proposes a solution framework for supporting Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-etree-frwk There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-etree-frwk-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-etree-frwk-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/