From nobody Mon Feb 2 10:39:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEC1A87A9 for ; Mon, 2 Feb 2015 10:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgtgJKrL0xhH for ; Mon, 2 Feb 2015 10:38:58 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 268231A884E for ; Mon, 2 Feb 2015 10:38:57 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.09,507,1418101200"; d="scan'208,217";a="213796786" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Feb 2015 13:30:28 -0500 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 2 Feb 2015 13:38:56 -0500 From: "George, Wes" To: Alia Atlas , "draft-ietf-sidr-as-migration@tools.ietf.org" , "sidr@ietf.org" Date: Mon, 2 Feb 2015 13:38:53 -0500 Thread-Topic: AD review and progressing draft-ietf-sidr-as-migration-02 Thread-Index: AdA/F4AazMPW/KhpQamgGz77RvqMOg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D0F5254B41CBAwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:39:00 -0000 --_000_D0F5254B41CBAwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSDigJMgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiBDb25zaWRlciB0aGlzIEFDSyBmb3IgYWxs IGNvbW1lbnRzIGV4Y2VwdCB0aGUgb25lcyBiZWxvdywgaW5saW5lIHdpdGggV0ddDQpJIGhhdmUg YSDigJMwMyBkcmFmdCBpbiB0aGUgZWRpdCBidWZmZXIsIGFuZCB3aWxsIHB1Ymxpc2ggb25jZSB0 aGUgYmVsb3cgaXMgcmVzb2x2ZWQuDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KRnJvbTogQWxpYSBB dGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4NCkRhdGU6 IEZyaWRheSwgSmFudWFyeSAzMCwgMjAxNSBhdCAzOjUwIFBNDQpUbzogImRyYWZ0LWlldGYtc2lk ci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1t aWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5p ZXRmLm9yZz4+LCAic2lkckBpZXRmLm9yZzxtYWlsdG86c2lkckBpZXRmLm9yZz4iIDxzaWRyQGll dGYub3JnPG1haWx0bzpzaWRyQGlldGYub3JnPj4NClN1YmplY3Q6IEFEIHJldmlldyBhbmQgcHJv Z3Jlc3NpbmcgZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbi0wMg0KUmVzZW50LVRvOiA8c2Fu ZHlAdGlzbGFicy5jb208bWFpbHRvOnNhbmR5QHRpc2xhYnMuY29tPj4sICJHZW9yZ2UsIFdlcyIg PHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5j b20+Pg0KDQphKSBMYW5ndWFnZSBhcm91bmQgZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uIGlz IG1vcmUgdGVudGF0aXZlIHRoYW4gaXMgYXBwcm9wcmlhdGUNCndoZW4gdGhhdCBkcmFmdCBhbmQg dGhpcyBhcmUgZ29pbmcgdG8gYmUgUkZDcy4gIFBsZWFzZSBjbGVhbiB0aGF0IHVwLg0KDQpXR10g b3RoZXIgdGhhbiByZW1vdmluZyB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNCAoZG9u ZSksIGFuZCBmaXhpbmcgdGhlIGludHJvIChyZW1vdmVkIGRlIGZhY3RvKSwgd2VyZSB0aGVyZSBv dGhlciBwbGFjZXMgdGhhdCB0aGlzIG5lZWRzIHRvIGJlIGFkZHJlc3NlZD8NCg0KDQpiKSBJbiBT ZWMgMy4xLCBpdCBzYXlzDQoNCiJJZiB0aGUgcm91dGUgbm93IHNob3dzIHVwIGFzIG9yaWdpbmF0 aW5nDQogICBmcm9tIEFTNjQ1MDAsIGFueSBkb3duc3RyZWFtIHBlZXJzJyB2YWxpZGF0aW9uIGNo ZWNrIHdpbGwgZmFpbCB1bmxlc3MNCiAgIGEgUk9BIGlzICphbHNvKiBhdmFpbGFibGUgZm9yIEFT NjQ1MDAgYXMgdGhlIG9yaWdpbiBBU04sIG1lYW5pbmcgdGhhdA0KICAgdGhlcmUgd2lsbCBiZSBv dmVybGFwcGluZyBST0FzIHVudGlsIGFsbCByb3V0ZXJzIG9yaWdpbmF0aW5nIHByZWZpeGVzDQog ICBmcm9tIEFTNjQ1MTAgYXJlIG1pZ3JhdGVkIHRvIEFTNjQ1MDAuIg0KDQpJIHRoaW5rIHRoZSBz ZWNvbmQgQVM2NDUwMCBzaG91bGQgYmUgQVM2NDUxMC4NCg0KV0ddIG5vLiBUaGlzIGlzIHNheWlu ZyB0aGF0IGEgUk9BIGFscmVhZHkgZXhpc3RzIGZvciA2NDUxMCwgYnV0IG5lZWRzIHRvIGV4aXN0 IGZvciA2NDUwMC4gVGhlIGRpc3RpbmN0aW9uIHRoZSBzZWNvbmQgaGFsZiBvZiB0aGF0IHNlY3Rp b24gaXMgbWFraW5nIGlzIHRoYXQgaW4gYWRkaXRpb24gdG8gZ2VuZXJhdGluZyBhIFJPQSBmb3Ig NjU0MDAgZm9yIGFueSBwcmVmaXhlcyBvcmlnaW5hdGVkIGJ5IHRoZSByb3V0ZXIgYmVpbmcgbW92 ZWQsIGJlY2F1c2Ugb2YgcmVwbGFjZS1BUywgeW91IG1heSBoYXZlIHRvIGdlbmVyYXRlIFJPQXMg Zm9yIDY1NDAwIGZvciByb3V0ZXMgdGhhdCBhcmUgb3JpZ2luYXRpbmcgb24gcm91dGVycyBzdGls bCBpbiA2NTQxMC4gSWYgdGhhdCBleHBsYW5hdGlvbiBpcyBhbnkgY2xlYXJlciwgSSBjYW4gdHJ5 IHRvIGVkaXQgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzLg0KDQoNCg0KZSkgSW4gZHJhZnQtaWV0 Zi1pZHItYXMtbWlncmF0aW9uLCB0aGUgY2FzZSBvZiBoYW5kbGluZyBBUyBtaWdyYXRpb24gaW4g aUJHUCBzZXNzaW9ucyBpcyBhbHNvIGNvdmVyZWQuICBJIGFzc3VtZSB0aGF0IGJlY2F1c2UgaXQg aXMgaUJHUCBzZXNzaW9ucywgdGhlcmUgaXMgbm8gd29yayB0byBiZSBkb25lIGZvciBCR1BzZWMu ICBDb3VsZCB5b3UgcGxlYXNlIGFkZCBhIHF1aWNrIG9idmlvdXMgc3RhdGVtZW50IHRvIHRoYXQg ZWZmZWN0Pw0KDQpXR10gaG1tLiBUaGlzIHNvbHV0aW9uIHdhcyBvcmlnaW5hbGx5IHdyaXR0ZW4g YmVmb3JlIHRoZSBpQkdQIHN0dWZmIHdhcyBhZGRlZCwgYW5kIGl0IGRpZG4ndCBvY2N1ciB0byBt ZSB0aGF0IGl0IG1heSBuZWVkIHRvIGJlIGRpc2N1c3NlZCBoZXJlLiBQaXRmYWxscyBvZiB0d28g bGFyZ2VseSBwYXJhbGxlbCBkb2NzLCBJIGd1ZXNzLg0KVGhlIGlCR1AgQVMgbWlncmF0aW9uIGRp c2N1c3NlZCBpcyBiYXNpY2FsbHkganVzdCBsaXN0ZW5pbmcgZm9yIG9wZW4gb24gZWl0aGVyIEFT TiwgYnV0IG90aGVyd2lzZSB0cmVhdHMgdGhlIHNlc3Npb24gYXMgaUJHUCBldmVuIGlmIHRoZSBB U04gaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBnbG9iYWxseS1jb25maWd1cmVkIG9uZS4gVGh1cyB0 aGVyZSBhcmUgdHdvIEFTTnMgaW52b2x2ZWQsIGFuZCB0aGlzIGlzIG1haW5seSB0aGUgc2FtZSBh cyBBUyBtaWdyYXRpb24gd2l0aCBlQkdQLCBpbiB0aGF0IHRoZSBtaWdyYXRpbmcgcm91dGVyIHdv dWxkIG5lZWQgdG8gaGF2ZSBhIHBjb3VudD0wIGZyb20gb2xkIEFTTiB0byBOZXcgaW4gb3JkZXIg dG8gaGlkZSB0aGF0IHBhdGggaW4gcm91dGVzIHRoYXQgYXJlIHNpZ25lZCB0byB0aGUgb2xkIEFT TiBmcm9tIGRvd25zdHJlYW0gZUJHUCBwZWVycy4gVGhlIHdyaW5rbGUgaXMgdGhhdCBpbnN0ZWFk IG9mIHRoZSBtaWdyYXRpb24gcG9pbnQgYmVpbmcgb24gdGhlIGVkZ2Ugcm91dGVyIGJldHdlZW4g aXRzIGVCR1AgcGVlcnMgYW5kIGl0cyBpQkdQIHBlZXJzLCB0aGUgbWlncmF0aW9uIHBvaW50IGlz IG5vdyBvbmUgcm91dGVyIHVwc3RyZWFtLCBiZXR3ZWVuIHR3byBpQkdQIHBlZXJzIChpLmUuIFRo ZSByb3V0ZXIgaW4gdGhlIG9sZCBBU04gZG9lc24ndCBuZWNlc3NhcmlseSBrbm93IHRvIG1hc2sg aXRzIGdsb2JhbCBBU04gd2l0aCBwY291bnQ9MCwgYW5kIHNvIHRoZSByb3V0ZXIgdGhhdCBpcyBh dCB0aGUgYWN0dWFsIGJvcmRlciBiZXR3ZWVuIHRoZSB0d28gQVNOcyB3aWxsIGhhdmUgdG8gZG8g dGhlIHBjb3VudD0wIHRyaWNrIHRvIHRoZSAiaUJHUCIgdXBkYXRlcyBpdCByZWNlaXZlcy4gSSds bCBuZWVkIHRvIGFkZCBzb21lIHRleHQgaW4gNS4zIHRvIGNvdmVyIHRoaXMgY2FzZS4gR29vZCBj YXRjaC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9y IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1l bnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_D0F5254B41CBAwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFsaWEg4oCTIHRoYW5rcyBmb3IgdGhlIHJldmlldy4gQ29uc2lkZXIgdGhpcyBBQ0sgZm9y IGFsbCBjb21tZW50cyBleGNlcHQgdGhlIG9uZXMgYmVsb3csIGlubGluZSB3aXRoIFdHXTwvZGl2 Pg0KPGRpdj5JIGhhdmUgYSDigJMwMyBkcmFmdCBpbiB0aGUgZWRpdCBidWZmZXIsIGFuZCB3aWxs IHB1Ymxpc2ggb25jZSB0aGUgYmVsb3cgaXMgcmVzb2x2ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7Ij5XZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+PGJyPg0KPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBC T1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURE SU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBC T1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPkFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+ YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IGF0IDM6NTAgUE08YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZyI+ZHJh ZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3Jn Ij5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPC9hPiZndDssDQog JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2lkckBpZXRmLm9yZyI+c2lkckBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5B RCByZXZpZXcgYW5kIHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb24tMDI8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVzZW50LVRvOiA8L3NwYW4+Jmx0 OzxhIGhyZWY9Im1haWx0bzpzYW5keUB0aXNsYWJzLmNvbSI+c2FuZHlAdGlzbGFicy5jb208L2E+ Jmd0OywgJnF1b3Q7R2VvcmdlLCBXZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXku Z2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDs8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5hKSBMYW5ndWFnZSBh cm91bmQgZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uIGlzIG1vcmUgdGVudGF0aXZlIHRoYW4g aXMgYXBwcm9wcmlhdGUNCjxkaXY+d2hlbiB0aGF0IGRyYWZ0IGFuZCB0aGlzIGFyZSBnb2luZyB0 byBiZSBSRkNzLiZuYnNwOyBQbGVhc2UgY2xlYW4gdGhhdCB1cC48L2Rpdj4NCjwvZGl2Pg0KPC9z cGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIG90aGVyIHRoYW4gcmVtb3ZpbmcgdGhl IGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQgKGRvbmUpLCBhbmQgZml4aW5nIHRoZSBpbnRy byAocmVtb3ZlZCBkZSBmYWN0byksIHdlcmUgdGhlcmUgb3RoZXIgcGxhY2VzIHRoYXQgdGhpcyBu ZWVkcyB0byBiZSBhZGRyZXNzZWQ/Jm5ic3A7PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjxicj4NCmIpIEluIFNlYyAz LjEsIGl0IHNheXM8YnI+DQo8YnI+DQomcXVvdDtJZiB0aGUgcm91dGUgbm93IHNob3dzIHVwIGFz IG9yaWdpbmF0aW5nPGJyPg0KJm5ic3A7ICZuYnNwO2Zyb20gQVM2NDUwMCwgYW55IGRvd25zdHJl YW0gcGVlcnMnIHZhbGlkYXRpb24gY2hlY2sgd2lsbCBmYWlsIHVubGVzczxicj4NCiZuYnNwOyAm bmJzcDthIFJPQSBpcyAqYWxzbyogYXZhaWxhYmxlIGZvciBBUzY0NTAwIGFzIHRoZSBvcmlnaW4g QVNOLCBtZWFuaW5nIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7dGhlcmUgd2lsbCBiZSBvdmVybGFw cGluZyBST0FzIHVudGlsIGFsbCByb3V0ZXJzIG9yaWdpbmF0aW5nIHByZWZpeGVzPGJyPg0KJm5i c3A7ICZuYnNwO2Zyb20gQVM2NDUxMCBhcmUgbWlncmF0ZWQgdG8gQVM2NDUwMC4mcXVvdDs8YnI+ DQo8YnI+DQpJIHRoaW5rIHRoZSBzZWNvbmQgQVM2NDUwMCBzaG91bGQgYmUgQVM2NDUxMC48L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIG5vLiBUaGlz IGlzIHNheWluZyB0aGF0IGEgUk9BIGFscmVhZHkgZXhpc3RzIGZvciA2NDUxMCwgYnV0IG5lZWRz IHRvIGV4aXN0IGZvciA2NDUwMC4gVGhlIGRpc3RpbmN0aW9uIHRoZSBzZWNvbmQgaGFsZiBvZiB0 aGF0IHNlY3Rpb24gaXMgbWFraW5nIGlzIHRoYXQgaW4gYWRkaXRpb24gdG8gZ2VuZXJhdGluZyBh IFJPQSBmb3IgNjU0MDAgZm9yIGFueSBwcmVmaXhlcyBvcmlnaW5hdGVkIGJ5IHRoZSByb3V0ZXIg YmVpbmcgbW92ZWQsDQogYmVjYXVzZSBvZiByZXBsYWNlLUFTLCB5b3UgbWF5IGhhdmUgdG8gZ2Vu ZXJhdGUgUk9BcyBmb3IgNjU0MDAgZm9yIHJvdXRlcyB0aGF0IGFyZSBvcmlnaW5hdGluZyBvbiBy b3V0ZXJzIHN0aWxsIGluIDY1NDEwLiBJZiB0aGF0IGV4cGxhbmF0aW9uIGlzIGFueSBjbGVhcmVy LCBJIGNhbiB0cnkgdG8gZWRpdCB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMuJm5ic3A7PC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2 Pjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxLjJlbTtt YXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6 ZToxMi43MjcyNzIwMzM2OTE0cHgiPmUpIEluIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNv bG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij5kcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24sIHRoZSBj YXNlIG9mIGhhbmRsaW5nIEFTIG1pZ3JhdGlvbiBpbiBpQkdQIHNlc3Npb25zIGlzIGFsc28gY292 ZXJlZC4gIEkgYXNzdW1lIHRoYXQgYmVjYXVzZSBpdCBpcyBpQkdQIHNlc3Npb25zLCB0aGVyZSBp cyBubyB3b3JrIHRvIGJlIGRvbmUgZm9yIEJHUHNlYy4gIENvdWxkIHlvdSBwbGVhc2UgYWRkIGEg cXVpY2sgb2J2aW91cyBzdGF0ZW1lbnQgdG8gdGhhdCBlZmZlY3Q/PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBobW0uIFRo aXMgc29sdXRpb24gd2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBiZWZvcmUgdGhlIGlCR1Agc3R1ZmYg d2FzIGFkZGVkLCBhbmQgaXQgZGlkbid0IG9jY3VyIHRvIG1lIHRoYXQgaXQgbWF5IG5lZWQgdG8g YmUgZGlzY3Vzc2VkIGhlcmUuIFBpdGZhbGxzIG9mIHR3byBsYXJnZWx5IHBhcmFsbGVsIGRvY3Ms IEkgZ3Vlc3MuJm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBpQkdQIEFTIG1pZ3JhdGlvbiBkaXNjdXNz ZWQgaXMgYmFzaWNhbGx5IGp1c3QgbGlzdGVuaW5nIGZvciBvcGVuIG9uIGVpdGhlciBBU04sIGJ1 dCBvdGhlcndpc2UgdHJlYXRzIHRoZSBzZXNzaW9uIGFzIGlCR1AgZXZlbiBpZiB0aGUgQVNOIGlz IG5vdCB0aGUgc2FtZSBhcyB0aGUgZ2xvYmFsbHktY29uZmlndXJlZCBvbmUuIFRodXMgdGhlcmUg YXJlIHR3byBBU05zIGludm9sdmVkLCBhbmQgdGhpcyBpcyBtYWlubHkgdGhlIHNhbWUgYXMNCiBB UyBtaWdyYXRpb24gd2l0aCBlQkdQLCBpbiB0aGF0IHRoZSBtaWdyYXRpbmcgcm91dGVyIHdvdWxk IG5lZWQgdG8gaGF2ZSBhIHBjb3VudD0wIGZyb20gb2xkIEFTTiB0byBOZXcgaW4gb3JkZXIgdG8g aGlkZSB0aGF0IHBhdGggaW4gcm91dGVzIHRoYXQgYXJlIHNpZ25lZCB0byB0aGUgb2xkIEFTTiBm cm9tIGRvd25zdHJlYW0gZUJHUCBwZWVycy4gVGhlIHdyaW5rbGUgaXMgdGhhdCBpbnN0ZWFkIG9m IHRoZSBtaWdyYXRpb24gcG9pbnQgYmVpbmcNCiBvbiB0aGUgZWRnZSByb3V0ZXIgYmV0d2VlbiBp dHMgZUJHUCBwZWVycyBhbmQgaXRzIGlCR1AgcGVlcnMsIHRoZSBtaWdyYXRpb24gcG9pbnQgaXMg bm93IG9uZSByb3V0ZXIgdXBzdHJlYW0sIGJldHdlZW4gdHdvIGlCR1AgcGVlcnMgKGkuZS4gVGhl IHJvdXRlciBpbiB0aGUgb2xkIEFTTiBkb2Vzbid0IG5lY2Vzc2FyaWx5IGtub3cgdG8gbWFzayBp dHMgZ2xvYmFsIEFTTiB3aXRoIHBjb3VudD0wLCBhbmQgc28gdGhlIHJvdXRlciB0aGF0IGlzIGF0 DQogdGhlIGFjdHVhbCBib3JkZXIgYmV0d2VlbiB0aGUgdHdvIEFTTnMgd2lsbCBoYXZlIHRvIGRv IHRoZSBwY291bnQ9MCB0cmljayB0byB0aGUgJnF1b3Q7aUJHUCZxdW90OyB1cGRhdGVzIGl0IHJl Y2VpdmVzLiBJJ2xsIG5lZWQgdG8gYWRkIHNvbWUgdGV4dCBpbiA1LjMgdG8gY292ZXIgdGhpcyBj YXNlLiBHb29kIGNhdGNoLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuMmVtO21h cmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXpl OjEyLjcyNzI3MjAzMzY5MTRweCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBhcmlhbCwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiBzbWFsbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgY29sb3I6IHJn YigzNCwgMzQsIDM0KTsiPjxicj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjJlbTttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDAp O2ZvbnQtc2l6ZToxMi43MjcyNzIwMzM2OTE0cHgiPjxicj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXpl PSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBU aW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmls ZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8g VGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0 aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWws IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50 cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1h bmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFu ZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D0F5254B41CBAwesleygeorgetwcablecom_-- From nobody Tue Feb 3 12:31:03 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901291A1A1E for ; Tue, 3 Feb 2015 12:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.226 X-Spam-Level: ** X-Spam-Status: No, score=2.226 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Hh0vyrf-E1 for ; Tue, 3 Feb 2015 12:30:50 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4B001A887E for ; Tue, 3 Feb 2015 12:30:49 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.09,514,1418101200"; d="scan'208,217";a="826881629" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Feb 2015 15:21:57 -0500 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 3 Feb 2015 15:30:49 -0500 From: "George, Wes" To: Alia Atlas , "draft-ietf-sidr-as-migration@tools.ietf.org" , "sidr@ietf.org" Date: Tue, 3 Feb 2015 15:30:46 -0500 Thread-Topic: AD review and progressing draft-ietf-sidr-as-migration-02 Thread-Index: AdA/8EtjPqrOVmOLToi/JJxtdXb8qg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D0F699CD41F96wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 20:30:54 -0000 --_000_D0F699CD41F96wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 dXBkYXRlOiBJIGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCBhdCB0aGUgZW5kIG9mIHNlY3Rpb24g NS4zIHRvIGNvdmVyIEFsaWEncyBxdWVzdGlvbiBhYm91dCBpQkdQIEFTIG1pZ3JhdGlvbi4gTGV0 IG1lIGtub3cgd2hldGhlciB0aGlzIGlzIGFjY2VwdGFibGU6DQoNCkFkZGl0aW9uYWxseSwgc2Vj dGlvbiA0IG9mIGRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbiBkaXNjdXNzZXMgbWV0aG9kcyBp biB3aGljaCBBUyBtaWdyYXRpb25zIGNhbiBiZSBjb21wbGV0ZWQgZm9yIGlCR1AgcGVlcnMgc3Vj aCB0aGF0IGEgc2Vzc2lvbiBiZXR3ZWVuIHR3byByb3V0ZXJzIHdpbGwgYmUgdHJlYXRlZCBhcyBp QkdQIGV2ZW4gaWYgdGhlIG5laWdoYm9yIEFTTiBpcyBub3QgdGhlIHNhbWUgQVNOIG9uIGVhY2gg cGVlcidzIGdsb2JhbCBjb25maWd1cmF0aW9uLiBBcyBmYXIgYXMgQkdQU2VjIGlzIGNvbmNlcm5l ZCwgdGhpcyByZXF1aXJlcyB0aGUgc2FtZSBwcm9jZWR1cmUgYXMgd2hlbiB0aGUgcm91dGVycyBt aWdyYXRpbmcgYXJlIGFwcGx5aW5nIEFTIG1pZ3JhdGlvbiBrbm9icyB0byBlQkdQIHBlZXJzLCBi dXQgdGhlIHJvdXRlciBmdW5jdGlvbmluZyBhcyB0aGUgIkFTQlIiIGJldHdlZW4gb2xkIGFuZCBu ZXcgQVNOIGlzIGRpZmZlcmVudC4gSW4gZUJHUCwgdGhlIHJvdXRlciBiZWluZyBtaWdyYXRlZCBo YXMgZGlyZWN0IGVCR1Agc2Vzc2lvbnMgdG8gdGhlIG9sZCBBU04gYW5kIHNpZ25zIGZyb20gb2xk IEFTTiB0byBuZXcgd2l0aCBwQ291bnQ9MCBiZWZvcmUgcGFzc2luZyB0aGUgdXBkYXRlIGFsb25n IHRvIGFkZGl0aW9uYWwgcm91dGVycyBpbiBpdHMgZ2xvYmFsIChuZXcpIEFTTi4gSW4gaUJHUCwg dGhlIHJvdXRlciBiZWluZyBtaWdyYXRlZCBpcyByZWNlaXZpbmcgdXBkYXRlcyAodGhhdCBtYXkg aGF2ZSBvcmlnaW5hdGVkIGVpdGhlciBmcm9tIGVCR1AgbmVpZ2hib3JzIG9yIG90aGVyIGlCR1Ag bmVpZ2hib3JzKSBmcm9tIGl0cyBkb3duc3RyZWFtIG5laWdoYm9ycyBpbiB0aGUgb2xkIEFTTiwg YW5kIE1VU1Qgc2lnbiB0aG9zZSB1cGRhdGVzIGZyb20gb2xkIEFTTiB0byBuZXcgd2l0aCBwQ291 bnQ9MCBiZWZvcmUgc2VuZGluZyB0aGVtIG9uIHRvIG90aGVyIHBlZXJzLg0KDQpUaGFua3MsDQoN Cldlcw0KDQoNCkZyb206IDxHZW9yZ2U+LCAiR2VvcmdlLCBXZXMiIDx3ZXNsZXkuZ2VvcmdlQHR3 Y2FibGUuY29tPG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPj4NCkRhdGU6IE1vbmRh eSwgRmVicnVhcnkgMiwgMjAxNSBhdCAxOjM4IFBNDQpUbzogQWxpYSBBdGxhcyA8YWthdGxhc0Bn bWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4sICJkcmFmdC1pZXRmLXNpZHItYXMt bWlncmF0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0 aW9uQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5v cmc+PiwgInNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+IiA8c2lkckBpZXRmLm9y ZzxtYWlsdG86c2lkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IGFuZCBwcm9n cmVzc2luZyBkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uLTAyDQpSZXNlbnQtVG86IDxzYW5k eUB0aXNsYWJzLmNvbTxtYWlsdG86c2FuZHlAdGlzbGFicy5jb20+PiwgIkdlb3JnZSwgV2VzIiA8 d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNv bT4+DQoNCkFsaWEg4oCTIHRoYW5rcyBmb3IgdGhlIHJldmlldy4gQ29uc2lkZXIgdGhpcyBBQ0sg Zm9yIGFsbCBjb21tZW50cyBleGNlcHQgdGhlIG9uZXMgYmVsb3csIGlubGluZSB3aXRoIFdHXQ0K SSBoYXZlIGEg4oCTMDMgZHJhZnQgaW4gdGhlIGVkaXQgYnVmZmVyLCBhbmQgd2lsbCBwdWJsaXNo IG9uY2UgdGhlIGJlbG93IGlzIHJlc29sdmVkLg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCkZyb206 IEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+ DQpEYXRlOiBGcmlkYXksIEphbnVhcnkgMzAsIDIwMTUgYXQgMzo1MCBQTQ0KVG86ICJkcmFmdC1p ZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNp ZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtc2lkci1hcy1taWdy YXRpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25A dG9vbHMuaWV0Zi5vcmc+PiwgInNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+IiA8 c2lkckBpZXRmLm9yZzxtYWlsdG86c2lkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBBRCByZXZpZXcg YW5kIHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb24tMDINClJlc2VudC1U bzogPHNhbmR5QHRpc2xhYnMuY29tPG1haWx0bzpzYW5keUB0aXNsYWJzLmNvbT4+LCAiR2Vvcmdl LCBXZXMiIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3 Y2FibGUuY29tPj4NCg0KYSkgTGFuZ3VhZ2UgYXJvdW5kIGRyYWZ0LWlldGYtaWRyLWFzLW1pZ3Jh dGlvbiBpcyBtb3JlIHRlbnRhdGl2ZSB0aGFuIGlzIGFwcHJvcHJpYXRlDQp3aGVuIHRoYXQgZHJh ZnQgYW5kIHRoaXMgYXJlIGdvaW5nIHRvIGJlIFJGQ3MuICBQbGVhc2UgY2xlYW4gdGhhdCB1cC4N Cg0KV0ddIG90aGVyIHRoYW4gcmVtb3ZpbmcgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9u IDQgKGRvbmUpLCBhbmQgZml4aW5nIHRoZSBpbnRybyAocmVtb3ZlZCBkZSBmYWN0byksIHdlcmUg dGhlcmUgb3RoZXIgcGxhY2VzIHRoYXQgdGhpcyBuZWVkcyB0byBiZSBhZGRyZXNzZWQ/DQoNCg0K YikgSW4gU2VjIDMuMSwgaXQgc2F5cw0KDQoiSWYgdGhlIHJvdXRlIG5vdyBzaG93cyB1cCBhcyBv cmlnaW5hdGluZw0KICAgZnJvbSBBUzY0NTAwLCBhbnkgZG93bnN0cmVhbSBwZWVycycgdmFsaWRh dGlvbiBjaGVjayB3aWxsIGZhaWwgdW5sZXNzDQogICBhIFJPQSBpcyAqYWxzbyogYXZhaWxhYmxl IGZvciBBUzY0NTAwIGFzIHRoZSBvcmlnaW4gQVNOLCBtZWFuaW5nIHRoYXQNCiAgIHRoZXJlIHdp bGwgYmUgb3ZlcmxhcHBpbmcgUk9BcyB1bnRpbCBhbGwgcm91dGVycyBvcmlnaW5hdGluZyBwcmVm aXhlcw0KICAgZnJvbSBBUzY0NTEwIGFyZSBtaWdyYXRlZCB0byBBUzY0NTAwLiINCg0KSSB0aGlu ayB0aGUgc2Vjb25kIEFTNjQ1MDAgc2hvdWxkIGJlIEFTNjQ1MTAuDQoNCldHXSBuby4gVGhpcyBp cyBzYXlpbmcgdGhhdCBhIFJPQSBhbHJlYWR5IGV4aXN0cyBmb3IgNjQ1MTAsIGJ1dCBuZWVkcyB0 byBleGlzdCBmb3IgNjQ1MDAuIFRoZSBkaXN0aW5jdGlvbiB0aGUgc2Vjb25kIGhhbGYgb2YgdGhh dCBzZWN0aW9uIGlzIG1ha2luZyBpcyB0aGF0IGluIGFkZGl0aW9uIHRvIGdlbmVyYXRpbmcgYSBS T0EgZm9yIDY1NDAwIGZvciBhbnkgcHJlZml4ZXMgb3JpZ2luYXRlZCBieSB0aGUgcm91dGVyIGJl aW5nIG1vdmVkLCBiZWNhdXNlIG9mIHJlcGxhY2UtQVMsIHlvdSBtYXkgaGF2ZSB0byBnZW5lcmF0 ZSBST0FzIGZvciA2NTQwMCBmb3Igcm91dGVzIHRoYXQgYXJlIG9yaWdpbmF0aW5nIG9uIHJvdXRl cnMgc3RpbGwgaW4gNjU0MTAuIElmIHRoYXQgZXhwbGFuYXRpb24gaXMgYW55IGNsZWFyZXIsIEkg Y2FuIHRyeSB0byBlZGl0IHRoZSB0ZXh0IHRvIHJlZmxlY3QgdGhpcy4NCg0KDQoNCmUpIEluIGRy YWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbiwgdGhlIGNhc2Ugb2YgaGFuZGxpbmcgQVMgbWlncmF0 aW9uIGluIGlCR1Agc2Vzc2lvbnMgaXMgYWxzbyBjb3ZlcmVkLiAgSSBhc3N1bWUgdGhhdCBiZWNh dXNlIGl0IGlzIGlCR1Agc2Vzc2lvbnMsIHRoZXJlIGlzIG5vIHdvcmsgdG8gYmUgZG9uZSBmb3Ig QkdQc2VjLiAgQ291bGQgeW91IHBsZWFzZSBhZGQgYSBxdWljayBvYnZpb3VzIHN0YXRlbWVudCB0 byB0aGF0IGVmZmVjdD8NCg0KV0ddIGhtbS4gVGhpcyBzb2x1dGlvbiB3YXMgb3JpZ2luYWxseSB3 cml0dGVuIGJlZm9yZSB0aGUgaUJHUCBzdHVmZiB3YXMgYWRkZWQsIGFuZCBpdCBkaWRuJ3Qgb2Nj dXIgdG8gbWUgdGhhdCBpdCBtYXkgbmVlZCB0byBiZSBkaXNjdXNzZWQgaGVyZS4gUGl0ZmFsbHMg b2YgdHdvIGxhcmdlbHkgcGFyYWxsZWwgZG9jcywgSSBndWVzcy4NClRoZSBpQkdQIEFTIG1pZ3Jh dGlvbiBkaXNjdXNzZWQgaXMgYmFzaWNhbGx5IGp1c3QgbGlzdGVuaW5nIGZvciBvcGVuIG9uIGVp dGhlciBBU04sIGJ1dCBvdGhlcndpc2UgdHJlYXRzIHRoZSBzZXNzaW9uIGFzIGlCR1AgZXZlbiBp ZiB0aGUgQVNOIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgZ2xvYmFsbHktY29uZmlndXJlZCBvbmUu IFRodXMgdGhlcmUgYXJlIHR3byBBU05zIGludm9sdmVkLCBhbmQgdGhpcyBpcyBtYWlubHkgdGhl IHNhbWUgYXMgQVMgbWlncmF0aW9uIHdpdGggZUJHUCwgaW4gdGhhdCB0aGUgbWlncmF0aW5nIHJv dXRlciB3b3VsZCBuZWVkIHRvIGhhdmUgYSBwY291bnQ9MCBmcm9tIG9sZCBBU04gdG8gTmV3IGlu IG9yZGVyIHRvIGhpZGUgdGhhdCBwYXRoIGluIHJvdXRlcyB0aGF0IGFyZSBzaWduZWQgdG8gdGhl IG9sZCBBU04gZnJvbSBkb3duc3RyZWFtIGVCR1AgcGVlcnMuIFRoZSB3cmlua2xlIGlzIHRoYXQg aW5zdGVhZCBvZiB0aGUgbWlncmF0aW9uIHBvaW50IGJlaW5nIG9uIHRoZSBlZGdlIHJvdXRlciBi ZXR3ZWVuIGl0cyBlQkdQIHBlZXJzIGFuZCBpdHMgaUJHUCBwZWVycywgdGhlIG1pZ3JhdGlvbiBw b2ludCBpcyBub3cgb25lIHJvdXRlciB1cHN0cmVhbSwgYmV0d2VlbiB0d28gaUJHUCBwZWVycyAo aS5lLiBUaGUgcm91dGVyIGluIHRoZSBvbGQgQVNOIGRvZXNuJ3QgbmVjZXNzYXJpbHkga25vdyB0 byBtYXNrIGl0cyBnbG9iYWwgQVNOIHdpdGggcGNvdW50PTAsIGFuZCBzbyB0aGUgcm91dGVyIHRo YXQgaXMgYXQgdGhlIGFjdHVhbCBib3JkZXIgYmV0d2VlbiB0aGUgdHdvIEFTTnMgd2lsbCBoYXZl IHRvIGRvIHRoZSBwY291bnQ9MCB0cmljayB0byB0aGUgImlCR1AiIHVwZGF0ZXMgaXQgcmVjZWl2 ZXMuIEknbGwgbmVlZCB0byBhZGQgc29tZSB0ZXh0IGluIDUuMyB0byBjb3ZlciB0aGlzIGNhc2Uu IEdvb2QgY2F0Y2guDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBh dHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRv dXQuDQo= --_000_D0F699CD41F96wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxkaXY+PGRpdj51cGRhdGU6IEkgYWRkZWQgdGhlIGZvbGxv d2luZyB0ZXh0IGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA1LjMgdG8gY292ZXIgQWxpYSdzIHF1ZXN0 aW9uIGFib3V0IGlCR1AgQVMgbWlncmF0aW9uLiBMZXQgbWUga25vdyB3aGV0aGVyIHRoaXMgaXMg YWNjZXB0YWJsZTo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+QWRkaXRpb25hbGx5LCBz ZWN0aW9uIDQgb2YgZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uIGRpc2N1c3NlcyBtZXRob2Rz IGluIHdoaWNoIEFTIG1pZ3JhdGlvbnMgY2FuIGJlIGNvbXBsZXRlZCBmb3IgaUJHUCBwZWVycyBz dWNoIHRoYXQgYSBzZXNzaW9uIGJldHdlZW4gdHdvIHJvdXRlcnMgd2lsbCBiZSB0cmVhdGVkIGFz IGlCR1AgZXZlbiBpZiB0aGUgbmVpZ2hib3IgQVNOIGlzIG5vdCB0aGUgc2FtZSBBU04gb24gZWFj aCBwZWVyJ3MgZ2xvYmFsIGNvbmZpZ3VyYXRpb24uIEFzIGZhciBhcyBCR1BTZWMgaXMgY29uY2Vy bmVkLCB0aGlzIHJlcXVpcmVzIHRoZSBzYW1lIHByb2NlZHVyZSBhcyB3aGVuIHRoZSByb3V0ZXJz IG1pZ3JhdGluZyBhcmUgYXBwbHlpbmcgQVMgbWlncmF0aW9uIGtub2JzIHRvIGVCR1AgcGVlcnMs IGJ1dCB0aGUgcm91dGVyIGZ1bmN0aW9uaW5nIGFzIHRoZSAiQVNCUiIgYmV0d2VlbiBvbGQgYW5k IG5ldyBBU04gaXMgZGlmZmVyZW50LiBJbiBlQkdQLCB0aGUgcm91dGVyIGJlaW5nIG1pZ3JhdGVk IGhhcyBkaXJlY3QgZUJHUCBzZXNzaW9ucyB0byB0aGUgb2xkIEFTTiBhbmQgc2lnbnMgZnJvbSBv bGQgQVNOIHRvIG5ldyB3aXRoIHBDb3VudD0wIGJlZm9yZSBwYXNzaW5nIHRoZSB1cGRhdGUgYWxv bmcgdG8gYWRkaXRpb25hbCByb3V0ZXJzIGluIGl0cyBnbG9iYWwgKG5ldykgQVNOLiBJbiBpQkdQ LCB0aGUgcm91dGVyIGJlaW5nIG1pZ3JhdGVkIGlzIHJlY2VpdmluZyB1cGRhdGVzICh0aGF0IG1h eSBoYXZlIG9yaWdpbmF0ZWQgZWl0aGVyIGZyb20gZUJHUCBuZWlnaGJvcnMgb3Igb3RoZXIgaUJH UCBuZWlnaGJvcnMpIGZyb20gaXRzIGRvd25zdHJlYW0gbmVpZ2hib3JzIGluIHRoZSBvbGQgQVNO LCBhbmQgTVVTVCBzaWduIHRob3NlIHVwZGF0ZXMgZnJvbSBvbGQgQVNOIHRvIG5ldyB3aXRoIHBD b3VudD0wIGJlZm9yZSBzZW5kaW5nIHRoZW0gb24gdG8gb3RoZXIgcGVlcnMuJm5ic3A7PC9kaXY+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48L286 cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+ V2VzPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyI+PGJyPjwvcD48L2Rpdj48L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4gJmx0O0dlb3JnZSZndDssICJHZW9y Z2UsIFdlcyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tIj53 ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDs8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj4gTW9uZGF5LCBGZWJydWFyeSAyLCAyMDE1IGF0IDE6Mzgg UE08YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+IEFsaWEgQXRs YXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5j b208L2E+Jmd0OywgIjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9u QHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYu b3JnPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9u QHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYu b3JnPC9hPiZndDssICI8YSBocmVmPSJtYWlsdG86c2lkckBpZXRmLm9yZyI+c2lkckBpZXRmLm9y ZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86c2lkckBpZXRmLm9yZyI+c2lkckBpZXRmLm9yZzwv YT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ IFJlOiBBRCByZXZpZXcgYW5kIHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRp b24tMDI8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1UbzogPC9zcGFu PiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbmR5QHRpc2xhYnMuY29tIj5zYW5keUB0aXNsYWJzLmNv bTwvYT4mZ3Q7LCAiR2VvcmdlLCBXZXMiICZsdDs8YSBocmVmPSJtYWlsdG86d2VzbGV5Lmdlb3Jn ZUB0d2NhYmxlLmNvbSI+d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTwvYT4mZ3Q7PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGRpdj48ZGl2PjxkaXY+QWxpYSAmIzgy MTE7IHRoYW5rcyBmb3IgdGhlIHJldmlldy4gQ29uc2lkZXIgdGhpcyBBQ0sgZm9yIGFsbCBjb21t ZW50cyBleGNlcHQgdGhlIG9uZXMgYmVsb3csIGlubGluZSB3aXRoIFdHXTwvZGl2PjxkaXY+SSBo YXZlIGEgJiM4MjExOzAzIGRyYWZ0IGluIHRoZSBlZGl0IGJ1ZmZlciwgYW5kIHdpbGwgcHVibGlz aCBvbmNlIHRoZSBiZWxvdyBpcyByZXNvbHZlZC4mbmJzcDs8L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsiPjxicj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxi cj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBKYW51YXJ5IDMwLCAy MDE1IGF0IDM6NTAgUE08YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+IjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmll dGYub3JnIj5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPC9hPiIg Jmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmll dGYub3JnIj5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPC9hPiZn dDssDQogIjxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYub3JnPC9hPiIg Jmx0OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYub3JnPC9hPiZndDs8 YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5BRCByZXZp ZXcgYW5kIHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb24tMDI8YnI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlJlc2VudC1UbzogPC9zcGFuPiZsdDs8YSBocmVm PSJtYWlsdG86c2FuZHlAdGlzbGFicy5jb20iPnNhbmR5QHRpc2xhYnMuY29tPC9hPiZndDssICJH ZW9yZ2UsIFdlcyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29t Ij53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDs8YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdiBkaXI9Imx0ciI+YSkgTGFuZ3VhZ2UgYXJvdW5kIGRyYWZ0LWlldGYtaWRyLWFzLW1p Z3JhdGlvbiBpcyBtb3JlIHRlbnRhdGl2ZSB0aGFuIGlzIGFwcHJvcHJpYXRlDQo8ZGl2PndoZW4g dGhhdCBkcmFmdCBhbmQgdGhpcyBhcmUgZ29pbmcgdG8gYmUgUkZDcy4mbmJzcDsgUGxlYXNlIGNs ZWFuIHRoYXQgdXAuPC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxkaXY+V0ddIG90 aGVyIHRoYW4gcmVtb3ZpbmcgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQgKGRvbmUp LCBhbmQgZml4aW5nIHRoZSBpbnRybyAocmVtb3ZlZCBkZSBmYWN0byksIHdlcmUgdGhlcmUgb3Ro ZXIgcGxhY2VzIHRoYXQgdGhpcyBuZWVkcyB0byBiZSBhZGRyZXNzZWQ/Jm5ic3A7PC9kaXY+PHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IGRpcj0ibHRyIj48ZGl2Pjxicj48YnI+ DQpiKSBJbiBTZWMgMy4xLCBpdCBzYXlzPGJyPjxicj4NCiJJZiB0aGUgcm91dGUgbm93IHNob3dz IHVwIGFzIG9yaWdpbmF0aW5nPGJyPg0KJm5ic3A7ICZuYnNwO2Zyb20gQVM2NDUwMCwgYW55IGRv d25zdHJlYW0gcGVlcnMnIHZhbGlkYXRpb24gY2hlY2sgd2lsbCBmYWlsIHVubGVzczxicj4NCiZu YnNwOyAmbmJzcDthIFJPQSBpcyAqYWxzbyogYXZhaWxhYmxlIGZvciBBUzY0NTAwIGFzIHRoZSBv cmlnaW4gQVNOLCBtZWFuaW5nIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7dGhlcmUgd2lsbCBiZSBv dmVybGFwcGluZyBST0FzIHVudGlsIGFsbCByb3V0ZXJzIG9yaWdpbmF0aW5nIHByZWZpeGVzPGJy Pg0KJm5ic3A7ICZuYnNwO2Zyb20gQVM2NDUxMCBhcmUgbWlncmF0ZWQgdG8gQVM2NDUwMC4iPGJy Pjxicj4NCkkgdGhpbmsgdGhlIHNlY29uZCBBUzY0NTAwIHNob3VsZCBiZSBBUzY0NTEwLjwvZGl2 PjwvZGl2Pjwvc3Bhbj48ZGl2Pjxicj48L2Rpdj48ZGl2PldHXSBuby4gVGhpcyBpcyBzYXlpbmcg dGhhdCBhIFJPQSBhbHJlYWR5IGV4aXN0cyBmb3IgNjQ1MTAsIGJ1dCBuZWVkcyB0byBleGlzdCBm b3IgNjQ1MDAuIFRoZSBkaXN0aW5jdGlvbiB0aGUgc2Vjb25kIGhhbGYgb2YgdGhhdCBzZWN0aW9u IGlzIG1ha2luZyBpcyB0aGF0IGluIGFkZGl0aW9uIHRvIGdlbmVyYXRpbmcgYSBST0EgZm9yIDY1 NDAwIGZvciBhbnkgcHJlZml4ZXMgb3JpZ2luYXRlZCBieSB0aGUgcm91dGVyIGJlaW5nIG1vdmVk LA0KIGJlY2F1c2Ugb2YgcmVwbGFjZS1BUywgeW91IG1heSBoYXZlIHRvIGdlbmVyYXRlIFJPQXMg Zm9yIDY1NDAwIGZvciByb3V0ZXMgdGhhdCBhcmUgb3JpZ2luYXRpbmcgb24gcm91dGVycyBzdGls bCBpbiA2NTQxMC4gSWYgdGhhdCBleHBsYW5hdGlvbiBpcyBhbnkgY2xlYXJlciwgSSBjYW4gdHJ5 IHRvIGVkaXQgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzLiZuYnNwOzwvZGl2PjxzcGFuIGlkPSJP TEtfU1JDX0JPRFlfU0VDVElPTiI+PGRpdiBkaXI9Imx0ciI+PGRpdj48YnI+PGRpdj48YnI+PC9k aXY+PHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MS4yZW07bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJv dHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTIuNzI3MjcyMDMzNjkxNHB4Ij5l KSBJbiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IHNtYWxsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyI+ ZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uLCB0aGUgY2FzZSBvZiBoYW5kbGluZyBBUyBtaWdy YXRpb24gaW4gaUJHUCBzZXNzaW9ucyBpcyBhbHNvIGNvdmVyZWQuICBJIGFzc3VtZSB0aGF0IGJl Y2F1c2UgaXQgaXMgaUJHUCBzZXNzaW9ucywgdGhlcmUgaXMgbm8gd29yayB0byBiZSBkb25lIGZv ciBCR1BzZWMuICBDb3VsZCB5b3UgcGxlYXNlIGFkZCBhIHF1aWNrIG9idmlvdXMgc3RhdGVtZW50 IHRvIHRoYXQgZWZmZWN0Pzwvc3Bhbj48L3ByZT48L2Rpdj48L2Rpdj48L3NwYW4+PGRpdj48YnI+ PC9kaXY+PGRpdj5XR10gaG1tLiBUaGlzIHNvbHV0aW9uIHdhcyBvcmlnaW5hbGx5IHdyaXR0ZW4g YmVmb3JlIHRoZSBpQkdQIHN0dWZmIHdhcyBhZGRlZCwgYW5kIGl0IGRpZG4ndCBvY2N1ciB0byBt ZSB0aGF0IGl0IG1heSBuZWVkIHRvIGJlIGRpc2N1c3NlZCBoZXJlLiBQaXRmYWxscyBvZiB0d28g bGFyZ2VseSBwYXJhbGxlbCBkb2NzLCBJIGd1ZXNzLiZuYnNwOzwvZGl2PjxkaXY+VGhlIGlCR1Ag QVMgbWlncmF0aW9uIGRpc2N1c3NlZCBpcyBiYXNpY2FsbHkganVzdCBsaXN0ZW5pbmcgZm9yIG9w ZW4gb24gZWl0aGVyIEFTTiwgYnV0IG90aGVyd2lzZSB0cmVhdHMgdGhlIHNlc3Npb24gYXMgaUJH UCBldmVuIGlmIHRoZSBBU04gaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBnbG9iYWxseS1jb25maWd1 cmVkIG9uZS4gVGh1cyB0aGVyZSBhcmUgdHdvIEFTTnMgaW52b2x2ZWQsIGFuZCB0aGlzIGlzIG1h aW5seSB0aGUgc2FtZSBhcw0KIEFTIG1pZ3JhdGlvbiB3aXRoIGVCR1AsIGluIHRoYXQgdGhlIG1p Z3JhdGluZyByb3V0ZXIgd291bGQgbmVlZCB0byBoYXZlIGEgcGNvdW50PTAgZnJvbSBvbGQgQVNO IHRvIE5ldyBpbiBvcmRlciB0byBoaWRlIHRoYXQgcGF0aCBpbiByb3V0ZXMgdGhhdCBhcmUgc2ln bmVkIHRvIHRoZSBvbGQgQVNOIGZyb20gZG93bnN0cmVhbSBlQkdQIHBlZXJzLiBUaGUgd3Jpbmts ZSBpcyB0aGF0IGluc3RlYWQgb2YgdGhlIG1pZ3JhdGlvbiBwb2ludCBiZWluZw0KIG9uIHRoZSBl ZGdlIHJvdXRlciBiZXR3ZWVuIGl0cyBlQkdQIHBlZXJzIGFuZCBpdHMgaUJHUCBwZWVycywgdGhl IG1pZ3JhdGlvbiBwb2ludCBpcyBub3cgb25lIHJvdXRlciB1cHN0cmVhbSwgYmV0d2VlbiB0d28g aUJHUCBwZWVycyAoaS5lLiBUaGUgcm91dGVyIGluIHRoZSBvbGQgQVNOIGRvZXNuJ3QgbmVjZXNz YXJpbHkga25vdyB0byBtYXNrIGl0cyBnbG9iYWwgQVNOIHdpdGggcGNvdW50PTAsIGFuZCBzbyB0 aGUgcm91dGVyIHRoYXQgaXMgYXQNCiB0aGUgYWN0dWFsIGJvcmRlciBiZXR3ZWVuIHRoZSB0d28g QVNOcyB3aWxsIGhhdmUgdG8gZG8gdGhlIHBjb3VudD0wIHRyaWNrIHRvIHRoZSAiaUJHUCIgdXBk YXRlcyBpdCByZWNlaXZlcy4gSSdsbCBuZWVkIHRvIGFkZCBzb21lIHRleHQgaW4gNS4zIHRvIGNv dmVyIHRoaXMgY2FzZS4gR29vZCBjYXRjaC48L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPjxkaXYgZGlyPSJsdHIiPjxkaXY+PHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MS4yZW07 bWFyZ2luLXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNp emU6MTIuNzI3MjcyMDMzNjkxNHB4Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IHNtYWxsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjog cmdiKDM0LCAzNCwgMzQpOyI+PGJyPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSJsaW5lLWhlaWdo dDoxLjJlbTttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDAp O2ZvbnQtc2l6ZToxMi43MjcyNzIwMzM2OTE0cHgiPjxicj48L3ByZT48L2Rpdj48L2Rpdj48L3Nw YW4+PGJyPjxocj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBh dHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVs ZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmlu dG91dC48YnI+PC9mb250PjwvZGl2PjwvZGl2Pjwvc3Bhbj48L2JvZHk+PC9odG1sPg0K --_000_D0F699CD41F96wesleygeorgetwcablecom_-- From nobody Wed Feb 4 11:23:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC61A1EF8; Wed, 4 Feb 2015 11:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk-8hyslsQO0; Wed, 4 Feb 2015 11:23:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C151A3BA1; Wed, 4 Feb 2015 11:23:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150204192306.28372.25256.idtracker@ietfa.amsl.com> Date: Wed, 04 Feb 2015 11:23:06 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:23:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGPSec Considerations for AS Migration Authors : Wesley George Sandy Murphy Filename : draft-ietf-sidr-as-migration-03.txt Pages : 14 Date : 2015-02-04 Abstract: This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-as-migration-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 4 11:24:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517D81A1BE3 for ; Wed, 4 Feb 2015 11:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.226 X-Spam-Level: ** X-Spam-Status: No, score=2.226 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fXH6TGV5-Bl for ; Wed, 4 Feb 2015 11:24:10 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 202311A1EEA for ; Wed, 4 Feb 2015 11:24:05 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.09,519,1418101200"; d="scan'208,217";a="827267448" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Feb 2015 14:15:07 -0500 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 4 Feb 2015 14:24:04 -0500 From: "George, Wes" To: "George, Wes" , Alia Atlas , "draft-ietf-sidr-as-migration@tools.ietf.org" , "sidr@ietf.org" Date: Wed, 4 Feb 2015 14:24:01 -0500 Thread-Topic: AD review and progressing draft-ietf-sidr-as-migration-02 Thread-Index: AdBAsCMcFi+1vzv7QQmWVRgcQBAumw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D0F7DBE5420F0wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:24:15 -0000 --_000_D0F7DBE5420F0wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3ZW50IGFoZWFkIGFuZCBwdXNoZWQgYSByZXZpc2lvbiB0aGF0IGNvdmVycyBBbGlhJ3MgYW5k IEtleXVyJ3MgcmV2aWV3cy4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpGcm9tOiA8R2VvcmdlPiwg Ikdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdl b3JnZUB0d2NhYmxlLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAzLCAyMDE1IGF0IDM6 MzAgUE0NClRvOiBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0Bn bWFpbC5jb20+PiwgImRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+IiA8ZHJh ZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZz4+LCAic2lkckBpZXRmLm9yZzxtYWls dG86c2lkckBpZXRmLm9yZz4iIDxzaWRyQGlldGYub3JnPG1haWx0bzpzaWRyQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBBRCByZXZpZXcgYW5kIHByb2dyZXNzaW5nIGRyYWZ0LWlldGYtc2lkci1h cy1taWdyYXRpb24tMDINClJlc2VudC1UbzogPHNhbmR5QHRpc2xhYnMuY29tPG1haWx0bzpzYW5k eUB0aXNsYWJzLmNvbT4+LCAiR2VvcmdlLCBXZXMiIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29t PG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPj4NCg0KdXBkYXRlOiBJIGFkZGVkIHRo ZSBmb2xsb3dpbmcgdGV4dCBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNS4zIHRvIGNvdmVyIEFsaWEn cyBxdWVzdGlvbiBhYm91dCBpQkdQIEFTIG1pZ3JhdGlvbi4gTGV0IG1lIGtub3cgd2hldGhlciB0 aGlzIGlzIGFjY2VwdGFibGU6DQoNCkFkZGl0aW9uYWxseSwgc2VjdGlvbiA0IG9mIGRyYWZ0LWll dGYtaWRyLWFzLW1pZ3JhdGlvbiBkaXNjdXNzZXMgbWV0aG9kcyBpbiB3aGljaCBBUyBtaWdyYXRp b25zIGNhbiBiZSBjb21wbGV0ZWQgZm9yIGlCR1AgcGVlcnMgc3VjaCB0aGF0IGEgc2Vzc2lvbiBi ZXR3ZWVuIHR3byByb3V0ZXJzIHdpbGwgYmUgdHJlYXRlZCBhcyBpQkdQIGV2ZW4gaWYgdGhlIG5l aWdoYm9yIEFTTiBpcyBub3QgdGhlIHNhbWUgQVNOIG9uIGVhY2ggcGVlcidzIGdsb2JhbCBjb25m aWd1cmF0aW9uLiBBcyBmYXIgYXMgQkdQU2VjIGlzIGNvbmNlcm5lZCwgdGhpcyByZXF1aXJlcyB0 aGUgc2FtZSBwcm9jZWR1cmUgYXMgd2hlbiB0aGUgcm91dGVycyBtaWdyYXRpbmcgYXJlIGFwcGx5 aW5nIEFTIG1pZ3JhdGlvbiBrbm9icyB0byBlQkdQIHBlZXJzLCBidXQgdGhlIHJvdXRlciBmdW5j dGlvbmluZyBhcyB0aGUgIkFTQlIiIGJldHdlZW4gb2xkIGFuZCBuZXcgQVNOIGlzIGRpZmZlcmVu dC4gSW4gZUJHUCwgdGhlIHJvdXRlciBiZWluZyBtaWdyYXRlZCBoYXMgZGlyZWN0IGVCR1Agc2Vz c2lvbnMgdG8gdGhlIG9sZCBBU04gYW5kIHNpZ25zIGZyb20gb2xkIEFTTiB0byBuZXcgd2l0aCBw Q291bnQ9MCBiZWZvcmUgcGFzc2luZyB0aGUgdXBkYXRlIGFsb25nIHRvIGFkZGl0aW9uYWwgcm91 dGVycyBpbiBpdHMgZ2xvYmFsIChuZXcpIEFTTi4gSW4gaUJHUCwgdGhlIHJvdXRlciBiZWluZyBt aWdyYXRlZCBpcyByZWNlaXZpbmcgdXBkYXRlcyAodGhhdCBtYXkgaGF2ZSBvcmlnaW5hdGVkIGVp dGhlciBmcm9tIGVCR1AgbmVpZ2hib3JzIG9yIG90aGVyIGlCR1AgbmVpZ2hib3JzKSBmcm9tIGl0 cyBkb3duc3RyZWFtIG5laWdoYm9ycyBpbiB0aGUgb2xkIEFTTiwgYW5kIE1VU1Qgc2lnbiB0aG9z ZSB1cGRhdGVzIGZyb20gb2xkIEFTTiB0byBuZXcgd2l0aCBwQ291bnQ9MCBiZWZvcmUgc2VuZGlu ZyB0aGVtIG9uIHRvIG90aGVyIHBlZXJzLg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCkZyb206IDxH ZW9yZ2U+LCAiR2VvcmdlLCBXZXMiIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPG1haWx0bzp3 ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPj4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgMiwgMjAx NSBhdCAxOjM4IFBNDQpUbzogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPj4sICJkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3Jn PiIgPGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+PiwgInNpZHJAaWV0Zi5v cmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+IiA8c2lkckBpZXRmLm9yZzxtYWlsdG86c2lkckBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IGFuZCBwcm9ncmVzc2luZyBkcmFmdC1pZXRm LXNpZHItYXMtbWlncmF0aW9uLTAyDQpSZXNlbnQtVG86IDxzYW5keUB0aXNsYWJzLmNvbTxtYWls dG86c2FuZHlAdGlzbGFicy5jb20+PiwgIkdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2Nh YmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4+DQoNCkFsaWEg4oCTIHRo YW5rcyBmb3IgdGhlIHJldmlldy4gQ29uc2lkZXIgdGhpcyBBQ0sgZm9yIGFsbCBjb21tZW50cyBl eGNlcHQgdGhlIG9uZXMgYmVsb3csIGlubGluZSB3aXRoIFdHXQ0KSSBoYXZlIGEg4oCTMDMgZHJh ZnQgaW4gdGhlIGVkaXQgYnVmZmVyLCBhbmQgd2lsbCBwdWJsaXNoIG9uY2UgdGhlIGJlbG93IGlz IHJlc29sdmVkLg0KDQpUaGFua3MsDQoNCldlcw0KDQoNCkZyb206IEFsaWEgQXRsYXMgPGFrYXRs YXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEph bnVhcnkgMzAsIDIwMTUgYXQgMzo1MCBQTQ0KVG86ICJkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0 aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRv b2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+Piwg InNpZHJAaWV0Zi5vcmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+IiA8c2lkckBpZXRmLm9yZzxtYWls dG86c2lkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBBRCByZXZpZXcgYW5kIHByb2dyZXNzaW5nIGRy YWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb24tMDINClJlc2VudC1UbzogPHNhbmR5QHRpc2xhYnMu Y29tPG1haWx0bzpzYW5keUB0aXNsYWJzLmNvbT4+LCAiR2VvcmdlLCBXZXMiIDx3ZXNsZXkuZ2Vv cmdlQHR3Y2FibGUuY29tPG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPj4NCg0KYSkg TGFuZ3VhZ2UgYXJvdW5kIGRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbiBpcyBtb3JlIHRlbnRh dGl2ZSB0aGFuIGlzIGFwcHJvcHJpYXRlDQp3aGVuIHRoYXQgZHJhZnQgYW5kIHRoaXMgYXJlIGdv aW5nIHRvIGJlIFJGQ3MuICBQbGVhc2UgY2xlYW4gdGhhdCB1cC4NCg0KV0ddIG90aGVyIHRoYW4g cmVtb3ZpbmcgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQgKGRvbmUpLCBhbmQgZml4 aW5nIHRoZSBpbnRybyAocmVtb3ZlZCBkZSBmYWN0byksIHdlcmUgdGhlcmUgb3RoZXIgcGxhY2Vz IHRoYXQgdGhpcyBuZWVkcyB0byBiZSBhZGRyZXNzZWQ/DQoNCg0KYikgSW4gU2VjIDMuMSwgaXQg c2F5cw0KDQoiSWYgdGhlIHJvdXRlIG5vdyBzaG93cyB1cCBhcyBvcmlnaW5hdGluZw0KICAgZnJv bSBBUzY0NTAwLCBhbnkgZG93bnN0cmVhbSBwZWVycycgdmFsaWRhdGlvbiBjaGVjayB3aWxsIGZh aWwgdW5sZXNzDQogICBhIFJPQSBpcyAqYWxzbyogYXZhaWxhYmxlIGZvciBBUzY0NTAwIGFzIHRo ZSBvcmlnaW4gQVNOLCBtZWFuaW5nIHRoYXQNCiAgIHRoZXJlIHdpbGwgYmUgb3ZlcmxhcHBpbmcg Uk9BcyB1bnRpbCBhbGwgcm91dGVycyBvcmlnaW5hdGluZyBwcmVmaXhlcw0KICAgZnJvbSBBUzY0 NTEwIGFyZSBtaWdyYXRlZCB0byBBUzY0NTAwLiINCg0KSSB0aGluayB0aGUgc2Vjb25kIEFTNjQ1 MDAgc2hvdWxkIGJlIEFTNjQ1MTAuDQoNCldHXSBuby4gVGhpcyBpcyBzYXlpbmcgdGhhdCBhIFJP QSBhbHJlYWR5IGV4aXN0cyBmb3IgNjQ1MTAsIGJ1dCBuZWVkcyB0byBleGlzdCBmb3IgNjQ1MDAu IFRoZSBkaXN0aW5jdGlvbiB0aGUgc2Vjb25kIGhhbGYgb2YgdGhhdCBzZWN0aW9uIGlzIG1ha2lu ZyBpcyB0aGF0IGluIGFkZGl0aW9uIHRvIGdlbmVyYXRpbmcgYSBST0EgZm9yIDY1NDAwIGZvciBh bnkgcHJlZml4ZXMgb3JpZ2luYXRlZCBieSB0aGUgcm91dGVyIGJlaW5nIG1vdmVkLCBiZWNhdXNl IG9mIHJlcGxhY2UtQVMsIHlvdSBtYXkgaGF2ZSB0byBnZW5lcmF0ZSBST0FzIGZvciA2NTQwMCBm b3Igcm91dGVzIHRoYXQgYXJlIG9yaWdpbmF0aW5nIG9uIHJvdXRlcnMgc3RpbGwgaW4gNjU0MTAu IElmIHRoYXQgZXhwbGFuYXRpb24gaXMgYW55IGNsZWFyZXIsIEkgY2FuIHRyeSB0byBlZGl0IHRo ZSB0ZXh0IHRvIHJlZmxlY3QgdGhpcy4NCg0KDQoNCmUpIEluIGRyYWZ0LWlldGYtaWRyLWFzLW1p Z3JhdGlvbiwgdGhlIGNhc2Ugb2YgaGFuZGxpbmcgQVMgbWlncmF0aW9uIGluIGlCR1Agc2Vzc2lv bnMgaXMgYWxzbyBjb3ZlcmVkLiAgSSBhc3N1bWUgdGhhdCBiZWNhdXNlIGl0IGlzIGlCR1Agc2Vz c2lvbnMsIHRoZXJlIGlzIG5vIHdvcmsgdG8gYmUgZG9uZSBmb3IgQkdQc2VjLiAgQ291bGQgeW91 IHBsZWFzZSBhZGQgYSBxdWljayBvYnZpb3VzIHN0YXRlbWVudCB0byB0aGF0IGVmZmVjdD8NCg0K V0ddIGhtbS4gVGhpcyBzb2x1dGlvbiB3YXMgb3JpZ2luYWxseSB3cml0dGVuIGJlZm9yZSB0aGUg aUJHUCBzdHVmZiB3YXMgYWRkZWQsIGFuZCBpdCBkaWRuJ3Qgb2NjdXIgdG8gbWUgdGhhdCBpdCBt YXkgbmVlZCB0byBiZSBkaXNjdXNzZWQgaGVyZS4gUGl0ZmFsbHMgb2YgdHdvIGxhcmdlbHkgcGFy YWxsZWwgZG9jcywgSSBndWVzcy4NClRoZSBpQkdQIEFTIG1pZ3JhdGlvbiBkaXNjdXNzZWQgaXMg YmFzaWNhbGx5IGp1c3QgbGlzdGVuaW5nIGZvciBvcGVuIG9uIGVpdGhlciBBU04sIGJ1dCBvdGhl cndpc2UgdHJlYXRzIHRoZSBzZXNzaW9uIGFzIGlCR1AgZXZlbiBpZiB0aGUgQVNOIGlzIG5vdCB0 aGUgc2FtZSBhcyB0aGUgZ2xvYmFsbHktY29uZmlndXJlZCBvbmUuIFRodXMgdGhlcmUgYXJlIHR3 byBBU05zIGludm9sdmVkLCBhbmQgdGhpcyBpcyBtYWlubHkgdGhlIHNhbWUgYXMgQVMgbWlncmF0 aW9uIHdpdGggZUJHUCwgaW4gdGhhdCB0aGUgbWlncmF0aW5nIHJvdXRlciB3b3VsZCBuZWVkIHRv IGhhdmUgYSBwY291bnQ9MCBmcm9tIG9sZCBBU04gdG8gTmV3IGluIG9yZGVyIHRvIGhpZGUgdGhh dCBwYXRoIGluIHJvdXRlcyB0aGF0IGFyZSBzaWduZWQgdG8gdGhlIG9sZCBBU04gZnJvbSBkb3du c3RyZWFtIGVCR1AgcGVlcnMuIFRoZSB3cmlua2xlIGlzIHRoYXQgaW5zdGVhZCBvZiB0aGUgbWln cmF0aW9uIHBvaW50IGJlaW5nIG9uIHRoZSBlZGdlIHJvdXRlciBiZXR3ZWVuIGl0cyBlQkdQIHBl ZXJzIGFuZCBpdHMgaUJHUCBwZWVycywgdGhlIG1pZ3JhdGlvbiBwb2ludCBpcyBub3cgb25lIHJv dXRlciB1cHN0cmVhbSwgYmV0d2VlbiB0d28gaUJHUCBwZWVycyAoaS5lLiBUaGUgcm91dGVyIGlu IHRoZSBvbGQgQVNOIGRvZXNuJ3QgbmVjZXNzYXJpbHkga25vdyB0byBtYXNrIGl0cyBnbG9iYWwg QVNOIHdpdGggcGNvdW50PTAsIGFuZCBzbyB0aGUgcm91dGVyIHRoYXQgaXMgYXQgdGhlIGFjdHVh bCBib3JkZXIgYmV0d2VlbiB0aGUgdHdvIEFTTnMgd2lsbCBoYXZlIHRvIGRvIHRoZSBwY291bnQ9 MCB0cmljayB0byB0aGUgImlCR1AiIHVwZGF0ZXMgaXQgcmVjZWl2ZXMuIEknbGwgbmVlZCB0byBh ZGQgc29tZSB0ZXh0IGluIDUuMyB0byBjb3ZlciB0aGlzIGNhc2UuIEdvb2QgY2F0Y2guDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRh cnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3Vi amVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUt bWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFr ZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlz IEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_D0F7DBE5420F0wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxkaXY+PGRpdj48ZGl2Pkkgd2VudCBhaGVhZCBhbmQgcHVz aGVkIGEgcmV2aXNpb24gdGhhdCBjb3ZlcnMgQWxpYSdzIGFuZCBLZXl1cidzIHJldmlld3MuJm5i c3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48 L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyI+V2VzPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PGJyPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4gJmx0O0dlb3JnZSZn dDssICJHZW9yZ2UsIFdlcyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2Fi bGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDs8YnI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj4gVHVlc2RheSwgRmVicnVhcnkgMywgMjAx NSBhdCAzOjMwIFBNPGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFu PiBBbGlhIEF0bGFzICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRs YXNAZ21haWwuY29tPC9hPiZndDssICI8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zaWRyLWFz LW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0 b29scy5pZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zaWRyLWFz LW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0 b29scy5pZXRmLm9yZzwvYT4mZ3Q7LCAiPGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNp ZHJAaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJA aWV0Zi5vcmc8L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPiBSZTogQUQgcmV2aWV3IGFuZCBwcm9ncmVzc2luZyBkcmFmdC1pZXRmLXNpZHIt YXMtbWlncmF0aW9uLTAyPGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQt VG86IDwvc3Bhbj4gJmx0OzxhIGhyZWY9Im1haWx0bzpzYW5keUB0aXNsYWJzLmNvbSI+c2FuZHlA dGlzbGFicy5jb208L2E+Jmd0OywgIkdlb3JnZSwgV2VzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndl c2xleS5nZW9yZ2VAdHdjYWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0 Ozxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGRpdj48ZGl2PnVwZGF0ZTogSSBhZGRl ZCB0aGUgZm9sbG93aW5nIHRleHQgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDUuMyB0byBjb3ZlciBB bGlhJ3MgcXVlc3Rpb24gYWJvdXQgaUJHUCBBUyBtaWdyYXRpb24uIExldCBtZSBrbm93IHdoZXRo ZXIgdGhpcyBpcyBhY2NlcHRhYmxlOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdj5BZGRp dGlvbmFsbHksIHNlY3Rpb24gNCBvZiBkcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24gZGlzY3Vz c2VzIG1ldGhvZHMgaW4gd2hpY2ggQVMgbWlncmF0aW9ucyBjYW4gYmUgY29tcGxldGVkIGZvciBp QkdQIHBlZXJzIHN1Y2ggdGhhdCBhIHNlc3Npb24gYmV0d2VlbiB0d28gcm91dGVycyB3aWxsIGJl IHRyZWF0ZWQgYXMgaUJHUCBldmVuIGlmIHRoZSBuZWlnaGJvciBBU04gaXMgbm90IHRoZSBzYW1l IEFTTiBvbiBlYWNoIHBlZXIncyBnbG9iYWwgY29uZmlndXJhdGlvbi4gQXMgZmFyIGFzIEJHUFNl YyBpcyBjb25jZXJuZWQsIHRoaXMgcmVxdWlyZXMgdGhlIHNhbWUgcHJvY2VkdXJlIGFzIHdoZW4g dGhlIHJvdXRlcnMgbWlncmF0aW5nIGFyZSBhcHBseWluZyBBUyBtaWdyYXRpb24ga25vYnMgdG8g ZUJHUCBwZWVycywgYnV0IHRoZSByb3V0ZXIgZnVuY3Rpb25pbmcgYXMgdGhlICJBU0JSIiBiZXR3 ZWVuIG9sZCBhbmQgbmV3IEFTTiBpcyBkaWZmZXJlbnQuIEluIGVCR1AsIHRoZSByb3V0ZXIgYmVp bmcgbWlncmF0ZWQgaGFzIGRpcmVjdCBlQkdQIHNlc3Npb25zIHRvIHRoZSBvbGQgQVNOIGFuZCBz aWducyBmcm9tIG9sZCBBU04gdG8gbmV3IHdpdGggcENvdW50PTAgYmVmb3JlIHBhc3NpbmcgdGhl IHVwZGF0ZSBhbG9uZyB0byBhZGRpdGlvbmFsIHJvdXRlcnMgaW4gaXRzIGdsb2JhbCAobmV3KSBB U04uIEluIGlCR1AsIHRoZSByb3V0ZXIgYmVpbmcgbWlncmF0ZWQgaXMgcmVjZWl2aW5nIHVwZGF0 ZXMgKHRoYXQgbWF5IGhhdmUgb3JpZ2luYXRlZCBlaXRoZXIgZnJvbSBlQkdQIG5laWdoYm9ycyBv ciBvdGhlciBpQkdQIG5laWdoYm9ycykgZnJvbSBpdHMgZG93bnN0cmVhbSBuZWlnaGJvcnMgaW4g dGhlIG9sZCBBU04sIGFuZCBNVVNUIHNpZ24gdGhvc2UgdXBkYXRlcyBmcm9tIG9sZCBBU04gdG8g bmV3IHdpdGggcENvdW50PTAgYmVmb3JlIHNlbmRpbmcgdGhlbSBvbiB0byBvdGhlciBwZWVycy4m bmJzcDs8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7Ij5XZXM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7Ij48YnI+PC9wPjwvZGl2PjwvZGl2PjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1z aXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47 IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0 ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0 Ij48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiAmbHQ7R2Vvcmdl Jmd0OywgIkdlb3JnZSwgV2VzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xleS5nZW9yZ2VAdHdj YWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPiBNb25kYXksIEZlYnJ1YXJ5IDIsIDIw MTUgYXQgMTozOCBQTTxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4gQWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0 bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7LCAiPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1h cy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25A dG9vbHMuaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1h cy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25A dG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OywgIjxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5z aWRyQGlldGYub3JnPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRy QGlldGYub3JnPC9hPiZndDs8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj4gUmU6IEFEIHJldmlldyBhbmQgcHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi1zaWRy LWFzLW1pZ3JhdGlvbi0wMjxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVzZW50 LVRvOiA8L3NwYW4+ICZsdDs8YSBocmVmPSJtYWlsdG86c2FuZHlAdGlzbGFicy5jb20iPnNhbmR5 QHRpc2xhYnMuY29tPC9hPiZndDssICJHZW9yZ2UsIFdlcyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3 ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZn dDs8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48ZGl2PjxkaXY+PGRp dj5BbGlhICYjODIxMTsgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiBDb25zaWRlciB0aGlzIEFDSyBm b3IgYWxsIGNvbW1lbnRzIGV4Y2VwdCB0aGUgb25lcyBiZWxvdywgaW5saW5lIHdpdGggV0ddPC9k aXY+PGRpdj5JIGhhdmUgYSAmIzgyMTE7MDMgZHJhZnQgaW4gdGhlIGVkaXQgYnVmZmVyLCBhbmQg d2lsbCBwdWJsaXNoIG9uY2UgdGhlIGJlbG93IGlzIHJlc29sdmVkLiZuYnNwOzwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PGJyPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5UaGFua3MsPG86cD48L286cD48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+V2Vz PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyI+PGJyPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbGlhIEF0bGFzICZsdDs8YSBo cmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8 YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEph bnVhcnkgMzAsIDIwMTUgYXQgMzo1MCBQTTxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj4iPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRp b25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0 Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRp b25AdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0OywNCiAiPGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0 Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0Zi5v cmc8L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9z cGFuPkFEIHJldmlldyBhbmQgcHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlv bi0wMjxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVzZW50LVRvOiA8L3NwYW4+ Jmx0OzxhIGhyZWY9Im1haWx0bzpzYW5keUB0aXNsYWJzLmNvbSI+c2FuZHlAdGlzbGFicy5jb208 L2E+Jmd0OywgIkdlb3JnZSwgV2VzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xleS5nZW9yZ2VA dHdjYWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj5hKSBMYW5ndWFnZSBhcm91bmQgZHJhZnQtaWV0 Zi1pZHItYXMtbWlncmF0aW9uIGlzIG1vcmUgdGVudGF0aXZlIHRoYW4gaXMgYXBwcm9wcmlhdGUN CjxkaXY+d2hlbiB0aGF0IGRyYWZ0IGFuZCB0aGlzIGFyZSBnb2luZyB0byBiZSBSRkNzLiZuYnNw OyBQbGVhc2UgY2xlYW4gdGhhdCB1cC48L2Rpdj48L2Rpdj48L3NwYW4+PGRpdj48YnI+PC9kaXY+ PGRpdj5XR10gb3RoZXIgdGhhbiByZW1vdmluZyB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rp b24gNCAoZG9uZSksIGFuZCBmaXhpbmcgdGhlIGludHJvIChyZW1vdmVkIGRlIGZhY3RvKSwgd2Vy ZSB0aGVyZSBvdGhlciBwbGFjZXMgdGhhdCB0aGlzIG5lZWRzIHRvIGJlIGFkZHJlc3NlZD8mbmJz cDs8L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxkaXYgZGlyPSJsdHIiPjxk aXY+PGJyPjxicj4NCmIpIEluIFNlYyAzLjEsIGl0IHNheXM8YnI+PGJyPg0KIklmIHRoZSByb3V0 ZSBub3cgc2hvd3MgdXAgYXMgb3JpZ2luYXRpbmc8YnI+DQombmJzcDsgJm5ic3A7ZnJvbSBBUzY0 NTAwLCBhbnkgZG93bnN0cmVhbSBwZWVycycgdmFsaWRhdGlvbiBjaGVjayB3aWxsIGZhaWwgdW5s ZXNzPGJyPg0KJm5ic3A7ICZuYnNwO2EgUk9BIGlzICphbHNvKiBhdmFpbGFibGUgZm9yIEFTNjQ1 MDAgYXMgdGhlIG9yaWdpbiBBU04sIG1lYW5pbmcgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDt0aGVy ZSB3aWxsIGJlIG92ZXJsYXBwaW5nIFJPQXMgdW50aWwgYWxsIHJvdXRlcnMgb3JpZ2luYXRpbmcg cHJlZml4ZXM8YnI+DQombmJzcDsgJm5ic3A7ZnJvbSBBUzY0NTEwIGFyZSBtaWdyYXRlZCB0byBB UzY0NTAwLiI8YnI+PGJyPg0KSSB0aGluayB0aGUgc2Vjb25kIEFTNjQ1MDAgc2hvdWxkIGJlIEFT NjQ1MTAuPC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxkaXY+V0ddIG5vLiBUaGlz IGlzIHNheWluZyB0aGF0IGEgUk9BIGFscmVhZHkgZXhpc3RzIGZvciA2NDUxMCwgYnV0IG5lZWRz IHRvIGV4aXN0IGZvciA2NDUwMC4gVGhlIGRpc3RpbmN0aW9uIHRoZSBzZWNvbmQgaGFsZiBvZiB0 aGF0IHNlY3Rpb24gaXMgbWFraW5nIGlzIHRoYXQgaW4gYWRkaXRpb24gdG8gZ2VuZXJhdGluZyBh IFJPQSBmb3IgNjU0MDAgZm9yIGFueSBwcmVmaXhlcyBvcmlnaW5hdGVkIGJ5IHRoZSByb3V0ZXIg YmVpbmcgbW92ZWQsDQogYmVjYXVzZSBvZiByZXBsYWNlLUFTLCB5b3UgbWF5IGhhdmUgdG8gZ2Vu ZXJhdGUgUk9BcyBmb3IgNjU0MDAgZm9yIHJvdXRlcyB0aGF0IGFyZSBvcmlnaW5hdGluZyBvbiBy b3V0ZXJzIHN0aWxsIGluIDY1NDEwLiBJZiB0aGF0IGV4cGxhbmF0aW9uIGlzIGFueSBjbGVhcmVy LCBJIGNhbiB0cnkgdG8gZWRpdCB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMuJm5ic3A7PC9kaXY+ PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IGRpcj0ibHRyIj48ZGl2Pjxicj48 ZGl2Pjxicj48L2Rpdj48cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxLjJlbTttYXJnaW4tdG9wOjBw eDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMi43MjcyNzIw MzM2OTE0cHgiPmUpIEluIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogc21hbGw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoMzQs IDM0LCAzNCk7Ij5kcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24sIHRoZSBjYXNlIG9mIGhhbmRs aW5nIEFTIG1pZ3JhdGlvbiBpbiBpQkdQIHNlc3Npb25zIGlzIGFsc28gY292ZXJlZC4gIEkgYXNz dW1lIHRoYXQgYmVjYXVzZSBpdCBpcyBpQkdQIHNlc3Npb25zLCB0aGVyZSBpcyBubyB3b3JrIHRv IGJlIGRvbmUgZm9yIEJHUHNlYy4gIENvdWxkIHlvdSBwbGVhc2UgYWRkIGEgcXVpY2sgb2J2aW91 cyBzdGF0ZW1lbnQgdG8gdGhhdCBlZmZlY3Q/PC9zcGFuPjwvcHJlPjwvZGl2PjwvZGl2Pjwvc3Bh bj48ZGl2Pjxicj48L2Rpdj48ZGl2PldHXSBobW0uIFRoaXMgc29sdXRpb24gd2FzIG9yaWdpbmFs bHkgd3JpdHRlbiBiZWZvcmUgdGhlIGlCR1Agc3R1ZmYgd2FzIGFkZGVkLCBhbmQgaXQgZGlkbid0 IG9jY3VyIHRvIG1lIHRoYXQgaXQgbWF5IG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGhlcmUuIFBpdGZh bGxzIG9mIHR3byBsYXJnZWx5IHBhcmFsbGVsIGRvY3MsIEkgZ3Vlc3MuJm5ic3A7PC9kaXY+PGRp dj5UaGUgaUJHUCBBUyBtaWdyYXRpb24gZGlzY3Vzc2VkIGlzIGJhc2ljYWxseSBqdXN0IGxpc3Rl bmluZyBmb3Igb3BlbiBvbiBlaXRoZXIgQVNOLCBidXQgb3RoZXJ3aXNlIHRyZWF0cyB0aGUgc2Vz c2lvbiBhcyBpQkdQIGV2ZW4gaWYgdGhlIEFTTiBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIGdsb2Jh bGx5LWNvbmZpZ3VyZWQgb25lLiBUaHVzIHRoZXJlIGFyZSB0d28gQVNOcyBpbnZvbHZlZCwgYW5k IHRoaXMgaXMgbWFpbmx5IHRoZSBzYW1lIGFzDQogQVMgbWlncmF0aW9uIHdpdGggZUJHUCwgaW4g dGhhdCB0aGUgbWlncmF0aW5nIHJvdXRlciB3b3VsZCBuZWVkIHRvIGhhdmUgYSBwY291bnQ9MCBm cm9tIG9sZCBBU04gdG8gTmV3IGluIG9yZGVyIHRvIGhpZGUgdGhhdCBwYXRoIGluIHJvdXRlcyB0 aGF0IGFyZSBzaWduZWQgdG8gdGhlIG9sZCBBU04gZnJvbSBkb3duc3RyZWFtIGVCR1AgcGVlcnMu IFRoZSB3cmlua2xlIGlzIHRoYXQgaW5zdGVhZCBvZiB0aGUgbWlncmF0aW9uIHBvaW50IGJlaW5n DQogb24gdGhlIGVkZ2Ugcm91dGVyIGJldHdlZW4gaXRzIGVCR1AgcGVlcnMgYW5kIGl0cyBpQkdQ IHBlZXJzLCB0aGUgbWlncmF0aW9uIHBvaW50IGlzIG5vdyBvbmUgcm91dGVyIHVwc3RyZWFtLCBi ZXR3ZWVuIHR3byBpQkdQIHBlZXJzIChpLmUuIFRoZSByb3V0ZXIgaW4gdGhlIG9sZCBBU04gZG9l c24ndCBuZWNlc3NhcmlseSBrbm93IHRvIG1hc2sgaXRzIGdsb2JhbCBBU04gd2l0aCBwY291bnQ9 MCwgYW5kIHNvIHRoZSByb3V0ZXIgdGhhdCBpcyBhdA0KIHRoZSBhY3R1YWwgYm9yZGVyIGJldHdl ZW4gdGhlIHR3byBBU05zIHdpbGwgaGF2ZSB0byBkbyB0aGUgcGNvdW50PTAgdHJpY2sgdG8gdGhl ICJpQkdQIiB1cGRhdGVzIGl0IHJlY2VpdmVzLiBJJ2xsIG5lZWQgdG8gYWRkIHNvbWUgdGV4dCBp biA1LjMgdG8gY292ZXIgdGhpcyBjYXNlLiBHb29kIGNhdGNoLjwvZGl2PjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+PGRpdiBkaXI9Imx0ciI+PGRpdj48cHJlIHN0eWxlPSJsaW5lLWhl aWdodDoxLjJlbTttYXJnaW4tdG9wOjBweDttYXJnaW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCww LDApO2ZvbnQtc2l6ZToxMi43MjcyNzIwMzM2OTE0cHgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogYXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogc21hbGw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij48YnI+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEuMmVtO21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9y OnJnYigwLDAsMCk7Zm9udC1zaXplOjEyLjcyNzI3MjAzMzY5MTRweCI+PGJyPjwvcHJlPjwvZGl2 PjwvZGl2Pjwvc3Bhbj48YnI+PGhyPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6 ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCiBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt YW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBh bmQgYW55IHByaW50b3V0Ljxicj48L2ZvbnQ+PC9kaXY+PC9kaXY+PC9zcGFuPjwvZGl2PjwvZGl2 Pjwvc3Bhbj48L2JvZHk+PC9odG1sPg0K --_000_D0F7DBE5420F0wesleygeorgetwcablecom_-- From nobody Thu Feb 5 14:38:49 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB851A8757 for ; Thu, 5 Feb 2015 14:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6YqZ5yme96C for ; Thu, 5 Feb 2015 14:38:37 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902401A6F0E for ; Thu, 5 Feb 2015 14:38:37 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id D5A8428B0017 for ; Thu, 5 Feb 2015 17:38:36 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BD0251F8051; Thu, 5 Feb 2015 17:38:36 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_F8919675-148B-41A4-AA01-F7A1E403CEE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Thu, 5 Feb 2015 17:38:39 -0500 References: To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] Fwd: wg adoption call for draft-tbruijnzeels-sidr-delta-protocol-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 22:38:42 -0000 --Apple-Mail=_F8919675-148B-41A4-AA01-F7A1E403CEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There has been sufficient support for adopting this work as a working = group draft. The authors should re-submit the draft as a working group draft. --Sandy, speaking for the wg co-chairs Begin forwarded message: > From: Sandra Murphy > Subject: wg adoption call for = draft-tbruijnzeels-sidr-delta-protocol-03 > Date: January 14, 2015 3:38:37 PM EST > To: sidr wg list > Cc: Sandra Murphy >=20 > The authors of draft-tbruijnzeels-sidr-delta-protocol-03 have = requested working group adoption. >=20 > A working group adoption call starts now and will end 14 days from now = on 28 January. >=20 > Please respond to say whether you support adoption of this work as a = working group work item AND whether you will participate in the = discussion. >=20 > Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >=20 > --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_F8919675-148B-41A4-AA01-F7A1E403CEE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU0/DvAAoJEHplpQeet0IZjBIQAKdz9lHenk9ZvEgVZjsdgHxY RBLH3ddTkMcaRTFE+PxTgNEXiUKJra3xTedyX1JlnInuX8/uBxJBNB9hqFQ1D3+5 IGF/O2fCu1kEtH9xcSC8E7nm1Shey9KPRsEuinXZZqmMpz8BkbRmmNGpXeAKWSkB orMYL+ojAshLFfv5VNN+fUvocYf6b67kS4zRDS6PwXtu/IYksZKvrfNLW+9REUyr MMrUv1xI/G2FikH5oLfaX5MUc+VXpTEz7WtlmPDK/6O52N7pHtIWu8FmWkhUyHHZ DSQ/rY5THzZbNWlnujbwjQp1lJFoxTXZBJXksoUvKHESZj4IllvBKNERnaLUgLNy tH2zlyBkVEgd/gLYvH3nq9H9/xil2DuYGlbn/nhrfoa8y3jzeGLG/EIbiVz2eklh u8ABdjCTnwxAgeO9MYq6S0a/Tv5cPpkTbWMdwbKrqg7tP4oqKaTEBv5uCOAJ5GYm r4n3LvNuUFlPPkdnuwifXed/caRItq8cSlkA8MpDDjGvEAA3mqWkQQvDM2a31Sy3 OEXEUTWpzr8qhma3aOZI1TIxDzQax7gAXjfZfzE0k7VuQ1zEPEzWv7nMYAXA2G/9 8MkF1/W54GaGAJeOHd6V8QJXWlcRHKbgFJggc68oWyI5pQjIfAg9pzPziTmjCSpR O9l4iO/fJUbf86W3S+S3 =Qns1 -----END PGP SIGNATURE----- --Apple-Mail=_F8919675-148B-41A4-AA01-F7A1E403CEE2-- From nobody Thu Feb 5 20:38:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3691A036D for ; Thu, 5 Feb 2015 20:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyxx7UabgngZ for ; Thu, 5 Feb 2015 20:38:19 -0800 (PST) Received: from nm9-vm1.access.bullet.mail.bf1.yahoo.com (nm9-vm1.access.bullet.mail.bf1.yahoo.com [216.109.114.192]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C721A0089 for ; Thu, 5 Feb 2015 20:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423197498; bh=8iymQPon8c98MLs9bzx8iIvnCEy24R/g9GUTILG9B9E=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=kPjy3YHAopr0ZfXd0Q2RRNM+GB8oxJZKDxahbxCoo55SyIgB8gfxiRAK842l1SG/X8IPE7QNo81ogcnu8357maOETDGDzJHryH9O2HeZF3D3iFIPuIgf+hUL2L1Q7HIR5eF0fbBNrjiGGvqx2Gqd4eYOdZUOc+PUODdKkcQOhqVLaiA2/1Wrq0i9/cb+ol0E44Bmt5SZw2XKv4piH7ndCmkcbf7HolAq74f9+o/ZtgpssQO6pcieM2VtYPn8dvwOkQ8yY6GbHFvBGwA+CA2lv3KiOvbzIvfnxoUwtIi47osSfY09m427ygIUtNN7AOEZwsmWNz3j4myxQZt+ngRPUA== Received: from [66.196.81.155] by nm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2015 04:38:18 -0000 Received: from [98.138.104.97] by tm1.access.bullet.mail.bf1.yahoo.com with NNFMP; 06 Feb 2015 04:38:18 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 06 Feb 2015 04:38:18 -0000 X-Yahoo-Newman-Id: 438416.97141.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: N39MD8sVM1mTIJj_a94X0NXO2S.RG1zZoF.LbgGSVWsSZ4o SytWW99cvsTpho9dAd1svyGA7JMUQ2ql_94NhIScdOqGPzwxVIJFqE.Uowuc K1OWIjSM4r_cHGCCOVfU82RGNMAkXn.oBHLXoKTBG8KLhDixR.1ifIuMFVDY p8P4bYYBPxMikV.kyztq1hFyo_6zO6NcxjY3OZe2pUiYbOKEIYzy0U8NHO5K SRuqgIqD6yaVlIYaexVEFL_nclVZ_QiBActbZeRKNYwxFJJYennMQhbTcpul ro2Cex9qv57uYGqugeuerEQ._d9MQDbUD35azvXQF2GgIGvVlgZSAgtTQKym VRl2HYAZyT6r15aRN.nVK_roRPGsHLpe8SfXcap9dC7XlUqxpHC7sY_Jjexv JGN1uErE3ATLxzoLA1.03Y51aEtep_6K4x0RZHxSZZYtLn6imhRh83CMzQsR 8O_oPDWo_7NeNc_sOGDK5V9uehtq0zysXrXRb3Km.qG.5ZOORg2ywdOPQY0J vE8fBgzE2.i5ziql6mkpcSxw.psU_PwGOKEGL_g6SKxlGkEzsd7XXV.sGQ3L lL2R8KHxHxUoWM9x4I3FM0hE0ksuJ1zNKwO_r9ovp2KmPUuhc8Q-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 0C5801C604A for ; Thu, 5 Feb 2015 23:38:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Feb 2015 23:38:16 -0500 From: David Mandelberg To: In-Reply-To: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> Message-ID: <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 04:38:25 -0000 After reviewing this document, I have one concern below, and some nits that I'll send to the editor. Otherwise it looks good to me. In sections 4.1 and 4.2, there are two different to-be-signed structures. If I understand correctly, the same router keys will be used to sign data from both structures. It might be possible for an attacker to take a valid signature of data from the structure in 4.2, and present it as a valid signature of the same bytes interpreted with the structure in 4.1. I'm not sure anything malicious could be done this way, but reinterpreting the meaning of signed data seems like a bad idea to me. It would be easy to prevent this by prepending both structures with a single byte that MUST BE 0 for 4.1 and MUST BE 1 for 4.2. Apologies if this has already been discussed and is not an issue. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Fri Feb 6 06:08:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7F31A1AB2 for ; Fri, 6 Feb 2015 06:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZLN__hhKPhq for ; Fri, 6 Feb 2015 06:08:20 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21061A001B for ; Fri, 6 Feb 2015 06:08:20 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YJjZu-0004aC-I7; Fri, 06 Feb 2015 15:08:16 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::b5]) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1YJjZn-0005L9-Ob; Fri, 06 Feb 2015 15:08:14 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Fri, 6 Feb 2015 15:07:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01086F8F-5F08-4C4A-8E30-7CE79614686A@ripe.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b57e70b189b0ed93bcf37f463080a128 Archived-At: Cc: sidr wg list Subject: Re: [sidr] wg adoption call for draft-tbruijnzeels-sidr-delta-protocol-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:08:23 -0000 Hi, Thank you. I am about to leave on a one-week break though, so unless one = of the co-authors wants to take care of this, I prefer to do this when I = am back (16 feb) - that way I am also around for follow-up discussion. Thanks Tim On 05 Feb 2015, at 23:38, Sandra Murphy wrote: > There has been sufficient support for adopting this work as a working = group draft. >=20 > The authors should re-submit the draft as a working group draft. >=20 > --Sandy, speaking for the wg co-chairs >=20 > Begin forwarded message: >=20 >> From: Sandra Murphy >> Subject: wg adoption call for = draft-tbruijnzeels-sidr-delta-protocol-03 >> Date: January 14, 2015 3:38:37 PM EST >> To: sidr wg list >> Cc: Sandra Murphy >>=20 >> The authors of draft-tbruijnzeels-sidr-delta-protocol-03 have = requested working group adoption. >>=20 >> A working group adoption call starts now and will end 14 days from = now on 28 January. >>=20 >> Please respond to say whether you support adoption of this work as a = working group work item AND whether you will participate in the = discussion. >>=20 >> Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >>=20 >> --Sandy, speaking as one of the wg co-chairs >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Feb 6 08:15:57 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F171A6D3F for ; Fri, 6 Feb 2015 08:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni_XQtyHJPMW for ; Fri, 6 Feb 2015 08:15:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA661A1F1D for ; Fri, 6 Feb 2015 08:15:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YJlZN-0006Vw-Gn; Fri, 06 Feb 2015 16:15:49 +0000 Date: Fri, 06 Feb 2015 17:15:48 +0100 Message-ID: From: Randy Bush To: Wes George In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:15:53 -0000 has the wg really looked at 5.2 and 5.3 with respect to how the ibgp hacks affect the bgpsec spec? randy From nobody Sat Feb 7 06:35:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7FB1A87A0 for ; Sat, 7 Feb 2015 06:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5k5iz4PRcAo for ; Sat, 7 Feb 2015 06:35:21 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A91961A8735 for ; Sat, 7 Feb 2015 06:35:21 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.09,535,1418101200"; d="scan'208";a="828346931" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Feb 2015 09:26:08 -0500 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Sat, 7 Feb 2015 09:35:18 -0500 From: "George, Wes" To: Randy Bush Date: Sat, 7 Feb 2015 09:34:17 -0500 Thread-Topic: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 Thread-Index: AdBC40lt0Uo6K1swTYaFbY9hintnQA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: sidr wg list Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 14:35:24 -0000 SSBwb3NlZCBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGlzIGluIG15IFdHTEMgcmV2aWV3IG9mIGJn cHNlYyBzcGVjLCBidXQNCmhhdmVuJ3QgaGVhcmQgYW55dGhpbmcgYmFjay4gQ3VycmVudCBzY2hl ZHVsZSBoYXMgdGhpcyBiZWluZyBldmFsdWF0ZWQgYnkNCklFU0cgcHJpb3IgdG8gb3VyIG5leHQg bWVldGluZy4gSWYgd2UgbmVlZCB0byBkaXNjdXNzIGR1cmluZyB0aGUgbWVldGluZw0KaW4gRGFs bGFzLCB3ZSBjb3VsZCBjZXJ0YWlubHkgZGVsYXkgcHJvY2Vzc2luZyBvZiB0aGUgZG9jdW1lbnQu IEl0IGhhcyBhDQpub3JtYXRpdmUgYmxvY2sgb24gdGhlIGJncHNlYyBzcGVjLCBzbyBpdCdzIG5v dCBsaWtlIGl0J3MgZ2V0dGluZw0KcHVibGlzaGVkIHJpZ2h0IGF3YXkgYW55d2F5Lg0KDQpUaGFu a3MsDQoNCldlcw0KDQoNCg0KT24gMi82LzE1LCAxMToxNSBBTSwgIlJhbmR5IEJ1c2giIDxyYW5k eUBwc2cuY29tPiB3cm90ZToNCg0KPmhhcyB0aGUgd2cgcmVhbGx5IGxvb2tlZCBhdCA1LjIgYW5k IDUuMyB3aXRoIHJlc3BlY3QgdG8gaG93IHRoZSBpYmdwDQo+aGFja3MgYWZmZWN0IHRoZSBiZ3Bz ZWMgc3BlYz8NCj4NCj5yYW5keQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29w eXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Sat Feb 7 10:03:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C99F1A1DE1 for ; Sat, 7 Feb 2015 10:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbr8JQvo3yTQ for ; Sat, 7 Feb 2015 10:03:05 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7431A1B5F for ; Sat, 7 Feb 2015 10:03:04 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id p6so1152393qcv.12 for ; Sat, 07 Feb 2015 10:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=djsrvRFBOtYMiJaVdx5gNFiivFvCwSI128VFcqeFu6A=; b=lj3FDJv2gvWWfYy80dF9XsEj9gKAvrwzK7DONx7P0Dxh+TDh2V+UanV1tvSMHGdUVS INB0z696SbgTddkdU5uEjj3ANbpcXEKhbQG0cwcZOaFDRN2JoO2SO5jdj1DE42+Jxd3M u+7XOBgma/JzyWAFwOGDXUhbmYpzRjqrIfxtizfxGfqWpAd6FZkgZXNRJaEZBRlDjwvO Rbw97SMwutGkIwzX1J2jZz+XywYrhQlBELwIJ0rieDeVoO08365SJxZbU5HZhf0QATky nRYcDC/b/CjVpN8r3Qq4tvitWPqUaL5qJE1otTH3PbbZfQewa4cT+3ND+t6oBM8XePIu 5R8w== MIME-Version: 1.0 X-Received: by 10.229.19.68 with SMTP id z4mr7852319qca.14.1423332184033; Sat, 07 Feb 2015 10:03:04 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.140.49.33 with HTTP; Sat, 7 Feb 2015 10:03:03 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Feb 2015 13:03:03 -0500 X-Google-Sender-Auth: t_Hv-nSVh4r5QjEGNdUszv6PtKM Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 18:03:06 -0000 sounds like a good topic for the mic/front/preso in dallas... to me at leas= t. On Sat, Feb 7, 2015 at 9:34 AM, George, Wes wro= te: > I posed some questions about this in my WGLC review of bgpsec spec, but > haven't heard anything back. Current schedule has this being evaluated by > IESG prior to our next meeting. If we need to discuss during the meeting > in Dallas, we could certainly delay processing of the document. It has a > normative block on the bgpsec spec, so it's not like it's getting > published right away anyway. > > Thanks, > > Wes > > > > On 2/6/15, 11:15 AM, "Randy Bush" wrote: > >>has the wg really looked at 5.2 and 5.3 with respect to how the ibgp >>hacks affect the bgpsec spec? >> >>randy > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Sat Feb 7 15:29:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3821A6F20 for ; Sat, 7 Feb 2015 15:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNe41La1b5qG for ; Sat, 7 Feb 2015 15:29:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E1A1A1B78 for ; Sat, 7 Feb 2015 15:29:02 -0800 (PST) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sat, 7 Feb 2015 23:28:39 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0065.013; Sat, 7 Feb 2015 23:28:38 +0000 From: "Sriram, Kotikalapudi" To: David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQObnP/eFvHk0J6E2CzGstO0tmlJzjGf4AgALK1hw= Date: Sat, 7 Feb 2015 23:28:38 +0000 Message-ID: <1423351717341.84961@nist.gov> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com>, <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> In-Reply-To: <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.219.5] authentication-results: mandelberg.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-forefront-prvs: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(99286002)(46102003)(76176999)(50986999)(2900100001)(230783001)(106116001)(117636001)(92566002)(66066001)(102836002)(2950100001)(54356999)(107886001)(86362001)(87936001)(77156002)(2656002)(40100003)(2501002)(122556002)(36756003)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0302; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2015 23:28:38.1094 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0302 Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 23:29:05 -0000 =0A= >It might be possible for an attacker to take a valid signature of data fro= m the structure in 4.2, =0A= >and present it as a valid signature of the same bytes interpreted with the= structure in 4.1.=0A= =0A= If you have worked out a concrete example showing how the attack works, =0A= it would be good to see that. For this type of attack to be feasible, is it= required that the size =0A= of the signature field equals the combined size of {Alg. ID, NLRI length, N= LRI prefix}?=0A= If yes, observe that the size of the signature field (ECDSA-P256) =3D 64 oc= tets + a few variable #octets,=0A= and the combined size of {Alg. ID, NLRI length, NLRI prefix} is either 6 oc= tets (IPv4) or 18 octets (IPv6).=0A= =0A= Sriram =0A= =0A= From nobody Mon Feb 9 10:53:01 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4B1A1BEC for ; Mon, 9 Feb 2015 10:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.299 X-Spam-Level: X-Spam-Status: No, score=-99.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzexjKj69tlA for ; Mon, 9 Feb 2015 10:31:16 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C241A1B6E for ; Mon, 9 Feb 2015 10:31:11 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id b6so3599471yha.10 for ; Mon, 09 Feb 2015 10:31:11 -0800 (PST) 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=AkXtf+6Radfo5lyHr0cAY4QsMJUN+0eOJb9uIjZornQ=; b=EjXuGN9nnQ+NmYsAKRZU0BZiv84vdfTsxFl7o3cr7snvELmtgUb5ocGxHGEMvlAvkn v5HsVfyQvkHB4y8Dn5MOPI6hTi+HTa31YGoQMJMX/b+hqbhwVY6kDTcwuXKF7gdGESfT ofvlUX+f0aHpL6AerlvR/5Y/OrbbiRvs/ND1/v4LPKsfeOyjTZ3vGZib4bZJG83a/yeL sgw7yXqVc+H0U8y3iIb9C1ljx70MlLLt+Y3NHgENAn7LgFFB48dK5wBMW26iUP1tIICc RkdTbQwdDW+0oN6Tf0ZvzOsqqvbViZi1TFPSxf2ubQ3uAFkUmlaLqP8NB0YK6YI1/6jH STsQ== MIME-Version: 1.0 X-Received: by 10.236.97.71 with SMTP id s47mr2004058yhf.38.1423506670889; Mon, 09 Feb 2015 10:31:10 -0800 (PST) Received: by 10.170.133.80 with HTTP; Mon, 9 Feb 2015 10:31:10 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 13:31:10 -0500 Message-ID: From: Alia Atlas To: "George, Wes" Content-Type: multipart/alternative; boundary=001a11c1c35274300f050eabf97b Archived-At: Cc: "draft-ietf-sidr-as-migration@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:31:19 -0000 --001a11c1c35274300f050eabf97b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wes, In-line with [Alia] On Mon, Feb 2, 2015 at 1:38 PM, George, Wes wrote: > Alia =E2=80=93 thanks for the review. Consider this ACK for all comment= s except > the ones below, inline with WG] > I have a =E2=80=9303 draft in the edit buffer, and will publish once the = below is > resolved. > > > Thanks, > > > > Wes > > > > > From: Alia Atlas > Date: Friday, January 30, 2015 at 3:50 PM > To: "draft-ietf-sidr-as-migration@tools.ietf.org" < > draft-ietf-sidr-as-migration@tools.ietf.org>, "sidr@ietf.org" < > sidr@ietf.org> > Subject: AD review and progressing draft-ietf-sidr-as-migration-02 > Resent-To: , "George, Wes" > > a) Language around draft-ietf-idr-as-migration is more tentative than is > appropriate > when that draft and this are going to be RFCs. Please clean that up. > > WG] other than removing the first paragraph of section 4 (done), and > fixing the intro (removed de facto), were there other places that this > needs to be addressed? > [Alia] That sounds about right. > b) In Sec 3.1, it says > > "If the route now shows up as originating > from AS64500, any downstream peers' validation check will fail unless > a ROA is *also* available for AS64500 as the origin ASN, meaning that > there will be overlapping ROAs until all routers originating prefixes > from AS64510 are migrated to AS64500." > > I think the second AS64500 should be AS64510. > > WG] no. This is saying that a ROA already exists for 64510, but needs to > exist for 64500. The distinction the second half of that section is makin= g > is that in addition to generating a ROA for 65400 for any prefixes > originated by the router being moved, because of replace-AS, you may have > to generate ROAs for 65400 for routes that are originating on routers sti= ll > in 65410. If that explanation is any clearer, I can try to edit the text = to > reflect this. > [Alia] Yes, if you could clarify it a bit that'd help. > > e) In draft-ietf-idr-as-migration, the case of handling AS migration in = iBGP sessions is also covered. I assume that because it is iBGP sessions, = there is no work to be done for BGPsec. Could you please add a quick obvio= us statement to that effect? > > > WG] hmm. This solution was originally written before the iBGP stuff was > added, and it didn't occur to me that it may need to be discussed here. > Pitfalls of two largely parallel docs, I guess. > The iBGP AS migration discussed is basically just listening for open on > either ASN, but otherwise treats the session as iBGP even if the ASN is n= ot > the same as the globally-configured one. Thus there are two ASNs involved= , > and this is mainly the same as AS migration with eBGP, in that the > migrating router would need to have a pcount=3D0 from old ASN to New in o= rder > to hide that path in routes that are signed to the old ASN from downstrea= m > eBGP peers. The wrinkle is that instead of the migration point being on t= he > edge router between its eBGP peers and its iBGP peers, the migration poin= t > is now one router upstream, between two iBGP peers (i.e. The router in th= e > old ASN doesn't necessarily know to mask its global ASN with pcount=3D0, = and > so the router that is at the actual border between the two ASNs will have > to do the pcount=3D0 trick to the "iBGP" updates it receives. I'll need t= o > add some text in 5.3 to cover this case. Good catch. > [Alia] Thanks - looking forward to it. Alia > > > ------------------------------ > 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. > --001a11c1c35274300f050eabf97b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wes,

In-line with [Alia]

On Mon, Feb 2, 2015 at = 1:38 PM, George, Wes <wesley.george@twcable.com> wro= te:
Alia =E2=80=93 thanks for the review. Consider this ACK for all commen= ts except the ones below, inline with WG]
I have a =E2=80=9303 draft in the edit buffer, and will publish once t= he below is resolved.=C2=A0

Tha= nks,

= =C2=A0

Wes=

= =C2=A0

From: Alia Atlas <akatlas@gmail.com>
Date: Friday, January 30, 2015 at 3= :50 PM
To: "draft-ietf-sidr-as-= migration@tools.ietf.org" <draft-ietf-sidr-as-migration@t= ools.ietf.org>, "sidr@ietf.org= " <sidr@ietf.org= >
Subject: AD review and progressing = draft-ietf-sidr-as-migration-02
Resent-To: <sandy@tislabs.com>, "George,= Wes" <wesley.george@twcable.com>

a) Language around draft-ietf-idr-as-migration is more ten= tative than is appropriate
when that draft and this are going to be RFCs.=C2=A0 Please clean that= up.

WG] other than removing the first paragraph of section 4 (done), and f= ixing the intro (removed de facto), were there other places that this needs= to be addressed?=C2=A0

[Alia] = That sounds about right.
=C2=A0
b) In Sec 3.1, it says

"If the route now shows up as originating
=C2=A0 =C2=A0from AS64500, any downstream peers' validation check will = fail unless
=C2=A0 =C2=A0a ROA is *also* available for AS64500 as the origin ASN, meani= ng that
=C2=A0 =C2=A0there will be overlapping ROAs until all routers originating p= refixes
=C2=A0 =C2=A0from AS64510 are migrated to AS64500."

I think the second AS64500 should be AS64510.

WG] no. This is saying that a ROA already exists for 64510, but= needs to exist for 64500. The distinction the second half of that section = is making is that in addition to generating a ROA for 65400 for any prefixe= s originated by the router being moved, because of replace-AS, you may have to generate ROAs for 65400 for routes = that are originating on routers still in 65410. If that explanation is any = clearer, I can try to edit the text to reflect this.=C2=A0

[Alia] Yes, if you could clarify it a bit that&= #39;d help. =C2=A0
=C2=A0

e) In draft-i=
etf-idr-as-migration, the case of handling AS migration in iBGP sessions is=
 also covered.  I assume that because it is iBGP sessions, there is no work=
 to be done for BGPsec.  Could you please add a quick obvious statement to =
that effect?

WG] hmm. This solution was originally written before the iBGP s= tuff was added, and it didn't occur to me that it may need to be discus= sed here. Pitfalls of two largely parallel docs, I guess.=C2=A0
The iBGP AS migration discussed is basically just listening for open o= n either ASN, but otherwise treats the session as iBGP even if the ASN is n= ot the same as the globally-configured one. Thus there are two ASNs involve= d, and this is mainly the same as AS migration with eBGP, in that the migrating router would need to have a = pcount=3D0 from old ASN to New in order to hide that path in routes that ar= e signed to the old ASN from downstream eBGP peers. The wrinkle is that ins= tead of the migration point being on the edge router between its eBGP peers and its iBGP peers, the migratio= n point is now one router upstream, between two iBGP peers (i.e. The router= in the old ASN doesn't necessarily know to mask its global ASN with pc= ount=3D0, and so the router that is at the actual border between the two ASNs will have to do the pcount=3D0 tric= k to the "iBGP" updates it receives. I'll need to add some te= xt in 5.3 to cover this case. Good catch.

=
[Alia] Thanks - looking forward to it.

= Alia=C2=A0
=C2=A0


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.

--001a11c1c35274300f050eabf97b-- From nobody Mon Feb 9 11:00:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B781A1B6E for ; Mon, 9 Feb 2015 10:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRNQrYxyJmdL for ; Mon, 9 Feb 2015 10:36:00 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C5A1A1A9A for ; Mon, 9 Feb 2015 10:36:00 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id c41so2220390yho.2 for ; Mon, 09 Feb 2015 10:36:00 -0800 (PST) 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=3QEY8lVyiTmybHWT5U+YCnMPZjkTksbZpRjbXpwWFNk=; b=0Akm0ve3oYtN6n5NumcgAiwh85iSUOIthaEtYBh16sWb1U5Yk/+NCSCiU6gu2mMeXG swvfHzHfnsqXmHiQH7ywz3jDV7yVCLPPHOjciDwld9BaBzH/alEv3CR0D8Reixw1tTf4 LxwpcQl74TWSPkGt59a8uX5e9tpqsjUb+1ewd3S6T+KF6owXzPhpDkvqbjVhqycOwFCZ LK3oz5v6WRjaGdN7Y2j1mLSMNcno1+Sd51YCAai2L0981jR/TLE1fSDet4Rvu0QxcGzZ 0ITEbv1Id4sAFstfkcNipWZQcyGhsJ0lZPbFP6J8+kxcS04dGO18EcBY9B9s1A1qKepp uQaw== MIME-Version: 1.0 X-Received: by 10.236.203.108 with SMTP id e72mr7062889yho.48.1423506959971; Mon, 09 Feb 2015 10:35:59 -0800 (PST) Received: by 10.170.133.80 with HTTP; Mon, 9 Feb 2015 10:35:59 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 13:35:59 -0500 Message-ID: From: Alia Atlas To: Christopher Morrow Content-Type: multipart/alternative; boundary=089e0160b506af38f3050eac0a31 Archived-At: Cc: sidr wg list Subject: Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:36:03 -0000 --089e0160b506af38f3050eac0a31 Content-Type: text/plain; charset=UTF-8 I've passed the draft back to the WG. When the necessary conversation and WGLC has occurred again, I'll be happy to progress it quickly. Thanks, Alia On Sat, Feb 7, 2015 at 1:03 PM, Christopher Morrow wrote: > sounds like a good topic for the mic/front/preso in dallas... to me at > least. > > On Sat, Feb 7, 2015 at 9:34 AM, George, Wes > wrote: > > I posed some questions about this in my WGLC review of bgpsec spec, but > > haven't heard anything back. Current schedule has this being evaluated by > > IESG prior to our next meeting. If we need to discuss during the meeting > > in Dallas, we could certainly delay processing of the document. It has a > > normative block on the bgpsec spec, so it's not like it's getting > > published right away anyway. > > > > Thanks, > > > > Wes > > > > > > > > On 2/6/15, 11:15 AM, "Randy Bush" wrote: > > > >>has the wg really looked at 5.2 and 5.3 with respect to how the ibgp > >>hacks affect the bgpsec spec? > >> > >>randy > > > > > > 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. > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --089e0160b506af38f3050eac0a31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've passed the draft back to the WG.=C2=A0 When the n= ecessary conversation and WGLC has occurred again,
I'll be happy to= progress it quickly.

Thanks,
Alia
=

On Sat, Feb= 7, 2015 at 1:03 PM, Christopher Morrow <morrowc.lists@gmail.com= > wrote:
sounds like a good top= ic for the mic/front/preso in dallas... to me at least.

On Sat, Feb 7, 2015 at 9:34 AM, George, Wes <wesley.george@twcable.com> wrote:
> I posed some questions about this in my WGLC review of bgpsec spec, bu= t
> haven't heard anything back. Current schedule has this being evalu= ated by
> IESG prior to our next meeting. If we need to discuss during the meeti= ng
> in Dallas, we could certainly delay processing of the document. It has= a
> normative block on the bgpsec spec, so it's not like it's gett= ing
> published right away anyway.
>
> Thanks,
>
> Wes
>
>
>
> On 2/6/15, 11:15 AM, "Randy Bush" <randy@psg.com> wrote:
>
>>has the wg really looked at 5.2 and 5.3 with respect to how the ibg= p
>>hacks affect the bgpsec spec?
>>
>>randy
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright 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 no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.
> __________________= _____________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--089e0160b506af38f3050eac0a31-- From nobody Mon Feb 9 13:02:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A971A88A4 for ; Mon, 9 Feb 2015 12:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LJsB7gpT86b for ; Mon, 9 Feb 2015 12:16:56 -0800 (PST) Received: from nm16-vm8.access.bullet.mail.gq1.yahoo.com (nm16-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.224]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD2F1A8864 for ; Mon, 9 Feb 2015 12:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423513016; bh=lnCUDOKmsHAZ+S3tJYZ/TzfUdwFQ+SCSIWXLmJv9uak=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=kZFgXmtFoYjEminZeM1r48lQm2N3LJ3WVuyqKdP1Tp0X+41E/JwKwD8G2HY78ta8M9/HPjrc6dJ4HU8ZE5LxdwFXZJIj1Y+VQa0yPz+QjVNKrexsAretaibJ4GW/UMuX1QEq/8ljYJZYdSWzwgOZETud9iPioRMF4wYKGf1v2emky2llCbdsDIx4rh4drCitVvXkL++12hy6FlIim7KeT6XO22R4YMReZ2T95yl+wbngBvR0EjKmBlT0b1OgCWosmQ3soITKVpd4YNEZcz6G93/TZXentZZweVnodPu0qqPPCROz+qLyN3j1Vrb8D5krrOoVjZ/7CpAHwiCWzhgw7A== Received: from [216.39.60.171] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Feb 2015 20:16:56 -0000 Received: from [98.138.226.241] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Feb 2015 20:16:56 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 09 Feb 2015 20:16:56 -0000 X-Yahoo-Newman-Id: 129169.43184.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9YHrl6QVM1nm2nJ1f4ycQAL91aZp.Wg961o0UT3S.wQRpWk .Bru2Ug8REhu5i_aZc7wE7HwH086HE_ETpPAwTzLokbdilvCOOrcNqsmK_N1 dqZW_jSJDJU.7nMJkjIJqpWe4Xwnz4jAhj1JBTkqnqQzdC2Oj3EWlDzPHeCi 24WrBjqFHrNwUm.pHmBp9OUlV2ZJb6nAMgvl6o.u3fl6ebY3wGahtXsQc2kU 76BYKN8IAEB0H31hl7hkeHSzRRRxEabH_4TI_V_q3EEA_q9.SpI1YCSCXb1z Bmy4JS72wpZsffc_fT67GjgVus0P60ALhViCO.9KRXq.zzl3s_yoHAanAofC BexMTcCBA4ZdY3lpgegVgZGUleGRcZpXLk2.p8Q_TrFFJoKt5x.2eUGrjhfL sbB01KdBFsvExtvsjityCUHBX0JBrfriwogjXUCm_03INOfqmpDqeMQjaf0u Ch62D7Bi8apU78q29wWiu9YxTGNhCv9odcZAX8ForstOiSwvHO56Dp0bQeoq mZ5VoqkNRwSpJNlmhG0frg5vUu2SuPTDu6iz3mcICqvlGMPv1R_dSsFjyJOU EaQJie0SbGiaN7S6Y7zcIBpW6xI0kCcYwtfy8BeiCYLXrGSJ3bA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CAA411C6029 for ; Mon, 9 Feb 2015 15:16:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Feb 2015 15:16:54 -0500 From: David Mandelberg To: In-Reply-To: <1423351717341.84961@nist.gov> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com>, <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <1423351717341.84961@nist.gov> Message-ID: <372b33e64a0cb7c5f516dd88a09b9e8a@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:17:03 -0000 On 2015-02-07 18:28, Sriram, Kotikalapudi wrote: >>It might be possible for an attacker to take a valid signature of >> data from the structure in 4.2, >>and present it as a valid signature of the same bytes interpreted >> with the structure in 4.1. > > If you have worked out a concrete example showing how the attack > works, > it would be good to see that. For this type of attack to be feasible, > is it required that the size > of the signature field equals the combined size of {Alg. ID, NLRI > length, NLRI prefix}? Yes, that's correct. > If yes, observe that the size of the signature field (ECDSA-P256) = > 64 octets + a few variable #octets, > and the combined size of {Alg. ID, NLRI length, NLRI prefix} is > either 6 octets (IPv4) or 18 octets (IPv6). Good catch. It seems that for a feasible attack, a future algorithm suite would need to have much shorter signatures (unlikely) or bgpsec would need to be extended to something with much longer NLRI prefixes (who's ready for IPv8?!) So this isn't going to bite us for a very long time, if ever. Should we (1) prevent that remote possibility by adding a single byte to both to-be-signed structures (which doesn't add any bytes on the wire), (2) make a note in the security considerations, or (3) just ignore this as too unlikely to care about? If we choose either 2 or 3, won't it be very difficult to change our minds once bgpsec is deployed? How hard is it to do (1) now? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Feb 10 09:11:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393AE1A9117 for ; Tue, 10 Feb 2015 09:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl1cF9dLs-b0 for ; Tue, 10 Feb 2015 09:11:26 -0800 (PST) Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 182F01A9119 for ; Tue, 10 Feb 2015 09:09:05 -0800 (PST) Received: from localhost (unknown [173.239.75.179]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 70660395D3E; Tue, 10 Feb 2015 09:09:04 -0800 (PST) From: Michael Baer To: David Mandelberg References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (David Mandelberg's message of "Thu, 05 Feb 2015 23:38:16 -0500") Message-ID: <87iof9r8wg.fsf@rebma.mikesoffice.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:11:29 -0000 >>>>> On Thu, 05 Feb 2015 23:38:16 -0500, David Mandelberg said: David> After reviewing this document, I have one concern below, and David> some nits that I'll send to the editor. Otherwise it looks David> good to me. David> In sections 4.1 and 4.2, there are two different to-be-signed David> structures. If I understand correctly, the same router keys David> will be used to sign data from both structures. It might be David> possible for an attacker to take a valid signature of data David> from the structure in 4.2, and present it as a valid David> signature of the same bytes interpreted with the structure in David> 4.1. I'm not sure anything malicious could be done this way, David> but reinterpreting the meaning of signed data seems like a David> bad idea to me. It would be easy to prevent this by David> prepending both structures with a single byte that MUST BE 0 David> for 4.1 and MUST BE 1 for 4.2. Apologies if this has already David> been discussed and is not an issue. I don't believe this is a problem. The signature is calculated by creating a digest of the data and then creating a signature from that digest. I'm definitely not a cryptography expert, but my understanding of digest functions generally is that with even slightly differing input, the resulting set of bits should be completely different. Assuming the digest function chosen is not flawed, there shouldn't be a set of bits from the digest of 4.1 that could be used to successfully replace the digest of 4.2, except by chance. -Mike -- Michael Baer baerm@tislabs.com From nobody Tue Feb 10 13:48:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BAA1A86F7 for ; Tue, 10 Feb 2015 13:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvPqHB7uya1i for ; Tue, 10 Feb 2015 13:48:01 -0800 (PST) Received: from nm26-vm4.access.bullet.mail.gq1.yahoo.com (nm26-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.114]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFC31A19FA for ; Tue, 10 Feb 2015 13:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423604880; bh=/MiVZk5T1y4r+tDdGA3LtVJyAypgaCwqXxomrwx8eKU=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=XmZBfZys9styChwOrYCeGlw/vHUqdkTWOjSpyFWhyqWM7vKCsWa7E0LHhjPPm0hC6unVbRABRU7Xpg4PDuAx7VuVUMsp9H+0AUCbm1pCg7KxwkhwYsG1XJMf2Yw2/MNho7dXFimQ9xAF0OGLrTVcfX8KtqF6zXcCjz6TnjXV3nyCOKEKgUIhyoDaO8G1pRTyQI+naGxBLXS6kiTvrMj50FQxX55rgCKMMukbZ0ue9JZy29wzvVcjoXlGQ9oCPCr0FWNjIdKVMt/cU+c7FMVtx0WJZNh6nsArlMUgBoqGdn4lQCsQ2TG+qalPTW8zoUxQGD8gX27ASv0J2Iqbnu78iA== Received: from [216.39.60.166] by nm26.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2015 21:48:00 -0000 Received: from [98.138.104.97] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 10 Feb 2015 21:48:00 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 10 Feb 2015 21:48:00 -0000 X-Yahoo-Newman-Id: 622214.60801.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tId_3vgVM1lWbs5QvHtpoyXD..ry3abIKd_JDft6GFFSySR 1pBWcJxmTLTcul9SnhTo82fh5sm_LH5bVOH86zgKRvEw2DZhl10vaN_dhGsK J01UxZC6Fr9lm8Spkrqjb1cZl9Scdsj_arnEpXWYLaWQ_nq8YNt1XT8VLfVm LVdM5QvvbHCMyQXvfgk8kcr6.0w2kBccG5CahxB2lQ0NJaGyCRZQkip.X5yk h2HLuLCpSBu2dztk3HA69JrB9RbX9bbmERNo9zPgMl6zXp7.jLkwNaRW0a_V 18RU2cbVOLFJRg5iQ_5pMywA77g8mj15waJ4Z9Loi7ZRFmuZ8rYBF7KFN3SR 3w3mOt61OwPi3UM0f95FQ.0IcsXK76du8x2nm0wXU8WH_NWI7zw7QFPGqKYe O6zJSg8nr3whZ3f4GZbY1MhzT425CcOYkvg0nz54tNIx8uG_JIgBkxkWowrv qPJKiYAVf6rFlcbP53tpLsJ1P10VUUx4u6XXR1cLMOMq90u4eMGKk5vZmorm VCgdA.x3YW2Jwf7ug7O9pcwPrk49tpfCWONz9RYpyqNgSuHhOeTmmXi53hPV tgRpPU7iZAz5NqulTP3y.j5yU2eugKhjbRj8ytLugweweHr2.EKTzDQ6IVBt bQssZ0Rs- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.13] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 3E3E71C6029 for ; Tue, 10 Feb 2015 16:47:59 -0500 (EST) Message-ID: <54DA7C98.4040604@mandelberg.org> Date: Tue, 10 Feb 2015 16:48:08 -0500 From: David Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sidr@ietf.org References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> In-Reply-To: <87iof9r8wg.fsf@rebma.mikesoffice.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NvX6a6Tpjkimbc7RlfbHEoARBE5P9wWxu" Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 21:48:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NvX6a6Tpjkimbc7RlfbHEoARBE5P9wWxu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, while coming up with the example below, I realized another issue. The structure in 4.1 doesn't include an Address Family Identifier. Unless I missed something, this means that a signature for 1.2.0.0/16 would be exactly the same as a signature for 102::/16. This would be a much more practical attack than the one I originally though of. Michael, response to your comment is below. On 02/10/2015 12:09 PM, Michael Baer wrote: > I don't believe this is a problem. The signature is calculated by > creating a digest of the data and then creating a signature from that > digest. I'm definitely not a cryptography expert, but my understanding= > of digest functions generally is that with even slightly differing > input, the resulting set of bits should be completely different. > Assuming the digest function chosen is not flawed, there shouldn't be a= > set of bits from the digest of 4.1 that could be used to successfully > replace the digest of 4.2, except by chance. You're right about digest algorithms being highly sensitive to changes in the input, but the issue I described is when the two inputs are equal, not just similar. For example, if a router signed the below values in the structure from 4.2: Target AS Number =3D 0x01020304 Origin AS Number =3D 0x05060708 pCount =3D 0x01 Flags =3D 0x00 Most Recent Sig Field =3D 0x00700102030405060708090a0b0c0d0e (See Sriram'= s email for why this would never actually happen with the current algorithm suite's signature length.) Then the router signed the digest of the bytes 0x0102030405060708010000700102030405060708090a0b0c0d0e. However, these exact same bytes could appear to have come from the structure in 4.1 with these values: Target AS Number =3D 0x01020304 Origin AS Number =3D 0x05060708 pCount =3D 0x01 Flags =3D 0x00 Algorithm Suite Id =3D 0x00 NLRI Length =3D 0x70 (112 bits =3D 14 bytes) NLRI Prefix =3D 0x0102030405060708090a0b0c0d0e Note that the first 16 bits of 4.2's Most Recent Sig Field can't be any values. The first 8 have to match the Algorithm Suite ID (1 possible value). The next 8 have to be a valid number of bits for the number of bytes in the prefix (8 possible values). This means that there's only a 2^-13 chance that a single random Most Recent Sig Field of the appropriate length could be reinterpreted successfully. However, with more than 2^13 signatures floating around the Internet, that's not good odds. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --NvX6a6Tpjkimbc7RlfbHEoARBE5P9wWxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTafJgACgkQRKlmUHCg4sBFKwCcDhWV/yRHmmcliHkkC5fkXXpw mQIAnRbKZjkxtC1y2Ohlmn4zFWbPoQRh =1Sd6 -----END PGP SIGNATURE----- --NvX6a6Tpjkimbc7RlfbHEoARBE5P9wWxu-- From nobody Tue Feb 10 22:17:18 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B656E1A6FEE for ; Tue, 10 Feb 2015 22:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LA07bypRFrT for ; Tue, 10 Feb 2015 22:17:14 -0800 (PST) Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id EBCBB1A0024 for ; Tue, 10 Feb 2015 22:17:13 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 9BDB8395D3E; Tue, 10 Feb 2015 22:17:13 -0800 (PST) From: Michael Baer To: David Mandelberg References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org> X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (David Mandelberg's message of "Tue, 10 Feb 2015 16:48:08 -0500") Message-ID: <87k2zpdlau.fsf@rebma.mikesoffice.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 06:17:15 -0000 >>>>> On Tue, 10 Feb 2015 16:48:08 -0500, David Mandelberg said: DM> All, while coming up with the example below, I realized another DM> issue. The structure in 4.1 doesn't include an Address Family DM> Identifier. Unless I missed something, this means that a DM> signature for 1.2.0.0/16 would be exactly the same as a DM> signature for 102::/16. This would be a much more practical DM> attack than the one I originally though of. DM> Michael, response to your comment is below. DM> On 02/10/2015 12:09 PM, Michael Baer wrote: >> I don't believe this is a problem. The signature is calculated >> by creating a digest of the data and then creating a signature >> from that digest. I'm definitely not a cryptography expert, but >> my understanding of digest functions generally is that with even >> slightly differing input, the resulting set of bits should be >> completely different. Assuming the digest function chosen is not >> flawed, there shouldn't be a set of bits from the digest of 4.1 >> that could be used to successfully replace the digest of 4.2, >> except by chance. DM> You're right about digest algorithms being highly sensitive to DM> changes in the input, but the issue I described is when the two DM> inputs are equal, not just similar. For example, if a router DM> signed the below values in the structure from 4.2: DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708 DM> pCount = 0x01 Flags = 0x00 Most Recent Sig Field = DM> 0x00700102030405060708090a0b0c0d0e (See Sriram's email for why DM> this would never actually happen with the current algorithm DM> suite's signature length.) Ah, I see. Thanks for the explanation. I was not understanding the attack vector but I get how it would work now (and good to know the input won't match with the current algorithm). -Mike DM> Then the router signed the digest of the bytes DM> 0x0102030405060708010000700102030405060708090a0b0c0d0e. However, DM> these exact same bytes could appear to have come from the DM> structure in 4.1 with these values: DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708 DM> pCount = 0x01 Flags = 0x00 Algorithm Suite Id = 0x00 NLRI Length DM> = 0x70 (112 bits = 14 bytes) NLRI Prefix = DM> 0x0102030405060708090a0b0c0d0e DM> Note that the first 16 bits of 4.2's Most Recent Sig Field can't DM> be any values. The first 8 have to match the Algorithm Suite ID DM> (1 possible value). The next 8 have to be a valid number of bits DM> for the number of bytes in the prefix (8 possible values). This DM> means that there's only a 2^-13 chance that a single random Most DM> Recent Sig Field of the appropriate length could be DM> reinterpreted successfully. However, with more than 2^13 DM> signatures floating around the Internet, that's not good odds. DM> -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ DM> _______________________________________________ sidr mailing DM> list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr -- Michael Baer baerm@tislabs.com From nobody Thu Feb 12 14:39:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F69A1A19E5 for ; Thu, 12 Feb 2015 14:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzdAJbM5bV1k for ; Thu, 12 Feb 2015 14:39:47 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5261A038C for ; Thu, 12 Feb 2015 14:39:45 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DF2FF28B0041; Thu, 12 Feb 2015 17:39:44 -0500 (EST) Received: from cloud.netsec (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 98ACB1F8035; Thu, 12 Feb 2015 17:39:44 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_3E71515A-0414-4359-A9A1-EC68274528BE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <54DA7C98.4040604@mandelberg.org> Date: Thu, 12 Feb 2015 17:40:01 -0500 Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org> To: Randy Bush , Rob Austein X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: [sidr] David M's point about the bgpsec protocol (embarrassing) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:39:49 -0000 --Apple-Mail=_3E71515A-0414-4359-A9A1-EC68274528BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think David is right. This is embarrassing. I was looking at the syntax for the protocol in = response to David's previous message, realizing that there's no text = about what the NLRI length and NLRI prefix fields' syntax should be, = looking right at those fields, thinking only that we needed to copy the = text from 4271/4760, and did not spot this. This is embarrassing for the whole wg for not spotting the syntax = laxness. And embarrassing to all the security folk. There's a standard = problem in security protocols about not signing any old group of bits = you are given because the signed bits might be used in some other = context. So this should have been spotted much earlier. I keep hoping if I look at it closely there's a reason why this is not a = problem. Surely SteveK/MattL/SteveB/RussH/etc if the problem were this = obvious? Have you two looked at this? --Sandy On Feb 10, 2015, at 4:48 PM, David Mandelberg = wrote: > All, while coming up with the example below, I realized another issue. > The structure in 4.1 doesn't include an Address Family Identifier. > Unless I missed something, this means that a signature for 1.2.0.0/16 > would be exactly the same as a signature for 102::/16. This would be a > much more practical attack than the one I originally though of. >=20 --Apple-Mail=_3E71515A-0414-4359-A9A1-EC68274528BE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3SvBAAoJEHplpQeet0IZJ2EP/idY5UBgsxsYW6haFCurmsFQ YRtaizxUm8Mp0EXDmhsWsMbOVivrnfs9Cv+vCCyIi1+/Ol6iU7ijJoFlXUwACdaH I6D1KsEObPCnocsHXA6MNEBM571f7VrnnpIliv9B5iplFH+L6+c2AgcxMsvm2+rx 1Qo0smADLgCQF0MzenEkL8vLcmy1qEwZ0iQMJuVNo6mgB3iI2Zn5tLFIPW57Xb/K miVBvJ+n6R9NWDU1Ums0zosILisfl4HE2EKTgv1U1Ly0s3kDR7iV8a6Pvwgxr877 iy9Pby54pT7MrCQIHh48x48NgunVzUDF/OPVub6GBaRnkARzRR/+WpaZCAeGt5dC pKG8/mlWBJDD8XwvIt6Jv9wvj62YRsl5+DNB034AzBegQguNQekvtSwWyX1SS4il 96UMmkgBPvDDG4hSsjPm9VCMRG0NfZRK02l6Pgmd1YjWGMA3NNgUEM6jE62Wsjw2 ++6VPE3TbXlRcJWl2JKNuNjx6+WoDGZbX6O6diH5LDYcTtmw4nPCcapUnZperZXG TiYMlIs6wsS6IBttBvRvAmlllap6UQ7PEsu/dM7AyUhLeuq1DdVarTx3HtRc0G0u zvvM+lJiuVqc0sAkNYKUFxnlJWI078rqiIYvggkFcWq3XSXmMOyRnIDhvI3Wb3rF K2YrjI8HWcGVI3FCpZBT =nFXG -----END PGP SIGNATURE----- --Apple-Mail=_3E71515A-0414-4359-A9A1-EC68274528BE-- From nobody Thu Feb 12 16:13:06 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3111A014C for ; Thu, 12 Feb 2015 16:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuG_-Mi81_9r for ; Thu, 12 Feb 2015 16:12:51 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84C31A00FF for ; Thu, 12 Feb 2015 16:12:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YM3sG-0003Kb-Pt; Fri, 13 Feb 2015 00:12:49 +0000 Date: Fri, 13 Feb 2015 07:12:42 +0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] David M's point about the bgpsec protocol (embarrassing) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:13:00 -0000 > I think David is right. yep From nobody Thu Feb 12 18:59:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280F01A1A32 for ; Thu, 12 Feb 2015 18:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVWW66R7i3o0 for ; Thu, 12 Feb 2015 18:59:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F481A1A29 for ; Thu, 12 Feb 2015 18:59:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YM6TK-0004SS-Dv; Fri, 13 Feb 2015 02:59:15 +0000 Date: Fri, 13 Feb 2015 09:59:13 +0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] David M's point about the bgpsec protocol (embarrassing) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 02:59:20 -0000 > This is embarrassing for the whole wg for not spotting the syntax > laxness. And embarrassing to all the security folk. There's a > standard problem in security protocols about not signing any old group > of bits you are given because the signed bits might be used in some > other context. So this should have been spotted much earlier. bettr late than never. and a good security geek did spot it. good on david. randy From nobody Fri Feb 13 06:55:39 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0B1A870A for ; Fri, 13 Feb 2015 06:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D1a5Ezp5_06 for ; Fri, 13 Feb 2015 06:55:35 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961351A8702 for ; Fri, 13 Feb 2015 06:55:35 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E540128B0017 for ; Fri, 13 Feb 2015 09:55:34 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id AA6981F8035; Fri, 13 Feb 2015 09:55:34 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5E01CFEA-4DA7-4ABC-ADD3-A6869D012BF5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Fri, 13 Feb 2015 09:55:41 -0500 Message-Id: <4793C46A-0B6B-45D2-ACB8-638E5971F47D@tislabs.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] David M's point about the bgpsec protocol (embarrassing) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:55:37 -0000 --Apple-Mail=_5E01CFEA-4DA7-4ABC-ADD3-A6869D012BF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry for cc-ing the list on this message and the belaboring and = critical tone. I intended it as a private message, not a message to the = whole wg. I hope others are looking at the issue. I haven't seen anyone reply to = David. (Other than my oops-replied-to-all reply, of course. I wear the dunce = cap this week.) --Sandy On Feb 12, 2015, at 5:40 PM, Sandra Murphy wrote: > I think David is right. >=20 > This is embarrassing. I was looking at the syntax for the protocol in = response to David's previous message, realizing that there's no text = about what the NLRI length and NLRI prefix fields' syntax should be, = looking right at those fields, thinking only that we needed to copy the = text from 4271/4760, and did not spot this. >=20 > This is embarrassing for the whole wg for not spotting the syntax = laxness. And embarrassing to all the security folk. There's a standard = problem in security protocols about not signing any old group of bits = you are given because the signed bits might be used in some other = context. So this should have been spotted much earlier. >=20 > I keep hoping if I look at it closely there's a reason why this is not = a problem. Surely SteveK/MattL/SteveB/RussH/etc if the problem were = this obvious? >=20 > Have you two looked at this? >=20 > --Sandy >=20 > On Feb 10, 2015, at 4:48 PM, David Mandelberg = wrote: >=20 >> All, while coming up with the example below, I realized another = issue. >> The structure in 4.1 doesn't include an Address Family Identifier. >> Unless I missed something, this means that a signature for 1.2.0.0/16 >> would be exactly the same as a signature for 102::/16. This would be = a >> much more practical attack than the one I originally though of. >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_5E01CFEA-4DA7-4ABC-ADD3-A6869D012BF5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3hBuAAoJEHplpQeet0IZ+v4QALxzjE10sWjzeIRNw//RC0fG MAonINfgUs/jPGa+G2wSUvSVz0dXTkIeB4xyzVgFhbcuf+ppQqWgoAD1zc1drVLs MoZQAFpTlBiLeCeFaos/nKKoYzSF3hViHjNSsVPPmosXp+ExHFMnFHTCRsfMfgrT r5h1Dr3Xh6BnqyWe4hbI6+SqjpNI6GAY+eeu17WsV2skC8qqUWxHQWSMQ7nbyXMf XZDbyXw/+sRfBKSWya/t7l87MfEfYgxeeP3pwCVBzm/QRG24V14pcztLgaTeqbmi 3RRwnpEmGgO8zLbNo1+4p37Lh4u4wJWCBWgOYslqyXDdzGxa5/l7ZsgZQcXg5pG2 6+dnkexMw2pJzaLAXE99Khgg752wbfCGnvcam1ILCAsDQDTHZVZo2T+eNwfgWsRn hGbcxGgt4HtEPASup8i4XQ2HruJ2jW58K01za4eC5jfkEQ0tCZJXtqARkq36E4QZ j9JWrFfWbCCA4EN1KpPlmVzo528ILvB/V4p45hRjad+ph8kHn80Gny0FscfTKN2N kgQvjbUjAHjEg99KCNJrFmX5T5nTS+LR6UCPkPPyHj9cfoz4UEavVYrjPfT9/Dw+ DCYmR9mk5245uv9FKZc2oz4MjlGjyM8DkgpcY9z/ajoaLlc1hepK57x64Ki++vRY k7y+5Lr8evGMPEoeKoEK =F+X1 -----END PGP SIGNATURE----- --Apple-Mail=_5E01CFEA-4DA7-4ABC-ADD3-A6869D012BF5-- From nobody Fri Feb 13 17:03:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A601A00FF for ; Fri, 13 Feb 2015 17:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtPIN2SmSHvs for ; Fri, 13 Feb 2015 17:03:50 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913E51A03A9 for ; Fri, 13 Feb 2015 17:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2765; q=dns/txt; s=iport; t=1423875830; x=1425085430; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=OEYJXT/cn1THWOgEojWrVLirkWjHL8EYGjQuNOpKqcE=; b=EaRLGoqMkkcGueXvzazBX1GFitpAF9RBnlFUfAP9TChoWKrmhwyfCWZl ZftsVeante0G49WwmsRymT77GYwVuvhJLkeEgfTpAnWxuJ8FLhk4v3HaH zKXnCK632DpZPT9nieE19fdA1pbETloR28u5Fq8GOCJNTSJyT2C6Ywk3d o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFABie3lStJA2N/2dsb2JhbABbgwZSWgTCKoV1AoERQwEBAQEBAXyEDQEBBGsgAQgYYCUCBAESiC3UYAEBAQEBBQEBAQEeiwyECxEBV4QqBYoJhSuDVoVfgRg4jXeDPiKBfx+BUG+BBAcXBhx/AQEB X-IronPort-AV: E=Sophos;i="5.09,574,1418083200"; d="scan'208";a="392925928" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 14 Feb 2015 01:03:49 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1E13nSf029250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Feb 2015 01:03:49 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 19:03:49 -0600 From: "Keyur Patel (keyupate)" To: David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQR/IX9pGexz7OlEWPwIvxYzjWpA== Date: Sat, 14 Feb 2015 01:03:48 +0000 Message-ID: In-Reply-To: <54DA7C98.4040604@mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.123.137] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 01:03:54 -0000 Hi David, On 2/10/15, 1:48 PM, "David Mandelberg" wrote: >All, while coming up with the example below, I realized another issue. >The structure in 4.1 doesn't include an Address Family Identifier. >Unless I missed something, this means that a signature for 1.2.0.0/16 >would be exactly the same as a signature for 102::/16. This would be a >much more practical attack than the one I originally though of. But, isn=B9t this issue covered by origin-AS validation? Regards, Keyur > >Michael, response to your comment is below. > >On 02/10/2015 12:09 PM, Michael Baer wrote: >> I don't believe this is a problem. The signature is calculated by >> creating a digest of the data and then creating a signature from that >> digest. I'm definitely not a cryptography expert, but my understanding >> of digest functions generally is that with even slightly differing >> input, the resulting set of bits should be completely different. >> Assuming the digest function chosen is not flawed, there shouldn't be a >> set of bits from the digest of 4.1 that could be used to successfully >> replace the digest of 4.2, except by chance. > >You're right about digest algorithms being highly sensitive to changes >in the input, but the issue I described is when the two inputs are >equal, not just similar. For example, if a router signed the below >values in the structure from 4.2: > >Target AS Number =3D 0x01020304 >Origin AS Number =3D 0x05060708 >pCount =3D 0x01 >Flags =3D 0x00 >Most Recent Sig Field =3D 0x00700102030405060708090a0b0c0d0e (See Sriram's >email for why this would never actually happen with the current >algorithm suite's signature length.) > >Then the router signed the digest of the bytes >0x0102030405060708010000700102030405060708090a0b0c0d0e. However, these >exact same bytes could appear to have come from the structure in 4.1 >with these values: > >Target AS Number =3D 0x01020304 >Origin AS Number =3D 0x05060708 >pCount =3D 0x01 >Flags =3D 0x00 >Algorithm Suite Id =3D 0x00 >NLRI Length =3D 0x70 (112 bits =3D 14 bytes) >NLRI Prefix =3D 0x0102030405060708090a0b0c0d0e > >Note that the first 16 bits of 4.2's Most Recent Sig Field can't be any >values. The first 8 have to match the Algorithm Suite ID (1 possible >value). The next 8 have to be a valid number of bits for the number of >bytes in the prefix (8 possible values). This means that there's only a >2^-13 chance that a single random Most Recent Sig Field of the >appropriate length could be reinterpreted successfully. However, with >more than 2^13 signatures floating around the Internet, that's not good >odds. > >--=20 >David Eric Mandelberg / dseomn >http://david.mandelberg.org/ > From nobody Sat Feb 14 08:13:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABB1A1B2F for ; Sat, 14 Feb 2015 08:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osK5dNV0INuy for ; Sat, 14 Feb 2015 08:13:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5D31A6EE0 for ; Sat, 14 Feb 2015 08:13:18 -0800 (PST) Received: from BLUPR09MB0168.namprd09.prod.outlook.com (10.255.216.22) by BLUPR09MB0168.namprd09.prod.outlook.com (10.255.216.22) with Microsoft SMTP Server (TLS) id 15.1.81.19; Sat, 14 Feb 2015 16:13:17 +0000 Received: from BLUPR09MB0168.namprd09.prod.outlook.com ([10.255.216.22]) by BLUPR09MB0168.namprd09.prod.outlook.com ([10.255.216.22]) with mapi id 15.01.0081.018; Sat, 14 Feb 2015 16:13:17 +0000 From: "Montgomery, Douglas" To: "Keyur Patel (keyupate)" , David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQObnOcPb8vAQ1J0e+p2o22yvlkpzjGf4AgAcb4fmAAE0wAIAE7aoAgACqQQA= Importance: low X-Priority: 5 Date: Sat, 14 Feb 2015 16:13:16 +0000 Message-ID: References: <54DA7C98.4040604@mandelberg.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [129.6.219.148] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0168; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0168; x-forefront-prvs: 0487C0DB7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(51704005)(479174004)(54356999)(66066001)(81686999)(86362001)(122556002)(87936001)(107886001)(575784001)(15975445007)(36756003)(19580405001)(2656002)(77096005)(102836002)(106116001)(76176999)(50986999)(92566002)(99286002)(230783001)(19580395003)(77156002)(62966003)(40100003)(2950100001)(46102003)(2900100001)(83506001)(2501002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB0168; H:BLUPR09MB0168.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <7AD173B844BC5047A3768957B463C40A@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2015 16:13:16.1548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB0168 Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 16:13:21 -0000 U2luY2Ugd2UgYWdyZWVkIHRvIGRlY291cGxlIHBhdGggdmFsaWRpdHkgZnJvbSBvcmlnaW4gdmFs aWRpdHkgKGFuZCByZXR1cm4NCmJvdGggYXMgZGlzdGluY3QgdmFsaWRhdGlvbiByZXN1bHRzKSwg d2Ugc2hvdWxkIHByb2JhYmx5IGNsZWFuIHRoaXMgdXAuDQoNClRoYXQgaXMsIHdlIG5vdyBjYW7i gJl0IHJlbHkgb24gdGhlIG9yaWdpbiBiZWluZyBpbnZhbGlkLCB0byBpbnZhbGlkYXRlIHRoaXMN CnBhdGggbWFuaXB1bGF0aW9uLiANCg0KQW5kIGV2ZW4gaWYgd2UgaGFkIG5vdCBkZWNvdXBsZWQg dGhvc2UgdHdvLCBqdXN0IGJlY2F1c2UgeW91IG1pZ2h0IGJlDQphdXRob3JpemVkIHRvIGFubm91 bmNlIDEwMjo6LzE2IHRvIGEgcGVlciwgdGhhdCBpcyBkaWZmZXJlbnQgdGhhbiBzYXlpbmcNCnRo YXQgeW91IGFjdHVhbGx5IGFubm91bmNlZCBpdC4NCg0KSSByZWFsaXplIHRoYXQgdGhlIHRocmVh dCBzY2VuYXJpbyBoZXJlIGlzIGdldHRpbmcgZGltaW5pc2hpbmcgc21hbGwsIGJ1dA0Kc3RpbGws IHdlIHNob3VsZCBjbGVhbiB0aGlzIHVwIHRvIHJlZHVjZSBpdCB0byB6ZXJvLg0KDQpkb3VnbQ0K 4oCUIA0KRG91ZyBNb250Z29tZXJ5LCBNZ3IgSW50ZXJuZXQgJiBTY2FsYWJsZSBTeXN0ZW1zIFJl c2VhcmNoIEAgIE5JU1QvSVRML0FOVEQNCg0KDQoNCg0KDQpPbiAyLzEzLzE1LCA4OjAzIFBNLCAi S2V5dXIgUGF0ZWwgKGtleXVwYXRlKSIgPGtleXVwYXRlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5I aSBEYXZpZCwNCj4NCj4NCj5PbiAyLzEwLzE1LCAxOjQ4IFBNLCAiRGF2aWQgTWFuZGVsYmVyZyIg PGRhdmlkQG1hbmRlbGJlcmcub3JnPiB3cm90ZToNCj4NCj4+QWxsLCB3aGlsZSBjb21pbmcgdXAg d2l0aCB0aGUgZXhhbXBsZSBiZWxvdywgSSByZWFsaXplZCBhbm90aGVyIGlzc3VlLg0KPj5UaGUg c3RydWN0dXJlIGluIDQuMSBkb2Vzbid0IGluY2x1ZGUgYW4gQWRkcmVzcyBGYW1pbHkgSWRlbnRp Zmllci4NCj4+VW5sZXNzIEkgbWlzc2VkIHNvbWV0aGluZywgdGhpcyBtZWFucyB0aGF0IGEgc2ln bmF0dXJlIGZvciAxLjIuMC4wLzE2DQo+PndvdWxkIGJlIGV4YWN0bHkgdGhlIHNhbWUgYXMgYSBz aWduYXR1cmUgZm9yIDEwMjo6LzE2LiBUaGlzIHdvdWxkIGJlIGENCj4+bXVjaCBtb3JlIHByYWN0 aWNhbCBhdHRhY2sgdGhhbiB0aGUgb25lIEkgb3JpZ2luYWxseSB0aG91Z2ggb2YuDQo+DQo+DQo+ QnV0LCBpc27CuXQgdGhpcyBpc3N1ZSBjb3ZlcmVkIGJ5IG9yaWdpbi1BUyB2YWxpZGF0aW9uPw0K Pg0KPlJlZ2FyZHMsDQo+S2V5dXINCj4NCj4NCj4NCj4+DQo+Pk1pY2hhZWwsIHJlc3BvbnNlIHRv IHlvdXIgY29tbWVudCBpcyBiZWxvdy4NCj4+DQo+Pk9uIDAyLzEwLzIwMTUgMTI6MDkgUE0sIE1p Y2hhZWwgQmFlciB3cm90ZToNCj4+PiBJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBhIHByb2JsZW0u ICBUaGUgc2lnbmF0dXJlIGlzIGNhbGN1bGF0ZWQgYnkNCj4+PiBjcmVhdGluZyBhIGRpZ2VzdCBv ZiB0aGUgZGF0YSBhbmQgdGhlbiBjcmVhdGluZyBhIHNpZ25hdHVyZSBmcm9tIHRoYXQNCj4+PiBk aWdlc3QuICBJJ20gZGVmaW5pdGVseSBub3QgYSBjcnlwdG9ncmFwaHkgZXhwZXJ0LCBidXQgbXkg dW5kZXJzdGFuZGluZw0KPj4+IG9mIGRpZ2VzdCBmdW5jdGlvbnMgZ2VuZXJhbGx5IGlzIHRoYXQg d2l0aCBldmVuIHNsaWdodGx5IGRpZmZlcmluZw0KPj4+IGlucHV0LCB0aGUgcmVzdWx0aW5nIHNl dCBvZiBiaXRzIHNob3VsZCBiZSBjb21wbGV0ZWx5IGRpZmZlcmVudC4NCj4+PiBBc3N1bWluZyB0 aGUgZGlnZXN0IGZ1bmN0aW9uIGNob3NlbiBpcyBub3QgZmxhd2VkLCB0aGVyZSBzaG91bGRuJ3Qg YmUgYQ0KPj4+IHNldCBvZiBiaXRzIGZyb20gdGhlIGRpZ2VzdCBvZiA0LjEgdGhhdCBjb3VsZCBi ZSB1c2VkIHRvIHN1Y2Nlc3NmdWxseQ0KPj4+IHJlcGxhY2UgdGhlIGRpZ2VzdCBvZiA0LjIsIGV4 Y2VwdCBieSBjaGFuY2UuDQo+Pg0KPj5Zb3UncmUgcmlnaHQgYWJvdXQgZGlnZXN0IGFsZ29yaXRo bXMgYmVpbmcgaGlnaGx5IHNlbnNpdGl2ZSB0byBjaGFuZ2VzDQo+PmluIHRoZSBpbnB1dCwgYnV0 IHRoZSBpc3N1ZSBJIGRlc2NyaWJlZCBpcyB3aGVuIHRoZSB0d28gaW5wdXRzIGFyZQ0KPj5lcXVh bCwgbm90IGp1c3Qgc2ltaWxhci4gRm9yIGV4YW1wbGUsIGlmIGEgcm91dGVyIHNpZ25lZCB0aGUg YmVsb3cNCj4+dmFsdWVzIGluIHRoZSBzdHJ1Y3R1cmUgZnJvbSA0LjI6DQo+Pg0KPj5UYXJnZXQg QVMgTnVtYmVyID0gMHgwMTAyMDMwNA0KPj5PcmlnaW4gQVMgTnVtYmVyID0gMHgwNTA2MDcwOA0K Pj5wQ291bnQgPSAweDAxDQo+PkZsYWdzID0gMHgwMA0KPj5Nb3N0IFJlY2VudCBTaWcgRmllbGQg PSAweDAwNzAwMTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlIChTZWUgU3JpcmFtJ3MNCj4+ZW1h aWwgZm9yIHdoeSB0aGlzIHdvdWxkIG5ldmVyIGFjdHVhbGx5IGhhcHBlbiB3aXRoIHRoZSBjdXJy ZW50DQo+PmFsZ29yaXRobSBzdWl0ZSdzIHNpZ25hdHVyZSBsZW5ndGguKQ0KPj4NCj4+VGhlbiB0 aGUgcm91dGVyIHNpZ25lZCB0aGUgZGlnZXN0IG9mIHRoZSBieXRlcw0KPj4weDAxMDIwMzA0MDUw NjA3MDgwMTAwMDA3MDAxMDIwMzA0MDUwNjA3MDgwOTBhMGIwYzBkMGUuIEhvd2V2ZXIsIHRoZXNl DQo+PmV4YWN0IHNhbWUgYnl0ZXMgY291bGQgYXBwZWFyIHRvIGhhdmUgY29tZSBmcm9tIHRoZSBz dHJ1Y3R1cmUgaW4gNC4xDQo+PndpdGggdGhlc2UgdmFsdWVzOg0KPj4NCj4+VGFyZ2V0IEFTIE51 bWJlciA9IDB4MDEwMjAzMDQNCj4+T3JpZ2luIEFTIE51bWJlciA9IDB4MDUwNjA3MDgNCj4+cENv dW50ID0gMHgwMQ0KPj5GbGFncyA9IDB4MDANCj4+QWxnb3JpdGhtIFN1aXRlIElkID0gMHgwMA0K Pj5OTFJJIExlbmd0aCA9IDB4NzAgKDExMiBiaXRzID0gMTQgYnl0ZXMpDQo+Pk5MUkkgUHJlZml4 ID0gMHgwMTAyMDMwNDA1MDYwNzA4MDkwYTBiMGMwZDBlDQo+Pg0KPj5Ob3RlIHRoYXQgdGhlIGZp cnN0IDE2IGJpdHMgb2YgNC4yJ3MgTW9zdCBSZWNlbnQgU2lnIEZpZWxkIGNhbid0IGJlIGFueQ0K Pj52YWx1ZXMuIFRoZSBmaXJzdCA4IGhhdmUgdG8gbWF0Y2ggdGhlIEFsZ29yaXRobSBTdWl0ZSBJ RCAoMSBwb3NzaWJsZQ0KPj52YWx1ZSkuIFRoZSBuZXh0IDggaGF2ZSB0byBiZSBhIHZhbGlkIG51 bWJlciBvZiBiaXRzIGZvciB0aGUgbnVtYmVyIG9mDQo+PmJ5dGVzIGluIHRoZSBwcmVmaXggKDgg cG9zc2libGUgdmFsdWVzKS4gVGhpcyBtZWFucyB0aGF0IHRoZXJlJ3Mgb25seSBhDQo+PjJeLTEz IGNoYW5jZSB0aGF0IGEgc2luZ2xlIHJhbmRvbSBNb3N0IFJlY2VudCBTaWcgRmllbGQgb2YgdGhl DQo+PmFwcHJvcHJpYXRlIGxlbmd0aCBjb3VsZCBiZSByZWludGVycHJldGVkIHN1Y2Nlc3NmdWxs eS4gSG93ZXZlciwgd2l0aA0KPj5tb3JlIHRoYW4gMl4xMyBzaWduYXR1cmVzIGZsb2F0aW5nIGFy b3VuZCB0aGUgSW50ZXJuZXQsIHRoYXQncyBub3QgZ29vZA0KPj5vZGRzLg0KPj4NCj4+LS0gDQo+ PkRhdmlkIEVyaWMgTWFuZGVsYmVyZyAvIGRzZW9tbg0KPj5odHRwOi8vZGF2aWQubWFuZGVsYmVy Zy5vcmcvDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+c2lkciBtYWlsaW5nIGxpc3QNCj5zaWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQoNCg== From nobody Sat Feb 14 08:36:45 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07A01A6F0E for ; Sat, 14 Feb 2015 08:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLkbeZCNAr8G for ; Sat, 14 Feb 2015 08:36:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A211A6F0D for ; Sat, 14 Feb 2015 08:36:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YMfhq-00011z-MZ; Sat, 14 Feb 2015 16:36:35 +0000 Date: Sun, 15 Feb 2015 01:36:32 +0900 Message-ID: From: Randy Bush To: Douglas Montgomery In-Reply-To: References: <54DA7C98.4040604@mandelberg.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list , David Mandelberg Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 16:36:41 -0000 > And even if we had not decoupled those two, just because you might > be authorized to announce 102::/16 to a peer, that is different than > saying that you actually announced it. point taken randy From nobody Sat Feb 14 11:54:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE5A1A0053 for ; Sat, 14 Feb 2015 11:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6Vkc7PwK8Hx for ; Sat, 14 Feb 2015 11:54:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5621A0016 for ; Sat, 14 Feb 2015 11:54:07 -0800 (PST) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by BL2PR09MB0161.namprd09.prod.outlook.com (10.255.233.147) with Microsoft SMTP Server (TLS) id 15.1.87.18; Sat, 14 Feb 2015 19:53:46 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0087.013; Sat, 14 Feb 2015 19:53:46 +0000 From: "Sriram, Kotikalapudi" To: Randy Bush , "Montgomery, Douglas" Thread-Topic: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQObnP/eFvHk0J6E2CzGstO0tmlJzjGf4AgAcb4iqAAE0vAIAE7aoAgAD+GgCAAAaAAIAAMwz4 Date: Sat, 14 Feb 2015 19:53:45 +0000 Message-ID: <1423943624118.34986@nist.gov> References: <54DA7C98.4040604@mandelberg.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.219.139] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB0161; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB0161; x-forefront-prvs: 0487C0DB7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76176999)(46102003)(50986999)(77156002)(102836002)(54356999)(66066001)(15975445007)(93886004)(62966003)(2900100001)(92566002)(230783001)(117636001)(86362001)(106116001)(40100003)(36756003)(122556002)(2950100001)(19580395003)(99286002)(87936001)(2656002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB0161; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2015 19:53:45.8828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB0161 Archived-At: Cc: David Mandelberg , sidr wg list Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 19:54:10 -0000 >> And even if we had not decoupled those two, just because you might=0A= >> be authorized to announce 102::/16 to a peer, that is different than=0A= >> saying that you actually announced it.=0A= >point taken=0A= >randy =0A= =0A= I agree that the solution should not merely rely on the presence of a valid= ating ROA.=0A= But there is some more detail here that is worth looking into. The path was= fully signed =0A= and assume all signatures are valid. Then clearly the origin AS actually an= nounced it.=0A= The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4) or= 102::/16 (v6)?=0A= The ROA has AFI information, but the signed update does not (currently).=0A= https://tools.ietf.org/html/rfc6482#section-3.3 =0A= =93Within the ROAIPAddressFamily structure, addressFamily contains the= =0A= Address Family Identifier (AFI) of an IP address family. This=0A= specification only supports IPv4 and IPv6. Therefore, addressFamily=0A= MUST be either 0001 or 0002.=94 =0A= =0A= Hence, as Keyur has surmised, there is a possibility that the ROA can help = resolve the ambiguity here.=0A= But the ambiguity would still persist if the same origin AS happens to have= ROA(s) for =0A= both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the probability is= extremely small).=0A= So, yes, a robust solution calls for something more than a validating ROA.= =0A= The ambiguity goes away if the AFI (of the announced prefix) is included by= the origin AS =0A= on the wire as well as in the sequence of octets that are signed.=0A= =0A= Sriram= From nobody Mon Feb 16 11:16:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175471A1AE7; Mon, 16 Feb 2015 11:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH0VbPLW4OYj; Mon, 16 Feb 2015 11:16:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E51A1AFA; Mon, 16 Feb 2015 11:16:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 11:16:09 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-delta-protocol-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:16:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Repository Delta Protocol Authors : Tim Bruijnzeels Oleg Muravskiy Bryan Weber Rob Austein David Mandelberg Filename : draft-ietf-sidr-delta-protocol-00.txt Pages : 18 Date : 2015-02-16 Abstract: In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 16 11:17:52 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F511A1BA4 for ; Mon, 16 Feb 2015 11:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIqMrnnWrLSy for ; Mon, 16 Feb 2015 11:17:46 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34F01A1AE7 for ; Mon, 16 Feb 2015 11:17:45 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 367EB28B0017; Mon, 16 Feb 2015 14:17:45 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 09E5D1F8035; Mon, 16 Feb 2015 14:17:45 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_62883F92-3A3C-4421-BF3B-B12626E53288"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 16 Feb 2015 14:17:52 -0500 References: <20150216170007.16692.37577.idtracker@ietfa.amsl.com> To: "sidr@ietf.org list" , Tim Bruijnzeels X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] Fwd: New draft waiting for approval: draft-ietf-sidr-delta-protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 19:17:48 -0000 --Apple-Mail=_62883F92-3A3C-4421-BF3B-B12626E53288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This was approved and I've already seen the announcement make it to the = list. --Sandy Begin forwarded message: > From: IETF I-D Submission Tool > Subject: New draft waiting for approval: = draft-ietf-sidr-delta-protocol > Date: February 16, 2015 12:00:07 PM EST > To: "Chris Morrow" , "Sandra Murphy" = >=20 >=20 > Hi, >=20 > Chair approval is needed for posting of = draft-ietf-sidr-delta-protocol-00. >=20 > To approve the draft, go to this URL (note: you need to login to be = able to approve): > = https://datatracker.ietf.org/submit/status/66706/e0a4b2bdec39e3eda5dfd9b77= ace1e8e/ >=20 > File name : draft-ietf-sidr-delta-protocol > Revision : 00 > Submission date : 2015-02-16 > Group : Secure Inter-Domain Routing >=20 > Title : RPKI Repository Delta Protocol > Document date : 2015-02-16 > Pages : 18 > File size : 45.1 KB >=20 > Submitter : Tim Bruijnzeels >=20 > Abstract : In the Resource Public Key Infrastructure = (RPKI), certificate > authorities publish certificates, including end entity certificates, > and CRLs to repositories on publication servers. Relying Parties > (RP) retrieve the published information from the repository and MAY > store it in a cache. This document specifies a delta protocol which > provides relying parties with a mechanism to query a repository for > changes, thus enabling the RP to keep its state in sync with the > repository. >=20 >=20 >=20 > Authors: > Tim Bruijnzeels > Oleg Muravskiy > Bryan Weber > Rob Austein > David Mandelberg >=20 >=20 >=20 >=20 > Best regards, >=20 > The IETF Secretariat > through the draft submission service --Apple-Mail=_62883F92-3A3C-4421-BF3B-B12626E53288 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU4kJhAAoJEHplpQeet0IZI+QP+gJ7CiYjnwPVYy/vVqqrcohS WvPn+9rP9bZSpPOa0IlKtQ1pd1rdkh8sMMYK55zaNvesp5vT3SG3CHI771NN8UZl CiUuQruz4ppa9Me6fcsy864X04AZmypzpdgZ79tU65+SDXegSaa52uBwEROXOZxJ 13mDnPc5olkX5oBZ2wCZtd0V7KsYjy+iEr5WVGgLqkt9q3wqEFct3NXXcj3bueoN zSFevwFfPXYkRUImWPUkzyG0lR5tWtd2kiUPzxHGszo3vaJpUpYW2hwxokTy2N1Q ErY9Uz6jJeXH9vmESXtZ5UMCUoD4IQl2FA/t7fH7eV7g9AEfHv8A93+MPQl31txs sTZa+Xf/o8jj7t529uSBUdq+xmodLOCfiRDAad7xVTC3C/e/OXjTPToEN1Uf0Jlh BpGlJl9dWLHfCl9mZlFdIn66em4QyRUHJq3jUp9HhTnrj8lqIwIV7jgMVLmFcXSq Dtw4jGV3jDGxuRm6tvL+vNB8cs0dvIP4FdjF9T6fMyXVEb7Js8DNsCqmetIb5u2f PzpAmplJ2zdzLGfmNtTeWLSov/dKnvcLgsuQ1M7xEGDJYeMdgNUUFL/xgzW6yXwh zDa/pgigiWLX2hVM12F5Z5ZVVqU2vATs9o9MyFI0JPswNp2RQCTWxnWBiU7F4WKd y12TKy83uclTd3yfIlKK =7VkZ -----END PGP SIGNATURE----- --Apple-Mail=_62883F92-3A3C-4421-BF3B-B12626E53288-- From nobody Tue Feb 17 09:54:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6101A8A3C for ; Tue, 17 Feb 2015 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10bujJf9jvoi for ; Tue, 17 Feb 2015 09:54:21 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD281A8967 for ; Tue, 17 Feb 2015 09:54:21 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YNmLh-0001ZJ-Aw for sidr@ietf.org; Tue, 17 Feb 2015 18:54:18 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::21]) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1YNmLh-0006AJ-6u; Tue, 17 Feb 2015 18:54:17 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Bruijnzeels In-Reply-To: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 18:54:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> References: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a3dc154ecd2c3d33da37ee675c7750fb Archived-At: Subject: [sidr] draft-ietf-sidr-delta-protocol-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 17:54:23 -0000 Hi all, Following working group adoption I submitted the latest version of the = delta protocol document as a working group item: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ Sriram, allow me to get back on previous comments you made during the = call for adoption: > When authors spin a WG draft version (assuming it would be accepted as = a WG draft), > it would be good if the following suggestions can be given = consideration: The current version is unchanged except for its name and number (00). = But of course we can give consideration to these and other suggestions = for a next version. > 1. Include one short paragraph just to discuss key disadvantages of = rsync and > how the delta protocol avoids or overcomes the same. I would like to avoid general discussion that may include opinions about = how severe perceived disadvantages of rsync are. Instead I would like to = focus on a more positive, and factual message, of what we are trying to = achieve with this protocol, and why. The last paragraph of the introduction has some text on this: This protocol is designed to be consistent with the publication protocol [I-D.ietf-sidr-publication] and treats publication events of one or more repository objects as immutable events that can be communicated to relying parties. This approach helps to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. This protocol also provides a standards based way to obtain consistent, point in time views of a single repository eliminating a number of consistency related issues. Finally, this approach allows for caching infrastructure to be used to serve this immutable data, and thus helps to reduce the load on a publication server when a large a number of relying parties are querying it. But admittedly this is incomplete and lacks explanation for why we = believe these are good things to have. I am happy to elaborate more on this here, and if it's useful to include = in the document itself we can add more text.. Design goals and benefits that I see (did not check everything with my = co-authors, so will not speak for them..): =3D Based on publication protocol Not the most important design goal, but useful because this way we do = not need to reinvent all of the data structure. We can re-use the = and elements that have already been defined. = Furthermore this may be easier for publication servers - they can re-use = update messages from Certification Authorities in update messages with = minimal effort. =3D Minimise data transfer We don't want to waste bits.. this is nothing against rsync, rsync is = actually very good at this. We just thought it would be good if we = didn't waste bits here either. =3D Point in time views This actually refers to a problem with rsync. Objects may be republished = mid-transfer and this can lead to things like getting a new CRL, but an = old manifest - and then the hash of the CRL doesn't match and the MFT EE = may be revoked. Clients can keep trying until they get something that = seems consistent, but.. if a Certification Server just sends all its = updates (CRL, MFT, ROAs etc) in one message to a publication server, = then all of this can be served as one delta and a lot of this goes away. =3D Caching infrastructure / CDNs (and immutable data) There are many different http caching servers that can be used to deal = with the load of serving static data to a large number of clients. There = are also many commercial Global Content Delivery Networks (CDNs) that = can be used to improve this further - that can operate for some time = even if the back-end system is unavailable, can spread the load further, = and reduce latency to globally distributed clients. Of course it is technically possible to build a CDN infrastructure with = rsync, using anycast or DNS tricks etc etc, but this is far from a = trivial effort. It's expensive to do, and easy to mess up, where the = http based CDNs and caching servers have had years of battle testing in = the internet industry. =3D Shift load to clients to support scaling Not mentioned yet in the introduction. There is an asymmetry between the number of clients (relying parties) = and servers. With rsync the server needs to invest effort (CPU and = memory) in a dialogue with the client in order to work out what the = actually delta is that the client needs. The proportion of this effort = spent by the server in this dialogue is a limiting factor on how many = clients can be served. Of course we can add more servers to counter this, but there is a lot = more gain to be had if we can minimise the effort that the server = actually has to invest. For this reason the protocol shifts almost all the (CPU) work to the = relying party. The server creates a notification file that refers to = static snapshot and possible delta files. The RP can work out what they = need to get all on their own. Serving this static data may still have bottlenecks with regards to = network usage and server memory, but this is where the http caching = servers and CDNs come in very helpful. =3D Only support what's needed / protocol stability Also not mentioned yet, but I remember hallway discussions where people = mentioned things like: versioning=85 why don't you just use git/svn? This seems overkill to me because these tools (like rsync) provide many = options that we don't need here. Also, which version of git/svn, or = rsync, are we talking about? I think it would be best to have the protocol stripped down to only the = bare essentials, and version it clearly. =3D Availability of open-source libraries for transport http There are numerous open source http libraries available to use for RP = software in every major programming language. Helps with performance (no = need to fork a process), testing, and it reduces the risk of the system = as a whole of pretty much relying on a single implementation. =3D Transport Protocol agnostic? Although the protocol clearly relies on http caching, it was a design = decision to repeat relevant data such as session ids, and versions, in = all files (rather than making this implicit in their location). The = reason is that this will make it easier to share these files using other = transport or sharing protocols. > 2. Possible to say something about the relevance of or comparison with > Aspera (since they make big performance improvement claims over rsync = etc.)?=20 > http://asperasoft.com/resources/benchmarks/ > http://asperasoft.com/performance-calculator/ This seems to be an option as a transport protocol, but not as a = complete delta protocol - i.e. helping the client figure out what to = get. This may be quicker than http, but I am not convinced mainly because = it's a proprietary service. We would depend on a single vendor to = support the transport protocol. From nobody Tue Feb 17 15:40:25 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B851A895D for ; Tue, 17 Feb 2015 15:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgCByHsuWe4r for ; Tue, 17 Feb 2015 15:40:16 -0800 (PST) Received: from nm22-vm6.access.bullet.mail.gq1.yahoo.com (nm22-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24661A8946 for ; Tue, 17 Feb 2015 15:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1424216415; bh=gaVO9KJLVbdopM9mnvdfnRFOcAPuId06cCb/IqVBPhY=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=Z52Uxs4KvUvEOtEgW8Weo3EYjJu+aOpe/7ojFneMNrDPVjsSGo9l5xMKwQoGws65dYejukLlNduFffFfrlrdKi0KZlP98GPDsPGrzl1MciPy0jGqDSGdTABh33DgnA3y91VocJklr3EvdWzVIwGZwql/l5OKAsj7NzbXiY0CXYyE31F14sTqdy99x4tD0k9kkLFAbfcjMhltKXx/ZJJ0A/81X1EjaQuMb8TUlbhr2mYnaRxoT9cdy21Pu8+i9pS4qbnTplWV0p3WusI8dHlfb7m7QrlfC6t4JYC0AVERco+YZ7LkkKdQZF+b0qcHKjK1wOHuWMP2cKpJGj34kohrPA== Received: from [216.39.60.173] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Feb 2015 23:40:15 -0000 Received: from [98.138.226.244] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Feb 2015 23:40:15 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 17 Feb 2015 23:40:15 -0000 X-Yahoo-Newman-Id: 548592.58966.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZfBcFlQVM1m4cfPf7KXhM4GIy7QajAyTSZf6UTE8P_2Znnl dVDc6wVTGQN3fybSC7jW4jVHml.NMDBS.vht7OyheilI8qgJF1ddJvrziEAn UMbDNHJb93mHDDtU15AvOZIgp0M.1CV5o92HyjAT4TyJur2YM_O3EqDUwXEx TjC501pnQU5xWWsNcb5gd4ZwCjWT4EREM42vGyORmMHuv6yHJuFxcSPNO0zE nsUzDkpzRMHIfI18h6pO2sXwPuurG1bIEprWnB1XZntRARxF2.b5IJgCyvlC WPv_aA.C8GlZ8a8e.nr0s22QKSZxLwnEYfJxy9ZqkPceTioyV8b_vbQsIN.U KjXqxb344SOx0kCv7OPxuTP4Y7xrvfHrKWTII.pKtpWsjqNo9HAyPTK5lyGQ MQdzCyJM1YKc18KBH09NoZLh_gW0kYQQx4iMEEb1PepCndJ9VzANrydpvDuH 30bkrkqYG0Xv82PevXuA3rNNjKn1Qq4GbgUQbVY1dZ3gIKZvgmOcJuT1X1Km ztcUkfDGmIk86N1nd21MkL_nN.zv7O0PgHNY5xt0N2hZL5cJkp5HdY8YVAZN jJ2oCWDIUNIhxOgX9SChIMBAljW9HNI_s4.imZ2rc8ZulwWwtZd_X4lQfTh6 QYetYnKDQWE68w1EU1iuiDRzxKDg3OwvEzBAZ8S_eR_yG1DONXeb80VVcDba okNzLBx4- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.12] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 3F9231C609A for ; Tue, 17 Feb 2015 18:40:14 -0500 (EST) Message-ID: <54E3D163.1040600@mandelberg.org> Date: Tue, 17 Feb 2015 18:40:19 -0500 From: David Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sidr@ietf.org References: <54DA7C98.4040604@mandelberg.org> , <1423943624118.34986@nist.gov> In-Reply-To: <1423943624118.34986@nist.gov> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mT0OQP9C6GPRWCRt6f8mJui0otAA235Ki" Archived-At: Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mT0OQP9C6GPRWCRt6f8mJui0otAA235Ki Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: > I agree that the solution should not merely rely on the presence of a v= alidating ROA. > But there is some more detail here that is worth looking into. The path= was fully signed=20 > and assume all signatures are valid. Then clearly the origin AS actuall= y announced it. > The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4= ) or 102::/16 (v6)? > The ROA has AFI information, but the signed update does not (currently)= =2E > https://tools.ietf.org/html/rfc6482#section-3.3 =20 > =93Within the ROAIPAddressFamily structure, addressFamily contains = the > Address Family Identifier (AFI) of an IP address family. This > specification only supports IPv4 and IPv6. Therefore, addressFamil= y > MUST be either 0001 or 0002.=94=20 >=20 > Hence, as Keyur has surmised, there is a possibility that the ROA can h= elp resolve the ambiguity here. > But the ambiguity would still persist if the same origin AS happens to = have ROA(s) for=20 > both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the probabilit= y is extremely small). > So, yes, a robust solution calls for something more than a validating R= OA. > The ambiguity goes away if the AFI (of the announced prefix) is include= d by the origin AS=20 > on the wire as well as in the sequence of octets that are signed. When there's no attack, I don't think there's any ambiguity about what NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs in the right places on the wire. The only change that I think needs to happen for this issue is including (S)AFIs in the data that's signed. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --mT0OQP9C6GPRWCRt6f8mJui0otAA235Ki Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTj0WMACgkQRKlmUHCg4sBHlgCeP2E39eNM5J9cye2ZFCI5y2Sq Xp8Ani0Ux9LwDNdr+PfADsF2nCwy/ROG =gVqI -----END PGP SIGNATURE----- --mT0OQP9C6GPRWCRt6f8mJui0otAA235Ki-- From nobody Wed Feb 18 14:07:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8AD1A1B63 for ; Wed, 18 Feb 2015 14:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whz6H8a15NNK for ; Wed, 18 Feb 2015 14:07:37 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E3E1A1B59 for ; Wed, 18 Feb 2015 14:07:23 -0800 (PST) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 22:07:09 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 22:07:09 +0000 From: "Sriram, Kotikalapudi" To: Tim Bruijnzeels , sidr wg list Thread-Topic: [sidr] draft-ietf-sidr-delta-protocol-00.txt Thread-Index: AQHQStrI3nQfGxuRtE+mo8IgAxcTRpz28o2w Date: Wed, 18 Feb 2015 22:07:09 +0000 Message-ID: References: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> In-Reply-To: <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] authentication-results: ripe.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(53754006)(99286002)(15395725005)(106116001)(76576001)(46102003)(122556002)(40100003)(62966003)(77156002)(19580395003)(19580405001)(54356999)(92566002)(230783001)(50986999)(76176999)(2656002)(87936001)(2950100001)(33656002)(15975445007)(107886001)(102836002)(2900100001)(74316001)(66066001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0302; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 22:07:09.2508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0302 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-delta-protocol-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 22:07:40 -0000 Tim, Thanks for your detailed responses to my comments/questions. To the extent possible (and if your coauthors agree), please include some o= f these=20 explanations in the document (intro section or wherever appropriate). You may, of course, post the more detailed discussion (as you've offered be= low)=20 on a website - that you might maintain going forward - devoted to the delta= protocol=20 where people can access FAQ, code download, etc. Sriram =20 -----Original Message----- From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Tim Bruijnzeels Sent: Tuesday, February 17, 2015 12:54 PM To: sidr wg list Subject: [sidr] draft-ietf-sidr-delta-protocol-00.txt Hi all, Following working group adoption I submitted the latest version of the delt= a protocol document as a working group item: > https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ Sriram, allow me to get back on previous comments you made during the call = for adoption: > When authors spin a WG draft version (assuming it would be accepted as=20 > a WG draft), it would be good if the following suggestions can be given c= onsideration: The current version is unchanged except for its name and number (00). But o= f course we can give consideration to these and other suggestions for a nex= t version. > 1. Include one short paragraph just to discuss key disadvantages of=20 > rsync and how the delta protocol avoids or overcomes the same. I would like to avoid general discussion that may include opinions about ho= w severe perceived disadvantages of rsync are. Instead I would like to focu= s on a more positive, and factual message, of what we are trying to achieve= with this protocol, and why. The last paragraph of the introduction has some text on this: This protocol is designed to be consistent with the publication protocol [I-D.ietf-sidr-publication] and treats publication events of one or more repository objects as immutable events that can be communicated to relying parties. This approach helps to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. This protocol also provides a standards based way to obtain consistent, point in time views of a single repository eliminating a number of consistency related issues. Finally, this approach allows for caching infrastructure to be used to serve this immutable data, and thus helps to reduce the load on a publication server when a large a number of relying parties are querying it. But admittedly this is incomplete and lacks explanation for why we believe = these are good things to have. I am happy to elaborate more on this here, and if it's useful to include in= the document itself we can add more text.. Design goals and benefits that I see (did not check everything with my co-a= uthors, so will not speak for them..): =3D Based on publication protocol Not the most important design goal, but useful because this way we do not n= eed to reinvent all of the data structure. We can re-use the and = elements that have already been defined. Furthermore this may be= easier for publication servers - they can re-use update messages from Cert= ification Authorities in update messages with minimal effort. =3D Minimise data transfer We don't want to waste bits.. this is nothing against rsync, rsync is actua= lly very good at this. We just thought it would be good if we didn't waste = bits here either. =3D Point in time views This actually refers to a problem with rsync. Objects may be republished mi= d-transfer and this can lead to things like getting a new CRL, but an old m= anifest - and then the hash of the CRL doesn't match and the MFT EE may be = revoked. Clients can keep trying until they get something that seems consis= tent, but.. if a Certification Server just sends all its updates (CRL, MFT,= ROAs etc) in one message to a publication server, then all of this can be = served as one delta and a lot of this goes away. =3D Caching infrastructure / CDNs (and immutable data) There are many different http caching servers that can be used to deal with= the load of serving static data to a large number of clients. There are al= so many commercial Global Content Delivery Networks (CDNs) that can be used= to improve this further - that can operate for some time even if the back-= end system is unavailable, can spread the load further, and reduce latency = to globally distributed clients. Of course it is technically possible to build a CDN infrastructure with rsy= nc, using anycast or DNS tricks etc etc, but this is far from a trivial eff= ort. It's expensive to do, and easy to mess up, where the http based CDNs a= nd caching servers have had years of battle testing in the internet industr= y. =3D Shift load to clients to support scaling Not mentioned yet in the introduction. There is an asymmetry between the number of clients (relying parties) and s= ervers. With rsync the server needs to invest effort (CPU and memory) in a = dialogue with the client in order to work out what the actually delta is th= at the client needs. The proportion of this effort spent by the server in t= his dialogue is a limiting factor on how many clients can be served. Of course we can add more servers to counter this, but there is a lot more = gain to be had if we can minimise the effort that the server actually has t= o invest. For this reason the protocol shifts almost all the (CPU) work to the relyin= g party. The server creates a notification file that refers to static snaps= hot and possible delta files. The RP can work out what they need to get all= on their own. Serving this static data may still have bottlenecks with regards to network= usage and server memory, but this is where the http caching servers and CD= Ns come in very helpful. =3D Only support what's needed / protocol stability Also not mentioned yet, but I remember hallway discussions where people men= tioned things like: versioning... why don't you just use git/svn? This seems overkill to me because these tools (like rsync) provide many opt= ions that we don't need here. Also, which version of git/svn, or rsync, are= we talking about? I think it would be best to have the protocol stripped down to only the bar= e essentials, and version it clearly. =3D Availability of open-source libraries for transport http There are numerous open source http libraries available to use for RP softw= are in every major programming language. Helps with performance (no need to= fork a process), testing, and it reduces the risk of the system as a whole= of pretty much relying on a single implementation. =3D Transport Protocol agnostic? Although the protocol clearly relies on http caching, it was a design decis= ion to repeat relevant data such as session ids, and versions, in all files= (rather than making this implicit in their location). The reason is that t= his will make it easier to share these files using other transport or shari= ng protocols. > 2. Possible to say something about the relevance of or comparison with=20 > Aspera (since they make big performance improvement claims over rsync etc= .)? > http://asperasoft.com/resources/benchmarks/ > http://asperasoft.com/performance-calculator/ This seems to be an option as a transport protocol, but not as a complete d= elta protocol - i.e. helping the client figure out what to get. This may be quicker than http, but I am not convinced mainly because it's a= proprietary service. We would depend on a single vendor to support the tra= nsport protocol. From nobody Mon Feb 23 14:09:23 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236D01A00B7 for ; Mon, 23 Feb 2015 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojb02SnqKEpJ for ; Mon, 23 Feb 2015 14:09:21 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA09D1A0027 for ; Mon, 23 Feb 2015 14:09:20 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2932828B0017; Mon, 23 Feb 2015 17:09:20 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0C69D1F8035; Mon, 23 Feb 2015 17:09:20 -0500 (EST) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2015 17:09:27 -0500 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] sidr meeting time IETF 92 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:09:22 -0000 The draft agenda is out and the sidr session is currently scheduled for: 0900-1130 CDT Monday Morning Session I Parisian RTG sidr Secure Inter-Domain Routing Be aware that agenda shifts are possible as conflicts are resolved. = This is a starting point. --Sandy, speaking for the co-chairs= From nobody Tue Feb 24 09:00:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974601A1B81 for ; Tue, 24 Feb 2015 09:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhgKjKaKK4hK for ; Tue, 24 Feb 2015 09:00:33 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989EE1A1B2A for ; Tue, 24 Feb 2015 09:00:29 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id EEC4128B004F; Tue, 24 Feb 2015 12:00:28 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E41231F8051; Tue, 24 Feb 2015 12:00:28 -0500 (EST) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2015 12:00:39 -0500 Message-Id: <42AF7715-5407-4ED7-BA06-2A090863E626@parsons.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] requests for an agenda slot X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:00:34 -0000 The sidr meeting is about five weeks away. It is time to start setting = the agenda. Please send your request to the working group and chairs if you have a = topic you wish to present at the IETF 92 Dallas meeting. --Sandy, speaking as one of the co-chairs= From nobody Tue Feb 24 09:38:16 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF981A8765 for ; Tue, 24 Feb 2015 09:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT8ZVQtuberE for ; Tue, 24 Feb 2015 09:38:08 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F401A8766 for ; Tue, 24 Feb 2015 09:38:08 -0800 (PST) Received: by mail-oi0-f44.google.com with SMTP id a3so20596799oib.3 for ; Tue, 24 Feb 2015 09:38:07 -0800 (PST) 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=RzJwUD3iRo2IdpC6939iRzxHDWsuY/AjKVPNUEyweDI=; b=kH8Ewm62YKz8a8AjuAM7l/vbuMsBnxsK/3b5rlDW7YhTzfa8D0YMVVjIVfgzIDVRdv JUEFeZnsx9yChh2mlpqki7QZMEZsMSVCHH2g/yn7JU37/N3/um4wf7qJUUEvlgXEY8ui 2W+Azs/lq5kQ0bPI6AIOUxyrZ2dAPRJH0hsM6b2Wsy5DhBEHcl4HitJb3dt9LFbxthzH OEMgX8SN4NYZ5DlLZ5dIhyWvc9fifsmTCrqWuSNr1XJYYkIQmb8NvnE7rXMTR92QNvpK MIpUp+mi8NKLksXRzSp2Dr+dQTO1FElsAlwqPVs99cu66lkzAaxkrt5hAJyGcjRtJpjB oB8w== MIME-Version: 1.0 X-Received: by 10.202.51.137 with SMTP id z131mr11302314oiz.10.1424799487394; Tue, 24 Feb 2015 09:38:07 -0800 (PST) Received: by 10.202.135.17 with HTTP; Tue, 24 Feb 2015 09:38:07 -0800 (PST) In-Reply-To: <54E3D163.1040600@mandelberg.org> References: <54DA7C98.4040604@mandelberg.org> <1423943624118.34986@nist.gov> <54E3D163.1040600@mandelberg.org> Date: Tue, 24 Feb 2015 12:38:07 -0500 Message-ID: From: Matthew Lepinski To: David Mandelberg Content-Type: multipart/alternative; boundary=001a113cd3da528979050fd8fbef Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:38:14 -0000 --001a113cd3da528979050fd8fbef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in the process of resolving issues in the bgpsec-protocol document in order to get out a new version before Dallas. Based on the discussion in this thread, I believe the best way forward is: 1) Add a small amount of security considerations text to address the original concern that David raised. (I believe the consensus is that this concern cannot be converted into an actual attack. However, other readers might reasonably have the same concern as David and so there is no harm laying the concern to rest in security considerations.) 2) Given that origin validation is now decoupled from path validation, we will put the AFI under the BGPsec signature to avoid potential IPv4 vs IPv6 issues. Any objections to this resolution of these issues? - Matt Lepinski On Tue, Feb 17, 2015 at 6:40 PM, David Mandelberg wrote: > On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: > > I agree that the solution should not merely rely on the presence of a > validating ROA. > > But there is some more detail here that is worth looking into. The path > was fully signed > > and assume all signatures are valid. Then clearly the origin AS actuall= y > announced it. > > The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 > (v4) or 102::/16 (v6)? > > The ROA has AFI information, but the signed update does not (currently)= . > > https://tools.ietf.org/html/rfc6482#section-3.3 > > =E2=80=9CWithin the ROAIPAddressFamily structure, addressFamily con= tains the > > Address Family Identifier (AFI) of an IP address family. This > > specification only supports IPv4 and IPv6. Therefore, addressFamil= y > > MUST be either 0001 or 0002.=E2=80=9D > > > > Hence, as Keyur has surmised, there is a possibility that the ROA can > help resolve the ambiguity here. > > But the ambiguity would still persist if the same origin AS happens to > have ROA(s) for > > both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the > probability is extremely small). > > So, yes, a robust solution calls for something more than a validating > ROA. > > The ambiguity goes away if the AFI (of the announced prefix) is include= d > by the origin AS > > on the wire as well as in the sequence of octets that are signed. > > When there's no attack, I don't think there's any ambiguity about what > NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs > in the right places on the wire. The only change that I think needs to > happen for this issue is including (S)AFIs in the data that's signed. > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > --001a113cd3da528979050fd8fbef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in the process of resolving issues in the bgpsec-prot= ocol document in order to get out a new version before Dallas.=C2=A0
Based on the discussion in this thread, I believe the best way= forward is:
1) Add a small amount of security considerations tex= t to address the original concern that David raised. (I believe the consens= us is that this concern cannot be converted into an actual attack. However,= other readers might reasonably have the same concern as David and so there= is no harm laying the concern to rest in security considerations.)

2) Given that origin validation is now decoupled from pat= h validation, we will put the AFI under the BGPsec signature to avoid poten= tial IPv4 vs IPv6 issues.=C2=A0

Any objections to = this resolution of these issues?

- Matt Lepinski= =C2=A0

On Tue, Feb 17, 2015 at 6:40 PM, David Mandelberg <david@mandelberg.or= g> wrote:
= On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote:
> I agree that the solution should not merely rely on the presence of a = validating ROA.
> But there is some more detail here that is worth looking into. The pat= h was fully signed
> and assume all signatures are valid. Then clearly the origin AS actual= ly announced it.
> The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 (v4) or 102::/16 (v6)? > The ROA has AFI information, but the signed update does not (currently= ).
>=C2=A0 https://tools.ietf.org/html/rfc6482#section-3.3
>=C2=A0 =C2=A0 =C2=A0=E2=80=9CWithin the ROAIPAddressFamily structure, a= ddressFamily contains the
>=C2=A0 =C2=A0 =C2=A0Address Family Identifier (AFI) of an IP address fa= mily.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0specification only supports IPv4 and IPv6.=C2=A0 Th= erefore, addressFamily
>=C2=A0 =C2=A0 =C2=A0MUST be either 0001 or 0002.=E2=80=9D
>
> Hence, as Keyur has surmised, there is a possibility that the ROA can = help resolve the ambiguity here.
> But the ambiguity would still persist if the same origin AS happens to= have ROA(s) for
> both prefixes 1.2.0.0/= 16 (v4) and 102::/16 (v6)=C2=A0 (though the probability is extremely sm= all).
> So, yes, a robust solution calls for something more than a validating = ROA.
> The ambiguity goes away if the AFI (of the announced prefix) is includ= ed by the origin AS
> on the wire as well as in the sequence of octets that are signed.

When there's no attack, I don't think there's any ambigu= ity about what
NLRI is being announced or withdrawn. RFC4760 seems to include (S)AFIs
in the right places on the wire. The only change that I think needs to
happen for this issue is including (S)AFIs in the data that's signed.

--
David Eric Mandelberg / dseomn
http://david.man= delberg.org/


_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr


--001a113cd3da528979050fd8fbef-- From nobody Wed Feb 25 16:13:35 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817431A6F27; Wed, 25 Feb 2015 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISvn7vUyD_dX; Wed, 25 Feb 2015 16:13:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5662D1A6FE7; Wed, 25 Feb 2015 16:13:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226001331.30542.27304.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 16:13:31 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-publication-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 00:13:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Publication Protocol for the Resource Public Key Infrastructure (RPKI) Authors : Samuel Weiler Anuja Sonalker Rob Austein Filename : draft-ietf-sidr-publication-06.txt Pages : 14 Date : 2015-02-25 Abstract: This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-publication-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-publication-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 25 16:27:48 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637001A6FCF for ; Wed, 25 Feb 2015 16:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9-9bDIuZ1FD for ; Wed, 25 Feb 2015 16:27:46 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158CD1A1A46 for ; Wed, 25 Feb 2015 16:27:46 -0800 (PST) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0ACB937E7 for ; Thu, 26 Feb 2015 00:27:43 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2A3D51644A5B for ; Wed, 25 Feb 2015 19:27:47 -0500 (EST) Date: Wed, 25 Feb 2015 19:27:47 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20150226001331.30542.27304.idtracker@ietfa.amsl.com> References: <20150226001331.30542.27304.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20150226002747.2A3D51644A5B@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 00:27:47 -0000 Update to an old WG draft, adding a few features that we found we needed while developing RRDP (draft-ietf-sidr-delta-protocol). See the draft and diff for details, but the quick summary of changes is: - Added the PDU, and - Added "hash" attribute to the and PDUs. NB: I discussed these changes with my co-authors something like six months ago, but various distractions kept us from publishing an updated draft, and my co-authors have not seen the new text yet. Blame me for any errors, not them. From nobody Thu Feb 26 09:50:03 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256241A1B15 for ; Thu, 26 Feb 2015 09:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amTu-0xWXTpM for ; Thu, 26 Feb 2015 09:50:00 -0800 (PST) Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C11A040B for ; Thu, 26 Feb 2015 09:50:00 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 1B620395D3A; Thu, 26 Feb 2015 09:50:00 -0800 (PST) From: Michael Baer To: Matthew Lepinski References: <54DA7C98.4040604@mandelberg.org> <1423943624118.34986@nist.gov> <54E3D163.1040600@mandelberg.org> X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: (Matthew Lepinski's message of "Tue, 24 Feb 2015 12:38:07 -0500") Message-ID: <87ioeor29k.fsf@rebma.mikesoffice.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:50:02 -0000 I do not have any objection to the resolutions below, but I did notice something else while looking at the NLRI processing for BGPsec. For prefixes that do not end on octet boundary, the value of the trailing bits between the end of the prefix and the octet boundary are undefined. Both RFC 4271 p20 and the multiprotocol RFC 4760 p7 use the same language, "Note that the value of trailing bits is irrelevant." I was unable to find text in another RFC or within the protocol draft that explicitly sets these bits. If any of those bits get changed from what the originator signed, the signature will be invalid even though the NLRI is otherwise valid according to the RFCs. Practically speaking, these bits likely get set to zero by most (all?) routers anyway. But it would probably be good to have text in the protocol document explicitly setting them when creating signatures. Something like, "Any trailing bits in the NLRI prefix between the prefix length and the next octet boundary are set to zero when calculating the signatures." -Mike >>>>> On Tue, 24 Feb 2015 12:38:07 -0500, Matthew Lepinski said: ML> I am in the process of resolving issues in the bgpsec-protocol docu= ment in ML> order to get out a new version before Dallas. ML> Based on the discussion in this thread, I believe the best way forw= ard is: ML> 1) Add a small amount of security considerations text to address the ML> original concern that David raised. (I believe the consensus is tha= t this ML> concern cannot be converted into an actual attack. However, other r= eaders ML> might reasonably have the same concern as David and so there is no = harm ML> laying the concern to rest in security considerations.) ML> 2) Given that origin validation is now decoupled from path validati= on, we ML> will put the AFI under the BGPsec signature to avoid potential IPv4= vs IPv6 ML> issues. ML> Any objections to this resolution of these issues? ML> - Matt Lepinski ML> On Tue, Feb 17, 2015 at 6:40 PM, David Mandelberg ML> wrote: >> On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: >> > I agree that the solution should not merely rely on the presence o= f a >> validating ROA. >> > But there is some more detail here that is worth looking into. The= path >> was fully signed >> > and assume all signatures are valid. Then clearly the origin AS ac= tually >> announced it. >> > The question or ambiguity is: Did the origin AS announce 1.2.0.0/16 >> (v4) or 102::/16 (v6)? >> > The ROA has AFI information, but the signed update does not (curre= ntly). >> > https://tools.ietf.org/html/rfc6482#section-3.3 >> > =E2=80=9CWithin the ROAIPAddressFamily structure, addressFamil= y contains the >> > Address Family Identifier (AFI) of an IP address family. This >> > specification only supports IPv4 and IPv6. Therefore, address= Family >> > MUST be either 0001 or 0002.=E2=80=9D >> > >> > Hence, as Keyur has surmised, there is a possibility that the ROA = can >> help resolve the ambiguity here. >> > But the ambiguity would still persist if the same origin AS happen= s to >> have ROA(s) for >> > both prefixes 1.2.0.0/16 (v4) and 102::/16 (v6) (though the >> probability is extremely small). >> > So, yes, a robust solution calls for something more than a validat= ing >> ROA. >> > The ambiguity goes away if the AFI (of the announced prefix) is in= cluded >> by the origin AS >> > on the wire as well as in the sequence of octets that are signed. >>=20 >> When there's no attack, I don't think there's any ambiguity about wh= at >> NLRI is being announced or withdrawn. RFC4760 seems to include (S)AF= Is >> in the right places on the wire. The only change that I think needs = to >> happen for this issue is including (S)AFIs in the data that's signed. >>=20 >> -- >> David Eric Mandelberg / dseomn >> http://david.mandelberg.org/ >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >>=20 ML> _______________________________________________ ML> sidr mailing list ML> sidr@ietf.org ML> https://www.ietf.org/mailman/listinfo/sidr --=20 Michael Baer baerm@tislabs.com Senior Software Engineer Parsons Global Shared Services, Cyber Security Division C: 530.902.3131