From rogaglia@cisco.com Mon Mar 5 13:44:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317621F88BC for ; Mon, 5 Mar 2012 13:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.912 X-Spam-Level: X-Spam-Status: No, score=-8.912 tagged_above=-999 required=5 tests=[AWL=1.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+7M66BHKy3g for ; Mon, 5 Mar 2012 13:44:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92E21F8880 for ; Mon, 5 Mar 2012 13:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=11676; q=dns/txt; s=iport; t=1330983858; x=1332193458; h=from:to:subject:date:message-id:references:mime-version; bh=Y5/dtxGha+xiMNFrCXp8Nzl2/5LPwMttemxLptSgkow=; b=gZv06HTkOGeDpfp62qH8OgXrjkBzvYKog63KnHmqT83XkL9NrwdIJ25u PFjdvw+Up0+84wFSX9/3mvlx9UeGPKZayYtd4kBVuaa9wtK5YiidJKZJe 3GyGAU/qN5I/awFWxDel1N2XKj3xEPPaWkRSCYn22lZliTYcmZ4mzBYKx c=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMsyVU+tJV2d/2dsb2JhbABDtGeBB4F9AQEBAwESAWQHCwIBGQMBAi8CMBsCCAIEEw4Uh2AFmVkBnnSPbGMEjlKBH4VNkBKCYw X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="p7s'?scan'208,217";a="63975385" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2012 21:44:17 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q25LiHNa009242 for ; Mon, 5 Mar 2012 21:44:17 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Mon, 5 Mar 2012 13:44:17 -0800 From: "Roque Gagliano (rogaglia)" To: "sidr@ietf.org" Thread-Topic: New Version Notification for draft-rogaglia-sidr-bgpsec-rollover-00.txt Thread-Index: AQHM+xgwmA040KtAlUyoPB0clZuHIA== Date: Mon, 5 Mar 2012 21:44:16 +0000 Message-ID: <2E9F178A-0DB5-4BC1-AD5A-35D1FB5AF371@cisco.com> References: <20120305213738.16864.95151.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18756.000 x-tm-as-result: No--34.112900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-100-489334589"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [sidr] Fwd: New Version Notification for draft-rogaglia-sidr-bgpsec-rollover-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:44:19 -0000 --Apple-Mail-100-489334589 Content-Type: multipart/alternative; boundary=Apple-Mail-99-489330987 --Apple-Mail-99-489330987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear SIDR WG, We published this -00 draft to document a possible process to perform = key rollovers on a BGPSEC router certificate and discuss the use of = rollovers as an alternative to beaconing. We are planning to present the proposal in Paris and we welcome = comments. Regards, Roque Begin forwarded message: > From: > Date: March 5, 2012 10:37:38 PM GMT+01:00 > To: > Cc: , > Subject: New Version Notification for = draft-rogaglia-sidr-bgpsec-rollover-00.txt >=20 > A new version of I-D, draft-rogaglia-sidr-bgpsec-rollover-00.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >=20 > Filename: draft-rogaglia-sidr-bgpsec-rollover > Revision: 00 > Title: BGPSEC router key roll-over as an alternative = to beaconing > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 13 >=20 > Abstract: > The current BGPSEC draft documents do not specifies a key roll-over > process for routers. This document describes a possible key roll- > over process and explores its impact to mitigate replay attacks and > eliminate the need for beaconing in BGPSEC. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-99-489330987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = SIDR WG,

We published this -00 draft to document a = possible process to perform key rollovers on a BGPSEC router certificate = and discuss the use of rollovers as an alternative to = beaconing.

We are planning to present the = proposal in Paris and we welcome = comments.

Regards,
Roque

Begin forwarded message:

Date: March 5, 2012 10:37:38 PM = GMT+01:00
To: <rogaglia@cisco.com>
Subject: New Version = Notification for = draft-rogaglia-sidr-bgpsec-rollover-00.txt

A = new version of I-D, draft-rogaglia-sidr-bgpsec-rollover-00.txt has been = successfully submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-rogaglia-sidr-bgpsec-rollover
Revision: = 00
Title: = = BGPSEC router key roll-over as an alternative to = beaconing
Creation date: 2012-03-05
WG ID: = Individual Submission
Number of pages: 13

Abstract:
=   The current BGPSEC draft documents do not specifies a key = roll-over
  process for routers.  This document = describes a possible key roll-
  over process and explores = its impact to mitigate replay attacks and
  eliminate the = need for beaconing in BGPSEC.




The IETF = Secretariat

= --Apple-Mail-99-489330987-- --Apple-Mail-100-489334589 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MDUyMTQ0MTNaMCMGCSqGSIb3DQEJBDEWBBQoQej7tUQUKmmOCPy2lZEXgHJ6zzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQAMYa/MgkNS3ta7fj/SblWi6bjl3krb7Uj3PW66JAI1JrmC 8tStGpvbwEJ4EzuW41q/WiQ8sHozoWwWbhXsMGwcq3uv0MtfN0xvNgY+72pzbnFrEVTewK9cN6u3 HrOVwRkynhKRJUi7dXf+/BcKT64G9zaxT63eBJWwnJe4MKOxbNUmEPAf6lqdbo0f2qwzyrU/qOvD WI5M/NyemZJasJHbrTdpYGhFrD84t7WvZvbdaX9LmPVEJnaAf6ffqXJ2kdtRFEnIoyZvov3I9O84 5xEN7vO3eeeQeoydAoiJArsfDqwKmQCGP38TTTbCt+D/VWH6J6RrKQ7HmIn8X9+SXSbKAAAAAAAA --Apple-Mail-100-489334589-- From brian.peter.dickson@gmail.com Mon Mar 5 16:31:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E08C21E8028 for ; Mon, 5 Mar 2012 16:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGkcJsh-c+XN for ; Mon, 5 Mar 2012 16:31:24 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55EAD21E8017 for ; Mon, 5 Mar 2012 16:31:24 -0800 (PST) Received: by werb10 with SMTP id b10so3564967wer.31 for ; Mon, 05 Mar 2012 16:31:23 -0800 (PST) Received-SPF: pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.93 as permitted sender) client-ip=10.216.133.93; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.93 as permitted sender) smtp.mail=brian.peter.dickson@gmail.com; dkim=pass header.i=brian.peter.dickson@gmail.com Received: from mr.google.com ([10.216.133.93]) by 10.216.133.93 with SMTP id p71mr7240800wei.10.1330993883590 (num_hops = 1); Mon, 05 Mar 2012 16:31:23 -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 :content-type; bh=UgEC6YNAL8LMc1WCUfeylNBoJYM2vdqyNYMHIoKfUwg=; b=WM1pmaJ1KzicxEIaT98NGxc4f/rqHbTCGng3x9YabNpp7kIZ/VJpWzxQa44k4syHum Zs5CvJltfA/uqrSzCdjoLI5uIUnh1StuLWKgPc2aMsRKMbQPHl/tM3pPQK/zAn/MfEYC Y2N2ta9/FFdGLnkQgXjKoE2OrnzT8I5xKOG3lmgfTOrg4jRjbj26SuztLjod9M9tXNrf GY41pPQ0SKzDwb+BIsWdTFGkT7+bakAxv4op4tofT4zDRLTUcn+dQjssnXafjbBYxpoF Sbu1TXa4EANF1GnjDtqpVwWCh3mzNqZeN9pnd8VMosHpBe3KfVdw8K2Kq+EGDlNxxlbA JhUA== MIME-Version: 1.0 Received: by 10.216.133.93 with SMTP id p71mr5778333wei.10.1330993883458; Mon, 05 Mar 2012 16:31:23 -0800 (PST) Received: by 10.223.69.3 with HTTP; Mon, 5 Mar 2012 16:31:23 -0800 (PST) In-Reply-To: <20120305180943.16641.16867.idtracker@ietfa.amsl.com> References: <20120305180943.16641.16867.idtracker@ietfa.amsl.com> Date: Mon, 5 Mar 2012 19:31:23 -0500 Message-ID: From: Brian Dickson To: sidr wg list Content-Type: multipart/alternative; boundary=0016e6dbde579f2d0c04ba88291d Subject: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-def-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:31:25 -0000 --0016e6dbde579f2d0c04ba88291d Content-Type: text/plain; charset=ISO-8859-1 Greetings, SIDR folks. Here is the first of three IDs, concerning the definitions of "route leak". Comments and feedback are encouraged. Two sibling documents are also up (requirements and solutions), look for similar messages in a minute. Brian Dickson ---------- Forwarded message ---------- From: Date: Mon, Mar 5, 2012 at 1:09 PM Subject: New Version Notification for draft-dickson-sidr-route-leak-def-01.txt To: brian.peter.dickson@gmail.com A new version of I-D, draft-dickson-sidr-route-leak-def-01.txt has been successfully submitted by Brian Dickson and posted to the IETF repository. Filename: draft-dickson-sidr-route-leak-def Revision: 01 Title: Route Leaks -- Definitions Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 9 Abstract: The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate analysis of what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". The IETF Secretariat --0016e6dbde579f2d0c04ba88291d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings, SIDR folks.

Here is the first of three IDs, concerning th= e definitions of "route leak".

Comments and feedback are e= ncouraged.

Two sibling documents are also up (requirements and solut= ions), look for similar messages in a minute.

Brian Dickson

---------- Forwarded me= ssage ----------
From: <internet-drafts@ietf.or= g>
Date: Mon, Mar 5, 2012 at 1:09 PM
Subject: New Version Notification for = draft-dickson-sidr-route-leak-def-01.txt
To: brian.peter.dickson@gmail.com


A new ve= rsion of I-D, draft-dickson-sidr-route-leak-def-01.txt has been successfull= y submitted by Brian Dickson and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dickson-sidr-route-leak-def
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Route Leaks -- Definitions
Creation date: =A0 2012-03-05
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9

Abstract:
=A0 The Border Gateway Protocol, version 4, (BGP4) provides the means to =A0 advertise reachability for IP prefixes. =A0This reachability
=A0 information is propagated in a peer-to-peer topology. =A0Sometimes
=A0 routes are announced to peers for which the local peering policy does<= br> =A0 not permit. =A0And sometimes routes are propagated indiscriminantly, =A0 once they have been accepted.

=A0 This document considers the situations that can lead to routes being =A0 leaked, and tries to find acceptable definitions for describing these<= br> =A0 scenarios.

=A0 The purpose of these definitions is to facilitate analysis of what a =A0 route leak is, and what the scope of the problem space for route
=A0 leaks is.

=A0 This, in turn, is intended to inform a requirements document for
=A0 detection of (and prevention of) route leaks. =A0And finally, the
=A0 definitions and requirements are intended to allow proposed solutions<= br> =A0 which meet these criteria, and to facilitate evaluation of proposed =A0 solutions.

=A0 The fundamental objective is to &quot;solve the route leaks proble= m&quot;.




The IETF Secretariat

--0016e6dbde579f2d0c04ba88291d-- From brian.peter.dickson@gmail.com Mon Mar 5 16:32:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB121E8036 for ; Mon, 5 Mar 2012 16:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItZMjlZmPkfW for ; Mon, 5 Mar 2012 16:32:27 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDAA821E8017 for ; Mon, 5 Mar 2012 16:32:26 -0800 (PST) Received: by werb10 with SMTP id b10so3565366wer.31 for ; Mon, 05 Mar 2012 16:32:26 -0800 (PST) Received-SPF: pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.134.39 as permitted sender) client-ip=10.216.134.39; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.134.39 as permitted sender) smtp.mail=brian.peter.dickson@gmail.com; dkim=pass header.i=brian.peter.dickson@gmail.com Received: from mr.google.com ([10.216.134.39]) by 10.216.134.39 with SMTP id r39mr7223487wei.26.1330993946053 (num_hops = 1); Mon, 05 Mar 2012 16:32:26 -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 :content-type; bh=9iS9SjnzhWxK2bsPlV+fswWPc57Der+zAuz1qkQd8lk=; b=XYB7WMt0+aFHAyx8CzOZHvCl9n+YqzhilrXt5sLRCv7aDYzVk/yjXG5Ug1d/EJKVQG fDxOa0eAp/H8W3Oz8kAmGcEEznEzEOglMOnddmc+I5b+msyhTCga54DI94Lk9GH6p8md ws+fqJ+yAJ7DmRKX0+UohCKgRewgwFLN5kS6SC7DI4IAJ8jukmZSqv2QwaqkoxAGri3U 850bIHGmi84w0JCufNZdU0X8t3PnK5mGLohYQ3K0g6DFeGB9RB9p62BUl+l1cD2EJbAh MmhXmHjK9efe7hwvMyg3TTlHDe34WiU8UbREi8JSVVXcVefjABOnPpnUNvd67uHhJ9Rn 2LAQ== MIME-Version: 1.0 Received: by 10.216.134.39 with SMTP id r39mr5807928wei.26.1330993945949; Mon, 05 Mar 2012 16:32:25 -0800 (PST) Received: by 10.223.69.3 with HTTP; Mon, 5 Mar 2012 16:32:25 -0800 (PST) In-Reply-To: <20120306002849.8209.942.idtracker@ietfa.amsl.com> References: <20120306002849.8209.942.idtracker@ietfa.amsl.com> Date: Mon, 5 Mar 2012 19:32:25 -0500 Message-ID: From: Brian Dickson To: sidr wg list Content-Type: multipart/alternative; boundary=0016e6d77f0f58b70b04ba882d31 Subject: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:32:27 -0000 --0016e6d77f0f58b70b04ba882d31 Content-Type: text/plain; charset=ISO-8859-1 Greetings, SIDR folks, Here is the notice on the ID for the route leak "requirements" document. Comments and feedback are welcomed. Brian ---------- Forwarded message ---------- From: Date: Mon, Mar 5, 2012 at 7:28 PM Subject: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt To: brian.peter.dickson@gmail.com A new version of I-D, draft-dickson-sidr-route-leak-reqts-02.txt has been successfully submitted by Brian Dickson and posted to the IETF repository. Filename: draft-dickson-sidr-route-leak-reqts Revision: 02 Title: Route Leaks -- Requirements for Detection and Prevention thereof Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 8 Abstract: The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document is a requirements document for detection of (and prevention of) route leaks. Together with the definitions document, it is intended to suggest solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". The IETF Secretariat --0016e6d77f0f58b70b04ba882d31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings, SIDR folks,

Here is the notice on the ID for the route le= ak "requirements" document.

Comments and feedback are welc= omed.

Brian

---------- Forwarded m= essage ----------
From: <internet-drafts@ietf.org>
= Date: Mon, Mar 5, 2012 at 7:28 PM
Subject: New Version Notification for = draft-dickson-sidr-route-leak-reqts-02.txt
To: brian.peter.dickson@gm= ail.com


A new version of I-D, draft-dickson-sidr-route-leak-= reqts-02.txt has been successfully submitted by Brian Dickson and posted to= the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dickson-sidr-route-leak-reqts
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Route Leaks -- Requirements for Detection and Pr= evention thereof
Creation date: =A0 2012-03-06
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8

Abstract:
=A0 The Border Gateway Protocol, version 4, (BGP4) provides the means to =A0 advertise reachability for IP prefixes. =A0This reachability
=A0 information is propagated in a peer-to-peer topology. =A0Sometimes
=A0 routes are announced to peers for which the local peering policy does<= br> =A0 not permit. =A0And sometimes routes are propagated indiscriminantly, =A0 once they have been accepted.

=A0 This document is a requirements document for detection of (and
=A0 prevention of) route leaks.

=A0 Together with the definitions document, it is intended to suggest
=A0 solutions which meet these criteria, and to facilitate evaluation of =A0 proposed solutions.

=A0 The fundamental objective is to &quot;solve the route leaks proble= m&quot;.




The IETF Secretariat

--0016e6d77f0f58b70b04ba882d31-- From brian.peter.dickson@gmail.com Mon Mar 5 16:33:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5860621E8028 for ; Mon, 5 Mar 2012 16:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5mn571mQPs4 for ; Mon, 5 Mar 2012 16:33:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBC121E8017 for ; Mon, 5 Mar 2012 16:33:55 -0800 (PST) Received: by werb10 with SMTP id b10so3565880wer.31 for ; Mon, 05 Mar 2012 16:33:54 -0800 (PST) Received-SPF: pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.93 as permitted sender) client-ip=10.216.133.93; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.93 as permitted sender) smtp.mail=brian.peter.dickson@gmail.com; dkim=pass header.i=brian.peter.dickson@gmail.com Received: from mr.google.com ([10.216.133.93]) by 10.216.133.93 with SMTP id p71mr7243466wei.10.1330994034483 (num_hops = 1); Mon, 05 Mar 2012 16:33:54 -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 :content-type; bh=VRzI1nm+xU8C1CvBpX3uJ82VuD3xPGzQn69Qc3paqDg=; b=j0BbyYrOCtp1hfU7SVnA9VmBBSQj5YTaRP8LGag9TUS545VjnTdMuCv+xkbynEYLMB MLYf64G/Pq1DO42m+L0omK1PIQzdcveQox3sRs5pXVKIOWUTtI6hFCC6NU6eYddoxcEK PbFBXG97E3EjyEeGhdSRZhLs2PJPt2VO5qcRDCM3rQFURoRXmEmnnApJViU3TYhs/cCF 5Ibjp8tmCMZdJDIE3qMTLZmqS2REsCk76eytzir6bbA3+lqmd1cQvNPr0WIO085eT7Mq wI3omiHdV4C3rf2xCyeRaTHkXd4lqaacKUou8DWd/zdW7T4eovjkY2k2lvKnjFuVDriM QxJg== MIME-Version: 1.0 Received: by 10.216.133.93 with SMTP id p71mr5780503wei.10.1330994034424; Mon, 05 Mar 2012 16:33:54 -0800 (PST) Received: by 10.223.69.3 with HTTP; Mon, 5 Mar 2012 16:33:54 -0800 (PST) In-Reply-To: <20120306002335.7199.52176.idtracker@ietfa.amsl.com> References: <20120306002335.7199.52176.idtracker@ietfa.amsl.com> Date: Mon, 5 Mar 2012 19:33:54 -0500 Message-ID: From: Brian Dickson To: sidr wg list Content-Type: multipart/alternative; boundary=0016e6dbde579ebb8904ba88329e Subject: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-solns-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:33:56 -0000 --0016e6dbde579ebb8904ba88329e Content-Type: text/plain; charset=ISO-8859-1 Greetings, SIDR folk, Here is the "route leak solutions" ID, which builds on the two sibling documents (and depends on them heavily). I encourage anyone interested in the route leak problem, to read them in order: def, reqts, solns. Questions, comments, and other feedback are encouraged. Thanks, Brian ---------- Forwarded message ---------- From: Date: Mon, Mar 5, 2012 at 7:23 PM Subject: New Version Notification for draft-dickson-sidr-route-leak-solns-01.txt To: brian.peter.dickson@gmail.com A new version of I-D, draft-dickson-sidr-route-leak-solns-01.txt has been successfully submitted by Brian Dickson and posted to the IETF repository. Filename: draft-dickson-sidr-route-leak-solns Revision: 01 Title: Route Leaks -- Proposed Solutions Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 7 Abstract: The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate discussion on what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". The IETF Secretariat --0016e6dbde579ebb8904ba88329e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings, SIDR folk,

Here is the "route leak solutions" I= D, which builds on the two sibling documents (and depends on them heavily).=

I encourage anyone interested in the route leak problem, to read th= em in order: def, reqts, solns.

Questions, comments, and other feedback are encouraged.

Thanks,<= br>Brian

---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Mon, Mar 5, 2012 at 7:23 PM
Subject: New Version Notification for = draft-dickson-sidr-route-leak-solns-01.txt
To: brian.peter.dickson@gmail.com


A new = version of I-D, draft-dickson-sidr-route-leak-solns-01.txt has been success= fully submitted by Brian Dickson and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dickson-sidr-route-leak-solns
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Route Leaks -- Proposed Solutions
Creation date: =A0 2012-03-06
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7

Abstract:
=A0 The Border Gateway Protocol, version 4, (BGP4) provides the means to =A0 advertise reachability for IP prefixes. =A0This reachability
=A0 information is propagated in a peer-to-peer topology. =A0Sometimes
=A0 routes are announced to peers for which the local peering policy does<= br> =A0 not permit. =A0And sometimes routes are propagated indiscriminantly, =A0 once they have been accepted.

=A0 This document considers the situations that can lead to routes being =A0 leaked, and tries to find acceptable definitions for describing these<= br> =A0 scenarios.

=A0 The purpose of these definitions is to facilitate discussion on what =A0 a route leak is, and what the scope of the problem space for route
=A0 leaks is. =A0This, in turn, is intended to inform a requirements
=A0 document for detection of (and prevention of) route leaks. =A0And
=A0 finally, the definitions and requirements are intended to allow
=A0 proposed solutions which meet these criteria, and to facilitate
=A0 evaluation of proposed solutions.

=A0 The fundamental objective is to &quot;solve the route leaks proble= m&quot;.




The IETF Secretariat

--0016e6dbde579ebb8904ba88329e-- From randy@psg.com Mon Mar 5 17:54:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF621E8019 for ; Mon, 5 Mar 2012 17:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k1P-vQ-EEQ8 for ; Mon, 5 Mar 2012 17:54:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A09DA21E8018 for ; Mon, 5 Mar 2012 17:54:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S4jbT-000IBs-Qy for sidr@ietf.org; Tue, 06 Mar 2012 01:54:15 +0000 Date: Tue, 06 Mar 2012 10:54:15 +0900 Message-ID: From: Randy Bush To: sidr wg list References: <20120306014427.30681.28993.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:54:17 -0000 chairs, please consider as a wg work item. thanks. randy --- From: internet-drafts@ietf.org Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes= sfully submitted by Sean Turner and posted to the IETF repository. Filename: draft-ymbk-bgpsec-rtr-rekeying Revision: 00 Title: Router Keying for BGPsec Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 7 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. From jmh@joelhalpern.com Tue Mar 6 06:11:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2F21F879C for ; Tue, 6 Mar 2012 06:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-nd9sKw+OIZ for ; Tue, 6 Mar 2012 06:11:32 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AA21F879A for ; Tue, 6 Mar 2012 06:11:32 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id A6619CD083 for ; Tue, 6 Mar 2012 06:11:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 67FF91C084B for ; Tue, 6 Mar 2012 06:11:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EEB3C1C079A for ; Tue, 6 Mar 2012 06:11:29 -0800 (PST) Message-ID: <4F561B18.4040208@joelhalpern.com> Date: Tue, 06 Mar 2012 09:11:36 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr wg list References: <20120306014427.30681.28993.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:11:32 -0000 I wonder if this may have broader applicability than just SIDR. Given the current environment and needs, SIDR seems the right place to deal with it, and it definitely seems worth taking forward. Yours, Joel On 3/5/2012 8:54 PM, Randy Bush wrote: > chairs, please consider as a wg work item. thanks. > > randy > > --- > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt > > A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes= > sfully submitted by Sean Turner and posted to the IETF repository. > > Filename: draft-ymbk-bgpsec-rtr-rekeying > Revision: 00 > Title: Router Keying for BGPsec > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 7 > > Abstract: > BGPsec-speaking routers must be provisioned with private keys and the > corresponding public key must be published in the global Resource > PKI. This document describes two ways of doing so, router-driven and > operator-driven. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rogaglia@cisco.com Tue Mar 6 09:01:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCDF21F866C for ; Tue, 6 Mar 2012 09:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox1PV9EtmT4k for ; Tue, 6 Mar 2012 09:01:11 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 273AB21F8678 for ; Tue, 6 Mar 2012 09:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=16156; q=dns/txt; s=iport; t=1331053271; x=1332262871; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8PXecl2md8Krn6tbuIoQw6jUHICanoZsnOZ1iuBYdg4=; b=M8n1TPqHjpq8dIh6nyGDPbk3U7UXdlgmi447piIns9wYxLRwIC4SjKTz AAUbbvi8Xwf3PEh5qYFTHe5TzFEcrreXJoEhxwzKP0OfG9GH2ON6YiIQo iiQgNL90DTdrlBe7tAh0Gs4oUR/LVsNWgXbqC73X9wwXXUgvHbWMPnnFW w=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwAAP9BVk+rRDoI/2dsb2JhbABDoxmRX4EHgX0BAQEDAQEBAQ8BWwkCEAIBCBEDAQEBLwIlCxwBCAIEAQ0FDhSHYAQBC6BrAZcrBI97YwSOVIEfhUyQFoJj X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="p7s'?scan'208,217";a="34675010" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 17:01:05 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26H15Oo017101; Tue, 6 Mar 2012 17:01:05 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Tue, 6 Mar 2012 09:01:05 -0800 From: "Roque Gagliano (rogaglia)" To: "Murphy, Sandra" , Christopher Morrow Thread-Topic: [sidr] FW: Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt Thread-Index: AQHM8YLCM6W56Y0mW06lJSEw7q5I0ZZeGHyA Date: Tue, 6 Mar 2012 17:01:04 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60370E2@Hermes.columbia.ads.sparta.com> <5E7BDC05-9B1D-4578-86E3-D1A49D73F031@cisco.com> In-Reply-To: <5E7BDC05-9B1D-4578-86E3-D1A49D73F031@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18756.003 x-tm-as-result: No--47.086700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-35-558745121"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] FW: Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:01:12 -0000 --Apple-Mail-35-558745121 Content-Type: multipart/alternative; boundary=Apple-Mail-34-558739155 --Apple-Mail-34-558739155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG Chairs, Could you please help us stating the current status of this document? = We believe the latest version (-05) incorporated all the changes that = were agreed on the list.=20 Regards, Roque >=20 > Begin forwarded message: >=20 >> From: "Murphy, Sandra" >> Date: December 8, 2011 11:50:52 PM GMT+01:00 >> To: "sidr@ietf.org" >> Subject: [sidr] FW: Fwd: New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt >>=20 >> Dear WG, >>=20 >> Roque mentions below that the authors believe that all comments have = been addressed. >>=20 >> It would help the process and the chairs if those of you who made = comments say whether you believe that your comments have been adequately = or acceptably addressed. >>=20 >> ----Sandy, speaking as wg chair >>=20 >>=20 >>=20 >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Roque Gagliano [rogaglia@cisco.com] >>=20 >> Sent: Tuesday, November 29, 2011 12:14 PM >>=20 >> To: sidr wg list >>=20 >> Subject: [sidr] Fwd: New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Dear WG,=20 >>=20 >>=20 >>=20 >> We just submitted a new version of the agility draft, where we = believe we addressed all the comments during WGLC. >>=20 >>=20 >>=20 >> Particularly: >> - Decoupling the documents to be updated in two, one signaling the = algorithms and another one (BCP) with the specific dates. >> - Adding a roll-over mechanism for the process. >> - Several text improvements and editorial nits >>=20 >>=20 >>=20 >> Regards, >> Roque >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>=20 >>=20 >> From: internet-drafts@ietf.org >>=20 >>=20 >>=20 >> Date: November 29, 2011 6:10:26 PM GMT+01:00 >>=20 >>=20 >>=20 >> To: rogaglia@cisco.com >>=20 >>=20 >>=20 >> Cc: turners@ieca.com, >>=20 >> rogaglia@cisco.com,=20 >> kent@bbn.com >>=20 >>=20 >>=20 >> Subject: New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt >>=20 >>=20 >>=20 >>=20 >> A new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >>=20 >>=20 >>=20 >> Filename: draft-ietf-sidr-algorithm-agility >>=20 >> Revision: 04 >>=20 >> Title: Algorithm Agility Procedure for RPKI. >>=20 >> Creation date: 2011-11-29 >>=20 >> WG ID: sidr >>=20 >> Number of pages: 29 >>=20 >>=20 >>=20 >> Abstract: >>=20 >> This document specifies the process that Certification Authorities >>=20 >> (CAs) and Relying Parties (RP) participating in the Resource Public >>=20 >> Key Infrastructure (RPKI) will need to follow to transition to a new >>=20 >> (and probably cryptographically stronger) algorithm set. The = process >>=20 >> is expected to be completed in a time scale of months or years. >>=20 >> Consequently, no emergency transition is specified. The transition >>=20 >> procedure defined in this document supports only a top-down = migration >>=20 >> (parent migrates before children). >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 > >> _______________________________________________ >> 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 >=20 --Apple-Mail-34-558739155 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi WG = Chairs,

Could you please help us stating the current = status of this document?  We believe the latest version (-05) = incorporated all the changes that were agreed on the = list. 

Regards,
Roque


Begin forwarded = message:

From: "Murphy, Sandra" <Sandra.Murphy@sparta.com><= br>
Date: December 8, 2011 11:50:52 PM = GMT+01:00
Subject: [sidr] FW: Fwd: = New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt

Dear= WG,

Roque mentions below that the authors believe that all = comments have been addressed.

It would help the process and the = chairs if those of you who made comments say whether you believe that = your comments have been adequately or acceptably = addressed.

----Sandy, speaking as wg chair



From: = sidr-bounces@ietf.org = [sidr-bounces@ietf.org] on behalf of Roque Gagliano = [rogaglia@cisco.com]

Sent: Tuesday, November 29, 2011 12:14 = PM

To: sidr wg list

Subject: [sidr] Fwd: New Version = Notification for = draft-ietf-sidr-algorithm-agility-04.txt






Dear = WG,



We just submitted a new version of the agility = draft, where we believe we addressed all the comments during = WGLC.



Particularly:
- Decoupling the documents to be = updated in two, one signaling the algorithms and another one (BCP) with = the specific dates.
- Adding a roll-over mechanism for the = process.
- Several text improvements and editorial = nits



Regards,
Roque







Begin= forwarded message:



From: internet-drafts@ietf.org
<= br>

Date: November 29, 2011 6:10:26 PM = GMT+01:00



To: rogaglia@cisco.com



C= c: turners@ieca.com,

rogaglia@cisco.com,
kent@bbn.com



Subject: = New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt




A new = version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has been = successfully submitted by Roque Gagliano and posted to the IETF = repository.



Filename: = draft-ietf-sidr-algorithm-agility

Revision: 04

Title: = Algorithm Agility Procedure for RPKI.

Creation date: = 2011-11-29

WG ID: sidr

Number of pages: = 29



Abstract:

 This document specifies the = process that Certification Authorities

 (CAs) and Relying = Parties (RP) participating in the Resource Public

 Key = Infrastructure (RPKI) will need to follow to transition to a new

=  (and probably cryptographically stronger) algorithm set.  The = process

 is expected to be completed in a time scale of = months or years.

 Consequently, no emergency transition is = specified.  The transition

 procedure defined in this = document supports only a top-down migration

 (parent = migrates before children).









The = IETF = Secretariat









<smime.p7s>
_______________________________________________
sidr= mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr
_______________________________________________
= sidr mailing = list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr


= = --Apple-Mail-34-558739155-- --Apple-Mail-35-558745121 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MDYxNzAxMDNaMCMGCSqGSIb3DQEJBDEWBBT5fO3vvDjPYz8xDmg/vWt6GQTAKjCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBakZQbm9pF4lChZilfbC516vxWqZNcw8vDNc7L+mXa2aZP Y1Zy8oz6zpNcYXaZihEUikTRlrJLn/STbsU6RUcpKdldRRSpT4Pthgt+1rmwdrM0K2pBqEZXmU3V nCa6kg+UfeV0CUI9lQ1tEuNxHjBGLF8DLvGu45uYh+/xZdKttRf/Oky/nSPWeB0GLr4THX1Un/lD uZ0yqqcD1BCvVKr619VM1mApEHeo3mPaKucJQOEJGsPq+zgVnqPM5S+1qp8umu0x94FXw5YWzkEs 0+F3vowdkoBfH7wo6SH6KxZ3poqpgf9X+VVHepN7v1PhBVTezEE3WRMwqCymVVA9+kVsAAAAAAAA --Apple-Mail-35-558745121-- From Sandra.Murphy@sparta.com Wed Mar 7 14:40:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDF811E80C0 for ; Wed, 7 Mar 2012 14:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t96yXhshZSDn for ; Wed, 7 Mar 2012 14:40:28 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9726211E8074 for ; Wed, 7 Mar 2012 14:40:28 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q27MeRD1028021 for ; Wed, 7 Mar 2012 16:40:27 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q27MeRYC030700 for ; Wed, 7 Mar 2012 16:40:27 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 17:40:26 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt Thread-Index: AQHM/LNB9YzpszfnIE2Lt1kJ+kpDSg== Date: Wed, 7 Mar 2012 22:40:25 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:40:29 -0000 The following request has been made for wg adoption of draft-ymbk-bgpsec-rt= r-rekeying-00.txt. The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-im= pl-01. Please respond to the list to say whether you accept this draft as a workin= g group draft and are willing to work on it. Remember that you do not need = to accept all content in a draft to adopt, as draft editors are required to= reflect the consensus of the working group. This call will end 21 Mar 2012. --Sandy, speaking as wg co-chair ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy Bush= [randy@psg.com] Sent: Monday, March 05, 2012 8:54 PM To: sidr wg list Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt chairs, please consider as a wg work item. thanks. randy --- From: internet-drafts@ietf.org Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes= =3D sfully submitted by Sean Turner and posted to the IETF repository. Filename: draft-ymbk-bgpsec-rtr-rekeying Revision: 00 Title: Router Keying for BGPsec Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 7 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr= From Sandra.Murphy@sparta.com Wed Mar 7 14:52:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED71911E80AE for ; Wed, 7 Mar 2012 14:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJG4Dko16kUP for ; Wed, 7 Mar 2012 14:52:58 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8011E808F for ; Wed, 7 Mar 2012 14:52:56 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q27Mqu6x028114 for ; Wed, 7 Mar 2012 16:52:56 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q27MqtOh031006 for ; Wed, 7 Mar 2012 16:52:55 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 17:52:55 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: Invitation to Web seminar: Virtual meeting - Mar 2012 Thread-Index: AQHM/K7uFjs06m8ZKEGKrQ/DscVgvZZfbi9G Date: Wed, 7 Mar 2012 22:52:54 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4@Hermes.columbia.ads.sparta.com> References: <2123587110.18271331158152285.JavaMail.nobody@grsj2rmd005.webex.com> In-Reply-To: <2123587110.18271331158152285.JavaMail.nobody@grsj2rmd005.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/mixed; boundary="_002_24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4Hermescolumbiaa_" MIME-Version: 1.0 Subject: [sidr] FW: Invitation to Web seminar: Virtual meeting - Mar 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:52:59 -0000 --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4Hermescolumbiaa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The co-chairs have arranged a virtual meeting for Mar 24, 2012. As per process, an agenda will be announced by one week before the event. This is scheduled for a full day - we will use this experience to gauge fut= ure meetings. --Sandy, speaking as wg co-chair From: messenger@webex.com [messenger@webex.com] Subject: Invitation to Web seminar: Virtual meeting - Mar 2012 =20 Hello, Secure Inter-Domain Routing Working Group invites you to attend a Web semin= ar using WebEx. Topic: Virtual meeting - Mar 2012 Host: Secure Inter-Domain Routing Working Group Date and Time: Saturday, March 24, 2012 8:00 am, GMT Time (London, GMT) Event number: 648 807 999 Event password: VIRTUAL ------------------------------------------------------- To join the online event ------------------------------------------------------- 1. Click here to join the online event. Or copy and paste the following link to a browser:=20 https://ietf.webex.com/ietf/onstage/g.php?d=3D648807999&t=3Da&EA=3Dsandra.m= urphy%40sparta.com&ET=3D49da78014cc5d3aacc1a55e34a2cff7d&ETR=3D75b14f07e621= faef30fd3542aeaa8773&RT=3DMiMxMQ=3D=3D&p 2. Click "Join Now". ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code: 648 807 999 ------------------------------------------------------- For assistance ------------------------------------------------------- You can contact Secure Inter-Domain Routing Working Group at: sidr-chairs@tools.ietf.org The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/onstage/systemdiagnosis.php=20 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation.=20 = --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4Hermescolumbiaa_ Content-Type: application/octet-stream; name="Virtual meeting - Mar 2012.ics" Content-Description: Virtual meeting - Mar 2012.ics Content-Disposition: attachment; filename="Virtual meeting - Mar 2012.ics"; size=3181; creation-date="Wed, 07 Mar 2012 22:09:13 GMT"; modification-date="Wed, 07 Mar 2012 22:09:13 GMT" Content-ID: <72D6A15D3B450A4C88AD8122D4E6F540@ads.sparta.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpQYWNpZmljIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEwMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA3MDAKVFpPRkZTRVRUTzotMDgwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEwMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDgw MApUWk9GRlNFVFRPOi0wNzAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJTYW5kcmEgTXVycGh5 IjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOnNhbmRyYS5tdXJwaHlAc3Bh cnRhLmNvbQpPUkdBTklaRVI7Q049IlNlY3VyZSBJbnRlci1Eb21haW4gUm91dGluZyBXb3JraW5n IEdyb3VwIjpNQUlMVE86c2lkci1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcKRFRTVEFSVDtUWklEPSJQ YWNpZmljIFRpbWUiOjIwMTIwMzI0VDAxMDAwMApEVEVORDtUWklEPSJQYWNpZmljIFRpbWUiOjIw MTIwMzI0VDEwMDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvb25zdGFn ZS9nLnBocD9kPTY0ODgwNzk5OSZ0PWEgClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MApVSUQ6V0VC RVgtTUVFVElORyBDRU5URVItNi4wNDU2NjgwLTE1MDkyOTYzNwpEVFNUQU1QOjIwMTIwMzA3VDIy MDkwOVoKREVTQ1JJUFRJT046SGVsbG8gU2FuZHJhIE11cnBoeSxcblxuU2VjdXJlIEludGVyLURv bWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gYXR0ZW5kIGEgV2ViIHNl bWluYXIgdXNpbmcgV2ViRXguXG5cblRvcGljOiBWaXJ0dWFsIG1lZXRpbmcgLSBNYXIgMjAxMlxu SG9zdDogU2VjdXJlIEludGVyLURvbWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXBcbkRhdGUgYW5k IFRpbWU6XG5TYXR1cmRheSwgTWFyY2ggMjQsIDIwMTIgODowMCBhbSwgR01UIFRpbWUgKExvbmRv biwgR01UKVxuU2F0dXJkYXksIE1hcmNoIDI0LCAyMDEyIDE6MDAgYW0sIFBhY2lmaWMgRGF5bGln aHQgVGltZSAoU2FuIEZyYW5jaXNjbywgR01ULTA3OjAwKVxuU2F0dXJkYXksIE1hcmNoIDI0LCAy MDEyIDQ6MDAgYW0sIEVhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMClc blNhdHVyZGF5LCBNYXJjaCAyNCwgMjAxMiA5OjAwIGFtLCBFdXJvcGUgVGltZSAoUGFyaXMsIEdN VCswMTowMClcbkV2ZW50IG51bWJlcjogNjQ4IDgwNyA5OTlcbkV2ZW50IHBhc3N3b3JkOiBWSVJU VUFMXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS1cblRvIGpvaW4gdGhlIG9ubGluZSBldmVudFxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuMS4gR28gdG8gaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL29uc3RhZ2UvZy5waHA/ZD02NDg4MDc5OTkmdD1hJkVBPXNhbmRyYS5tdXJw aHklNDBzcGFydGEuY29tJkVUPTQ5ZGE3ODAxNGNjNWQzYWFjYzFhNTVlMzRhMmNmZjdkJkVUUj03 NWIxNGYwN2U2MjFmYWVmMzBmZDM1NDJhZWFhODc3MyZSVD1NaU14TVE9PSZwXG4yLiBDbGljayAi Sm9pbiBOb3ciLlxuXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1cblRvIGpvaW4gdGhlIHRlbGVjb25mZXJlbmNlIG9ubHlcbi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbkNhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk6ICsxLTQwOC02MDAtMzYwMFxuQWNjZXNzIGNvZGU6IDY0 OCA4MDcgOTk5XG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS1cbkZvciBhc3Npc3RhbmNlXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5Zb3UgY2FuIGNvbnRhY3QgU2VjdXJlIEludGVy LURvbWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgYXQ6XG5zaWRyLWNoYWlyc0B0b29scy5pZXRm Lm9yZ1xuXG5UaGUgcGxheWJhY2sgb2YgVUNGIChVbml2ZXJzYWwgQ29tbXVuaWNhdGlvbnMgRm9y bWF0KSByaWNoIG1lZGlhIGZpbGVzIHJlcXVpcmVzIGFwcHJvcHJpYXRlIHBsYXllcnMuIFRvIHZp ZXcgdGhpcyB0eXBlIG9mIHJpY2ggbWVkaWEgZmlsZXMgaW4gdGhlIG1lZXRpbmcsIHBsZWFzZSBj aGVjayB3aGV0aGVyIHlvdSBoYXZlIHRoZSBwbGF5ZXJzIGluc3RhbGxlZCBvbiB5b3VyIGNvbXB1 dGVyIGJ5IGdvaW5nIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9vbnN0YWdlL3N5c3Rl bWRpYWdub3Npcy5waHBcblxuXG5cblxuXG5odHRwOi8vd3d3LndlYmV4LmNvbVxuXG5JTVBPUlRB TlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxs b3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2Vk IG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcg dGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5n cy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91ciBj b25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSBy ZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55 IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50 IG9mIGxpdGlnYXRpb24uIFxuClNVTU1BUlk6VmlydHVhbCBtZWV0aW5nIC0gTWFyIDIwMTIKUFJJ T1JJVFk6NQpDTEFTUzpQVUJMSUMKRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4Hermescolumbiaa_-- From Sandra.Murphy@sparta.com Wed Mar 7 15:07:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4453E11E8074 for ; Wed, 7 Mar 2012 15:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2q-1k37uZuy for ; Wed, 7 Mar 2012 15:07:58 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9B11E8088 for ; Wed, 7 Mar 2012 15:07:58 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q27N7vSO028247 for ; Wed, 7 Mar 2012 17:07:57 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q27N7vVo031439 for ; Wed, 7 Mar 2012 17:07:57 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 18:07:52 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt Thread-Index: AQHM/LNB9YzpszfnIE2Lt1kJ+kpDSpZfdC9C Date: Wed, 7 Mar 2012 23:07:51 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:07:59 -0000 An alert eye pointed out that the URL below is incorrect. The correct poin= ter is http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 --Sandy, speaking as clumsy wg co-chair ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com] Sent: Wednesday, March 07, 2012 5:40 PM To: sidr@ietf.org Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt The following request has been made for wg adoption of draft-ymbk-bgpsec-rt= r-rekeying-00.txt. The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-im= pl-01. Please respond to the list to say whether you accept this draft as a workin= g group draft and are willing to work on it. Remember that you do not need = to accept all content in a draft to adopt, as draft editors are required to= reflect the consensus of the working group. This call will end 21 Mar 2012. --Sandy, speaking as wg co-chair ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy Bush= [randy@psg.com] Sent: Monday, March 05, 2012 8:54 PM To: sidr wg list Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt chairs, please consider as a wg work item. thanks. randy --- From: internet-drafts@ietf.org Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes= =3D sfully submitted by Sean Turner and posted to the IETF repository. Filename: draft-ymbk-bgpsec-rtr-rekeying Revision: 00 Title: Router Keying for BGPsec Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 7 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. _______________________________________________ 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= From internet-drafts@ietf.org Wed Mar 7 22:35:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7621F84A6; Wed, 7 Mar 2012 22:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6dy55aiDa3X; Wed, 7 Mar 2012 22:35:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B650121F85EA; Wed, 7 Mar 2012 22:34:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308063437.4682.3362.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 22:34:37 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:35:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-14.txt Pages : 10 Date : 2012-03-07 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-14.txt From randy@psg.com Wed Mar 7 22:57:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F021E8024 for ; Wed, 7 Mar 2012 22:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzCuxs-y8Oe9 for ; Wed, 7 Mar 2012 22:57:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8449221E8017 for ; Wed, 7 Mar 2012 22:57:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5XIL-0000Do-L5 for sidr@ietf.org; Thu, 08 Mar 2012 06:57:50 +0000 Date: Thu, 08 Mar 2012 15:57:48 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20120308063437.4682.3362.idtracker@ietfa.amsl.com> References: <20120308063437.4682.3362.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-origin-ops-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:57:51 -0000 quite willing to address constructive comments before monday's dreadline randy From internet-drafts@ietf.org Wed Mar 7 23:57:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D294F21F863B; Wed, 7 Mar 2012 23:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojdhxAaO2Fhz; Wed, 7 Mar 2012 23:57:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2521F8629; Wed, 7 Mar 2012 23:57:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308075759.17980.26248.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2012 23:57:59 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:58:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPsec Operational Considerations Author(s) : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-02.txt Pages : 8 Date : 2012-03-07 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-02.txt From randy@psg.com Thu Mar 8 00:00:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD29321F866D for ; Thu, 8 Mar 2012 00:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YB+Z+laU0zN for ; Thu, 8 Mar 2012 00:00:36 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7D421F865E for ; Thu, 8 Mar 2012 00:00:36 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5YH5-0000Ni-NO for sidr@ietf.org; Thu, 08 Mar 2012 08:00:35 +0000 Date: Thu, 08 Mar 2012 17:00:34 +0900 Message-ID: From: Randy Bush To: sidr@ietf.org In-Reply-To: <20120308075759.17980.26248.idtracker@ietfa.amsl.com> References: <20120308075759.17980.26248.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:00:37 -0000 constructive comments before dreadline solicited as a wise early review said: Overall this doc seems like a good start but it doesn't actually tell me how to configure my router and has more "mights" and "on the other hands" than I'd prefer to see in a BCP. Maybe I am asking for too much given that this is a protocol that has yet to see the light of day. And maybe I should step back and ask what your goal is -- I'm operating under the assumption that a network operator should be able to read this and find if not a cookbook, at least some solid guidelines for how to configure their network. I don't yet see that. (I do see the caveat that "[the doc] is expected to evolve" and maybe that's all that's needed.) it's a hard balance between a firm warning and letting the operator do as they will, even if it means shooting themselves in the foot. randy From Sandra.Murphy@sparta.com Thu Mar 8 05:50:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DBB21F866B for ; Thu, 8 Mar 2012 05:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srJ+22YFRl8u for ; Thu, 8 Mar 2012 05:50:46 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3282521F8516 for ; Thu, 8 Mar 2012 05:50:46 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q28DojrK031492 for ; Thu, 8 Mar 2012 07:50:45 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q28Doi8k009764 for ; Thu, 8 Mar 2012 07:50:45 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 08:50:44 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt Thread-Index: AczX0k8MBLEob/ovShO+j20oxVDgwAFOoY2QCAkxadE= Date: Thu, 8 Mar 2012 13:50:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C10BA@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F6077032@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6077032@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:50:47 -0000 The wg adoption call ended as scheduled and the wg supported adoption. The= response was notable (for this wg) for its enthusiasm. The authors should submit draft-ietf-sidr-rpki-rtr-impl-00.txt as soon as p= ossible. Despite having sent a reminder to everyone else of the call for adoption, I= neglected to note on the list that the draft was adopted. That meant that= the authors missed the opportunity to submit the draft-ietf-sidr-xxx versi= on of the draft before the -00 deadline. My abject apologies to the author= s. --Sandy, speaking as wg co-chairs ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com] Sent: Friday, January 27, 2012 11:04 AM To: sidr@ietf.org Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt A suggestion was made at the last wg call, that reminders should be sent ou= t for approaching deadlines. You are hereby reminded that there is an active wg call for adoption, which= ends a week from today. --Sandy, speaking as wg co-chair > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Friday, January 20, 2012 7:19 PM > To: sidr@ietf.org > Subject: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt > > The working group has been requested to adopt draft-ymbk-rpki-rtr-impl- > 01.txt as a working group draft. > > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr- > impl. > > Please respond to the list to say whether you accept this draft as a > working group draft and are willing to work on it. Remember that you do > not need to accept all content in a draft to adopt, as draft editors are > required to reflect the consensus of the working group. > > This call will end 3 Feb 2012. > > --Sandy, speaking as wg co-chair > > > > > _______________________________________________ > 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= From randy@psg.com Thu Mar 8 22:50:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7BB21F8608 for ; Thu, 8 Mar 2012 22:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7i4-+69jjkV for ; Thu, 8 Mar 2012 22:50:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7521F8606 for ; Thu, 8 Mar 2012 22:50:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5tek-0003Vp-S8 for sidr@ietf.org; Fri, 09 Mar 2012 06:50:27 +0000 Date: Fri, 09 Mar 2012 15:50:25 +0900 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (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 Subject: [sidr] defending at layer seven against layer nine attacks X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 06:50:29 -0000 yesterday, a few friends asked if someone files in court against your customer and gets a judgment telling the rir to revoke your bgp-speaking customer's certs and roas[0], what the heck happens to your responsibility and/or sla to your customer? what can you do to keep them flying? i believe this is a legitimate concern. one classic example is a russian isp being attacked by a dutch court. of course it could be a canadian being attacked by a virginia court. note that, traditionally, the sla describes a level of service between you and your customer, and its all best effort to the rest of the intertubes. first, the rirs, no matter how well-meaning, can do nothing to help, any thought thereof is a joke. they will not stand up to court orders and people with guns, end of story. and the same goes for well-intentioned schemes where arin backs up ripe's members' rpki data. american (dns) registries have already been used, through us courts, to attack overseas sites. but, note that the decisions routers make are not burned in. by design, they are local policy configured by the operator. rpki- based origin validation merely marks a received bgp announcement as valid, notfound, or invalid. it is up to operator-configured policy to decide how to treat the received announcement based on the validity marking and anything else the operator chooses. so we will use local knowledge of who your customers are to make a local policy decision that you're going to route them no matter what some third party says about them. let's assume you have a prefix filter list for my customer's prefixes (the customer themself, not their bgp speaking customer cone). you do have prefix lists for your customers, don't you [1]? so, your programatically generated template for a customer peering could be something such as the following pretty strict policy: if p in custs-pfxs community add ExportToPeersCustsAndUpstreams if p is marked valid set local-pref 120 elif p is marked notfound set local-pref 100 elif p is marked invalid # layer nine attack set local-pref 120 # maintain g-r fantasy an even more paranoid approach might begin if p in custs-pfxs if p comes from or through an as not my customer's drop it on the floor ... as you surely have customer specific prefix filters in place, you do not risk allowing in invalid attacks sourced by your customer. that this is all supported in the design and in current code from J&C is not an accident. but beware of occasional vendor do-gooder knobs which default to applying policy for you. also check out draft-ietf-sidr-ltamgmt. it explains how to use the rpki tools and tool-sets (i.e. nothing new needed) to have your own view of the world, overriding the iana/rir-based rpki data. this view could include copies of your customers' rpki data. it would also be really helpful to have a seventh registry of good reputation situated in a much less vulnerable jurisdiction, e.g. iceland. we could all use the ltamgt hack to use them as a safety net. otoh, i would also hope that the goons at layers 8-10 would realize that a lot of attacks against the rpki would jeopardize everyone's, including their own, routing security as folk will start to shy away from using it. --- [0] - or forces the rir to create a roa for as 0 [1] - you can always construct one from the rpki data, all the roas with the customer's as. if they did not register, then all this makes no difference, their prefixes are always notfound. From robert@raszuk.net Thu Mar 8 23:19:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE83D21F8658 for ; Thu, 8 Mar 2012 23:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0QmFPOdExTd for ; Thu, 8 Mar 2012 23:19:50 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A8FAB21F855F for ; Thu, 8 Mar 2012 23:19:49 -0800 (PST) Received: (qmail 1658 invoked by uid 399); 9 Mar 2012 07:19:48 -0000 Received: from unknown (HELO ?184.48.56.52?) (pbs:m42@mojaklasa.info@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 9 Mar 2012 07:19:48 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F59AF18.2010000@raszuk.net> Date: Fri, 09 Mar 2012 08:19:52 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr wg list References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] defending at layer seven against layer nine attacks X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 07:19:51 -0000 > so, your programatically generated template for a customer peering > could be something such as the following pretty strict policy: > > if p in custs-pfxs > community add ExportToPeersCustsAndUpstreams > if p is marked valid > set local-pref 120 > elif p is marked notfound > set local-pref 100 > elif p is marked invalid # layer nine attack > set local-pref 120 # maintain g-r fantasy that seems really like a brilliant idea to set same local pref of 120 to both valid and invalid customer prefixes. likewise to prefer not found (where 100 would be applied anyway as this is local pref's default value) over invalid customer prefixes. r. From robert@raszuk.net Thu Mar 8 23:23:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1351E21F8642 for ; Thu, 8 Mar 2012 23:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnPVhyu1OIIz for ; Thu, 8 Mar 2012 23:23:01 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 565A521F863C for ; Thu, 8 Mar 2012 23:23:01 -0800 (PST) Received: (qmail 4405 invoked by uid 399); 9 Mar 2012 07:23:00 -0000 Received: from unknown (HELO ?184.48.56.52?) (pbs:robert@raszuk.net@12.217.162.34) by mail1310.opentransfer.com with ESMTPM; 9 Mar 2012 07:23:00 -0000 X-Originating-IP: 12.217.162.34 Message-ID: <4F59AFD8.5040603@raszuk.net> Date: Fri, 09 Mar 2012 08:23:04 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr wg list References: <4F59AF18.2010000@raszuk.net> In-Reply-To: <4F59AF18.2010000@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] defending at layer seven against layer nine attacks X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 07:23:02 -0000 order error: likewise to prefer invalid over not found customer prefixes. Sorry, R. >> so, your programatically generated template for a customer peering >> could be something such as the following pretty strict policy: >> >> if p in custs-pfxs >> community add ExportToPeersCustsAndUpstreams >> if p is marked valid >> set local-pref 120 >> elif p is marked notfound >> set local-pref 100 >> elif p is marked invalid # layer nine attack >> set local-pref 120 # maintain g-r fantasy > > that seems really like a brilliant idea to set same local pref of 120 to > both valid and invalid customer prefixes. likewise to prefer not found > (where 100 would be applied anyway as this is local pref's default > value) over invalid customer prefixes. > > r. > > From kotikalapudi.sriram@nist.gov Fri Mar 9 04:43:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9310121F864B for ; Fri, 9 Mar 2012 04:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+v8fOaZiWW9 for ; Fri, 9 Mar 2012 04:43:36 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 05CA721F864E for ; Fri, 9 Mar 2012 04:43:36 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 07:43:15 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Mar 2012 07:40:23 -0500 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" , "sidr@ietf.org" Date: Fri, 9 Mar 2012 07:40:23 -0500 Thread-Topic: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: AQHM/fBJNbYzIso68EyJLlIzdXa/3A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:43:36 -0000 >We published this -00 draft to document a possible process to perform key = rollovers=20 >on a BGPSEC router certificate and discuss the use of rollovers as an alte= rnative to beaconing. I have a taxonomy suggestion to make. The method we currently have in the -01 version BGPSEC spec draft is really the Origin Signature Expire Time (OSET) method. We should try to move away from calling it the "beaconing" method. The reason is as follows. We have been using the name "beacon" simply to refer to re-origination of a= prefix. By this definition of "beacon", both the OSET method and the Router Re-keyi= ng (RR) method use "beaconing". In the OSET method, the re-origination is done well before the Origin Signa= ture Expire Time is reached. Router does re-origination of prefixes in the Router Re-keying method too, = except that it is done when a new cert (and key-pair) kicks in and well before the previous cert's expire time (i.e., NotValidAfter) is re= ached.=20 Each of the methods involves expire time. The Router Re-keying method has *implicit expire time* =96 the update would= =93expire=94=20 (i.e., become invalid) whenever the originating router's cert expires (and/= or is revoked). The OSET method has *explicit expire time* in the BGPSEC update. Considering all of the above, I think the following taxonomy would be prefe= rable: Origin Signature Expire Time (OSET) method (for what is in the current -01 = spec draft), and Router Re-keying (RR) method (proposed new method). Sriram= From rogaglia@cisco.com Fri Mar 9 05:02:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA5521F8623 for ; Fri, 9 Mar 2012 05:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.475 X-Spam-Level: X-Spam-Status: No, score=-9.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJlvelSUc54a for ; Fri, 9 Mar 2012 05:02:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC5D21F860E for ; Fri, 9 Mar 2012 05:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=6854; q=dns/txt; s=iport; t=1331298159; x=1332507759; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=c1ipFXwa7BP+Ap5s+kSJRXMMa5KNYH9Vl/9V3adia/Q=; b=jBRLGT+KPwdYR9n/eAPwAd1qmv4dvRz2PEq5ffKv8WJtMnyHyxXmD8z8 W5pMM71RIzriRuzJVGTCuftKZOOlOSec6PH7MP3SNxRahwNYcsh4gILBY yWlTnGPlsO589mp4Gp6dAvChsymLQX7KRA4FP7Qsz1ppCtqgS8bTnsl+2 w=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD/+WU+rRDoJ/2dsb2JhbABEtTGBB4IKAQEBAwESAWYFCwIBCEYCMCUCBA4TFIdjBAGbcwGefY93YwSOWYEfhVGQHIJjgVw X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="p7s'?scan'208";a="35360891" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Mar 2012 13:02:39 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q29D2cVv014783; Fri, 9 Mar 2012 13:02:38 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Fri, 9 Mar 2012 05:02:38 -0800 From: "Roque Gagliano (rogaglia)" To: "Sriram, Kotikalapudi" Thread-Topic: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: AQHM/fTnPUE0VVGBOk6qNy0nnlFd9w== Date: Fri, 9 Mar 2012 13:02:38 +0000 Message-ID: <4462EF82-66E7-404E-BF9A-BF098F4EED29@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18762.006 x-tm-as-result: No--26.767700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-503-803638838"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:02:40 -0000 --Apple-Mail-503-803638838 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sriram Thanks for your email. (snif) >=20 > Considering all of the above, I think the following taxonomy would be = preferable: > Origin Signature Expire Time (OSET) method (for what is in the current = -01 spec draft), and > Router Re-keying (RR) method (proposed new method). >=20 I am ok with your proposal for OSET. I used "key rollover" because I = wanted to be consistent with RFC 6489 which uses the term "rollover" = instead of "rekeying". What do you think? Roque > Sriram --Apple-Mail-503-803638838 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MDkxMzAyMzdaMCMGCSqGSIb3DQEJBDEWBBQvMQuhqrjFzuVXqQALOXYXoztxIzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQB7gnSnNFrvFQGS4DXbRkEpCOCWlhD+FRd87ahYOsKtpt84 ALjxnt6yFMPwUUSaUh81gUXXrxsniu3x/N0o9wzl6v71Lb4P+yFFBajpVcMsQOtXHyo7EzJ4rfog 4axCOiChvcXioy1rjArRUOG6nZuMT6kmuMCriHa155GEgFtNYq7W42OmbKxDWPb7DWxNFcP5uuOk vnpOJ+bJ8UAPIU4/2HtLxBHwoNVjL+yPPb9yxjIX/v4rW9LMy+cc/Lq5Rc+KBMjJvS150AR9E7q5 XMk5F4hIRAP4n9c+ABc7pwexqoic0ysor3s8VmN/E7sD+jWbTe7LLoF4TO8GUhI4b7LKAAAAAAAA --Apple-Mail-503-803638838-- From kotikalapudi.sriram@nist.gov Fri Mar 9 05:35:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E1021F85E6 for ; Fri, 9 Mar 2012 05:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YmacloV-SVC for ; Fri, 9 Mar 2012 05:35:22 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 930B021F85F9 for ; Fri, 9 Mar 2012 05:35:22 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 08:35:09 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Mar 2012 08:32:08 -0500 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Fri, 9 Mar 2012 08:32:07 -0500 Thread-Topic: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: AQHM/fTnPUE0VVGBOk6qNy0nnlFd95Zh88CY Message-ID: References: , <4462EF82-66E7-404E-BF9A-BF098F4EED29@cisco.com> In-Reply-To: <4462EF82-66E7-404E-BF9A-BF098F4EED29@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:35:23 -0000 Thanks. I am OK with either: "key rollover" or "router rekeying". It is just that were using "router rekeying" in the SIDR Interim meeting discussions, and Randy is also using it his documents: draft-ymbk-bgpsec-rtr-rekeying-00.txt Sriram ________________________________________ From: Roque Gagliano (rogaglia) [rogaglia@cisco.com] Sent: Friday, March 09, 2012 8:02 AM To: Sriram, Kotikalapudi Cc: sidr@ietf.org Subject: Re: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Hi Sriram Thanks for your email. (snif) > > Considering all of the above, I think the following taxonomy would be preferable: > Origin Signature Expire Time (OSET) method (for what is in the current -01 spec draft), and > Router Re-keying (RR) method (proposed new method). > I am ok with your proposal for OSET. I used "key rollover" because I wanted to be consistent with RFC 6489 which uses the term "rollover" instead of "rekeying". What do you think? Roque > Sriram From kotikalapudi.sriram@nist.gov Fri Mar 9 05:52:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB7321F865E for ; Fri, 9 Mar 2012 05:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCvnqknGb9QJ for ; Fri, 9 Mar 2012 05:52:53 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 725A221F865D for ; Fri, 9 Mar 2012 05:52:53 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 08:52:42 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 9 Mar 2012 08:52:52 -0500 From: "Sriram, Kotikalapudi" To: "Roque Gagliano (rogaglia)" Date: Fri, 9 Mar 2012 08:49:41 -0500 Thread-Topic: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: AQHM/fTnPUE0VVGBOk6qNy0nnlFd95Zh88CYgAAE8/o= Message-ID: References: , <4462EF82-66E7-404E-BF9A-BF098F4EED29@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:52:54 -0000 May seem like acronym mania but another possibility is: RCET (Router Cert Expire Time) method :) We are basically imposing an expire time on BGPSEC announcements either by the router cert's expire time (RCET) or by an explicit Origin Signature Expire Time (OSET). Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Sriram, Kotikalapudi [kotikalapudi.sriram@nist.gov] Sent: Friday, March 09, 2012 8:32 AM To: Roque Gagliano (rogaglia) Cc: sidr@ietf.org Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thanks. I am OK with either: "key rollover" or "router rekeying". It is just that were using "router rekeying" in the SIDR Interim meeting discussions, and Randy is also using it his documents: draft-ymbk-bgpsec-rtr-rekeying-00.txt Sriram ________________________________________ From: Roque Gagliano (rogaglia) [rogaglia@cisco.com] Sent: Friday, March 09, 2012 8:02 AM To: Sriram, Kotikalapudi Cc: sidr@ietf.org Subject: Re: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Hi Sriram Thanks for your email. (snif) > > Considering all of the above, I think the following taxonomy would be preferable: > Origin Signature Expire Time (OSET) method (for what is in the current -01 spec draft), and > Router Re-keying (RR) method (proposed new method). > I am ok with your proposal for OSET. I used "key rollover" because I wanted to be consistent with RFC 6489 which uses the term "rollover" instead of "rekeying". What do you think? Roque > Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Mar 9 05:56:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36BA21F8664 for ; Fri, 9 Mar 2012 05:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHSN2nZsXGUp for ; Fri, 9 Mar 2012 05:56:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8821F8646 for ; Fri, 9 Mar 2012 05:56:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S60JG-0004Ho-RS; Fri, 09 Mar 2012 13:56:43 +0000 Date: Fri, 09 Mar 2012 22:56:41 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:56:46 -0000 > It is just that were using "router rekeying" in the SIDR Interim > meeting discussions, and Randy is also using it his documents: > draft-ymbk-bgpsec-rtr-rekeying-00.txt and it is used for replay protection. randy From dougm@nist.gov Fri Mar 9 06:45:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0440621F85A4 for ; Fri, 9 Mar 2012 06:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-vN9TuXXxx8 for ; Fri, 9 Mar 2012 06:45:21 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7A21F85A1 for ; Fri, 9 Mar 2012 06:45:21 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 09:45:10 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Mar 2012 09:42:09 -0500 From: "Montgomery, Douglas" To: Randy Bush , "Sriram, Kotikalapudi" Date: Fri, 9 Mar 2012 09:45:18 -0500 Thread-Topic: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: Acz+As4iGqF5sT4aSoyHOWFP34DWww== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:45:22 -0000 Just so we understand that they are distinct issues. How to key, re-key routers and reflect that in the RPKI is necessary even if we don't take on the "stale update problem". If rekeying is our approach to control the validity period of stale updates, then the issues become inter-related. If we use other methods to control validity periods, they are not. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/9/12 8:56 AM, "Randy Bush" wrote: >> It is just that were using "router rekeying" in the SIDR Interim >> meeting discussions, and Randy is also using it his documents: >> draft-ymbk-bgpsec-rtr-rekeying-00.txt > >and it is used for replay protection. > >randy >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Mar 9 06:54:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12821F84CD for ; Fri, 9 Mar 2012 06:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6qUdYSig+Vy for ; Fri, 9 Mar 2012 06:54:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98F21F8646 for ; Fri, 9 Mar 2012 06:54:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S61DR-0004PP-Uw; Fri, 09 Mar 2012 14:54:46 +0000 Date: Fri, 09 Mar 2012 23:54:44 +0900 Message-ID: From: Randy Bush To: "Montgomery, Douglas" 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:54:47 -0000 > If rekeying is our approach to control the validity period of stale > updates, then the issues become inter-related. shame you could not make the san diego interim randy From dougm@nist.gov Fri Mar 9 07:11:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B69C21F8691 for ; Fri, 9 Mar 2012 07:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MBugehgNhmH for ; Fri, 9 Mar 2012 07:11:13 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id CB89B21F8642 for ; Fri, 9 Mar 2012 07:11:12 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 10:10:59 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 9 Mar 2012 10:11:09 -0500 From: "Montgomery, Douglas" To: Randy Bush Date: Fri, 9 Mar 2012 10:10:48 -0500 Thread-Topic: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: Acz+Bmit5N4/nWHKTyOlejyrbof0gg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:11:13 -0000 At least part of my quantum state was there. If draft-rogaglia-sidr-bgpsec-rollover-00 becomes the way to control stale updates, the two issues will be intertwined. I was just pointing out that you need the ability to key, re-key anyway, independent of its use in the above. Wonder where else my qbits were that week? dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/9/12 9:54 AM, "Randy Bush" wrote: >> If rekeying is our approach to control the validity period of stale >> updates, then the issues become inter-related. > >shame you could not make the san diego interim > >randy From internet-drafts@ietf.org Fri Mar 9 21:11:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0020C11E8080; Fri, 9 Mar 2012 21:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytHoU+xFB7Zf; Fri, 9 Mar 2012 21:11:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943CF21F852A; Fri, 9 Mar 2012 21:11:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120310051139.3717.92291.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 21:11:39 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-15.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 05:11:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-15.txt Pages : 10 Date : 2012-03-09 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-15.txt From internet-drafts@ietf.org Fri Mar 9 21:13:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D2A11E8087; Fri, 9 Mar 2012 21:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsNB5N9ZbVNG; Fri, 9 Mar 2012 21:13:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6461211E8073; Fri, 9 Mar 2012 21:13:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120310051317.4402.86580.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 21:13:17 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 05:13:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPsec Operational Considerations Author(s) : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-03.txt Pages : 8 Date : 2012-03-09 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-03.txt From internet-drafts@ietf.org Fri Mar 9 23:11:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B66221F8672; Fri, 9 Mar 2012 23:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDLYKx2DLSAs; Fri, 9 Mar 2012 23:11:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A981E21F8648; Fri, 9 Mar 2012 23:11:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120310071140.551.5252.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 23:11:40 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 07:11:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-02.txt Pages : 9 Date : 2012-03-09 This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt From eosterweil@verisign.com Sat Mar 10 11:37:09 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA10821F8567 for ; Sat, 10 Mar 2012 11:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcxZqZYJiI-I for ; Sat, 10 Mar 2012 11:37:09 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9B21F8578 for ; Sat, 10 Mar 2012 11:37:08 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT1utZEDFin1tSHvFOvY9AvKCfCwgE2KV@postini.com; Sat, 10 Mar 2012 11:37:09 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2AJb4Pv017188 for ; Sat, 10 Mar 2012 14:37:07 -0500 Received: from [10.100.0.113] ([10.100.0.113]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 14:37:04 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Eric Osterweil In-Reply-To: <20120310071140.551.5252.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 14:37:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120310071140.551.5252.idtracker@ietfa.amsl.com> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Mar 2012 19:37:04.0114 (UTC) FILETIME=[2BBCD520:01CCFEF5] Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 19:37:09 -0000 I just noticed that none of the comments I made in 11/11: http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html seem to be addressed in this revision. Eric On Mar 10, 2012, at 2:11 AM, Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Security Requirements for BGP Path Validation > Author(s) : Steven M. Bellovin > Randy Bush > David Ward > Filename : draft-ietf-sidr-bgpsec-reqs-02.txt > Pages : 9 > Date : 2012-03-09 >=20 > This document describes requirements for a future BGP security > protocol design to provide cryptographic assurance that the origin = AS > had the right to announce the prefix and to provide assurance of the > AS Path of the announcement. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-02.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Sat Mar 10 14:34:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DBF21F84EA for ; Sat, 10 Mar 2012 14:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wozv+KJsYXcs for ; Sat, 10 Mar 2012 14:34:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4B21F84E2 for ; Sat, 10 Mar 2012 14:34:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S6UrP-0009F0-HY; Sat, 10 Mar 2012 22:33:59 +0000 Date: Sun, 11 Mar 2012 07:33:58 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <20120310071140.551.5252.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Cc: "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 22:34:02 -0000 > I just noticed that none of the comments I made in 11/11: > http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html > seem to be addressed in this revision. mea culpa. but that's why i published early. lemme review now. randy From randy@psg.com Sat Mar 10 15:07:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABB21F8525 for ; Sat, 10 Mar 2012 15:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFF+NyjxE8AL for ; Sat, 10 Mar 2012 15:07:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47421F8516 for ; Sat, 10 Mar 2012 15:07:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S6VNj-0009Hx-9j; Sat, 10 Mar 2012 23:07:23 +0000 Date: Sun, 11 Mar 2012 08:07:09 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <20120310071140.551.5252.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 23:07:25 -0000 > I just noticed that none of the comments I made in 11/11: > http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html > seem to be addressed in this revision. great review. and again my apologies for having missed it. i now have an internal ticket system so i hope to lose less. i have hacked as per following, and will push -03 to repository. this will leave two days for further discussion and another version before the dreadline. > - 3.5 is not a testable requirement. One cannot be expected to enumerate the space of all things that are _not_ requirements, so why put any in? > - 3.6 ibid because these two serve as warnings, to which people might even object. though 3.6, can not fix data-plane, seems obvious to me, to others it might not be. > - 3.7 is too vague. Need to specify where an adversary needs to have access to link-layer. I have access to the link layer at home, but that doesn't help me insert traffic between any BGP peers. Can I suggest modifying the existing text as follows: > ``... an enemy who has access to the inter-router link layer...'' the term ``inter-router link'' is borrowed from the cited RFC. thanks > - 3.8 The word ``MAY'' is a very rough fit for the general notion of ``requirements.'' I would suggest it is reworded: > ``A BGPsec design MUST be able to understand and make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to > routing decisions when such a resource is available and operators wish to configure it for use. Such data includes information about > holdings of address space and ASNs, and assertions about binding of address space to ASNs.'' hmm, you are suggesting OLD: 3.8 A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to routing decisions. Such data include information about holdings of address space and ASNs, and assertions about binding of address space to ASNs. NEW: 3.8 A BGPsec design MUST be able to understand and make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to routing decisions when such a resource is available and operators wish to configure it for use. Such data includes information about holdings of address space and ASNs, and assertions about binding of address space to ASNs. i think you are just moving the point of equivocation. our wording was meant to leave open the idea that there might be other means than a PKI. yours seems to leave open the operator's ability to enable or not. for me, the operator's freedom to decide was assumed. otoh, the OLD wording could indeed be improved. how about 3.8 It is assumed that a BGPsec design will require information about holdings of address space and ASNs, and assertions about binding of address space to ASNs. A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute such authenticated data. i think that catches our intent. i am less sure it catches yours. > - 3.9 is also not worded as a requirement. Does the solution require that a 4k packet even be discussed? It seems to me that this is not the right document to discuss this. fair point. i'll leave a marker in the next version so as not to change numbering so folk can follow the discussion. > - 3.10 also does not seem to be a requirement. It is ``requiring'' an optional exclusion? I suggest it get yanked. making explicit that the design need not cover an existing feature fo BGP, AS-SET, seems important > - 3.11 This also does not seem to be a requirement. Discussing a design's status in a requirements document is backwards. I suggest this get yanked. making explicit that a design need not maintain the update packing feature of current bgp would seem important. > - 3.19 Seems like it would be hard to test as a requirement. The problem may be the word ``MAY.'' How could this be made into a testable requirement? i am not sure testability is the issue. if one can look inside the router, that the database is kept current would seem to be testable. if the router is a black box, not. if you are suggesting that the MAY should be a MUST, i agree and will make that change. > - 3.20 This requirement, again, references a baked design. This should be restated in a general way. Suggest, > ``Any inter-AS use of cryptographic hashes or signatures, should (must?) provide mechanisms for algorithm agility that take the form of...'' how about 3.20 Any inter-AS use of cryptographic hashes or signatures, MUST provide mechanisms for algorithm agility. > - 4.5 The term ``real-time'' seems to carry too many implicit/overloaded meanings. Could we try to disambiguate with different text. Maybe we can just drop that term ``real-time'' and leave the rest? sure > - 4.7 This requirement seems to preach a little bit of a design instead of being agnostic. Could it be rephrased to be something like: > ``The output of a router applying BGPsec to a received signed UPDATE MUST be either unequivocal and conform to a fully specified state in the design.'' sure. deep thanks for the thoughtful review, and apologies for having lost it. randy From internet-drafts@ietf.org Sat Mar 10 15:10:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CE921F84FC; Sat, 10 Mar 2012 15:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqFlQ8n4aT71; Sat, 10 Mar 2012 15:10:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5938421F84D9; Sat, 10 Mar 2012 15:10:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120310231043.16482.41372.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 15:10:43 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 23:10:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Security Requirements for BGP Path Validation Author(s) : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-03.txt Pages : 9 Date : 2012-03-10 This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-reqs-03.txt From jhaas@slice.pfrc.org Sun Mar 11 14:36:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552721F8754 for ; Sun, 11 Mar 2012 14:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clfuZqgAmTG0 for ; Sun, 11 Mar 2012 14:36:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 516A221F874C for ; Sun, 11 Mar 2012 14:36:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1CE201703E1; Sun, 11 Mar 2012 17:36:44 -0400 (EDT) Date: Sun, 11 Mar 2012 17:36:44 -0400 From: Jeffrey Haas To: Brian Dickson Message-ID: <20120311213644.GA21499@slice> References: <20120305180943.16641.16867.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-def-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:36:45 -0000 Brian, On Mon, Mar 05, 2012 at 07:31:23PM -0500, Brian Dickson wrote: > Here is the first of three IDs, concerning the definitions of "route leak". : 1.1. Rationale : : : A route-leak occurs when a prefix is originated by one party, : propagated by other parties, and received by the observer, where the : path used was not intentional end-to-end. It is a leak if the : receiver did not want the route, from a generic policy perspective. If the receiver didn't want the route? While that's perhaps true in many cases, the impacted party is usually someone whose route was distributed outside the scope where they intended it to be distributed. -- Jeff From jhaas@slice.pfrc.org Sun Mar 11 14:47:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D6821F84E7 for ; Sun, 11 Mar 2012 14:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZTNKKjnqxS6 for ; Sun, 11 Mar 2012 14:47:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BD25721F84E6 for ; Sun, 11 Mar 2012 14:47:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 89C021703E1; Sun, 11 Mar 2012 17:47:23 -0400 (EDT) Date: Sun, 11 Mar 2012 17:47:23 -0400 From: Jeffrey Haas To: Brian Dickson Message-ID: <20120311214723.GB21499@slice> References: <20120306002849.8209.942.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:47:24 -0000 Brian, On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote: > Greetings, SIDR folks, > > Here is the notice on the ID for the route leak "requirements" document. I am likely misunderstanding something in this document, but my interpretation of it is that routes are always colored based on link role. Consider some prefix, P, sent from AS 1 to AS 2 on two different links. Link 1 is primarily used for peering traffic. Link 2 is used for transit traffic. If I'm understanding the draft properly, routes received on Link 1 should not be propagated to AS 3 even though it's the same prefix (and path attribute set) as P received on Link 2. Is that correct? -- Jeff From jakob.heitz@ericsson.com Sun Mar 11 15:00:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DE521F8720 for ; Sun, 11 Mar 2012 15:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwYRGaSrzZpx for ; Sun, 11 Mar 2012 15:00:55 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A82AE21F871C for ; Sun, 11 Mar 2012 15:00:55 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2BM0rOJ009744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Mar 2012 17:00:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 11 Mar 2012 18:00:52 -0400 From: Jakob Heitz To: Jeffrey Haas , Brian Dickson Date: Sun, 11 Mar 2012 18:00:50 -0400 Thread-Topic: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt Thread-Index: Acz/0I2QsC5rXTOfRuaUQSmy5D+bUQAATBYg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3CAF63CE@EUSAACMS0701.eamcs.ericsson.se> References: <20120306002849.8209.942.idtracker@ietfa.amsl.com> <20120311214723.GB21499@slice> In-Reply-To: <20120311214723.GB21499@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 22:00:56 -0000 The essence IMO: If A sends a packet to B, then A must trust A's provider and B's provider and by extension, their providers and so on. A does not trust other customers of those providers and does not want his packet transiting any of them. Now, design the routing to make that happen. -- Jakob Heitz. -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Jef= frey Haas Sent: Sunday, March 11, 2012 2:47 PM To: Brian Dickson Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-ro= ute-leak-reqts-02.txt Brian, On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote: > Greetings, SIDR folks, >=20 > Here is the notice on the ID for the route leak "requirements" document. I am likely misunderstanding something in this document, but my interpretation of it is that routes are always colored based on link role. Consider some prefix, P, sent from AS 1 to AS 2 on two different links. Link 1 is primarily used for peering traffic. Link 2 is used for transit traffic. If I'm understanding the draft properly, routes received on Link = 1 should not be propagated to AS 3 even though it's the same prefix (and path attribute set) as P received on Link 2. Is that correct? -- Jeff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Sun Mar 11 17:44:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8832021F8578 for ; Sun, 11 Mar 2012 17:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqdTJ+M5LzyS for ; Sun, 11 Mar 2012 17:44:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4390C21F8575 for ; Sun, 11 Mar 2012 17:44:42 -0700 (PDT) Received: by werb10 with SMTP id b10so3412239wer.31 for ; Sun, 11 Mar 2012 17:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vgDSec80ktnurKrJ/YVLF0QmgOnVlP/QyM2uFbDWlEI=; b=KQ81SCneXP9Ets1HFmAKqwyvBxLJxyxb4H4tMFEPDB+4Dj0MhageGb/Dbw93s6l/yx yfKvdPY5tM4fvDOTEe8iSvT0AqVqBiDjkOA+bvk6+sM+RKS3qp2z2yhNSYB9Xrg+V4uS Kg0G1HZjHVjALOUbbU9K0g/2OheB53QWT3vUX0FxT0ooQ1yZawvrkNxir8XSyKTc5beD +i8+LxXk6H0ou2np+nJbxthXZaSFz8x3bVOT8tcD/iVhFeu8vAagf7D8K6rEUY10d3DW jHCZsdSDqGK+Bvbm8nCLYr6JovI7uR3QxAzahe/OMo48Zq/dzrlSeuUhGAjmB2bDe7zi 7snw== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr2675615wib.3.1331513081185; Sun, 11 Mar 2012 17:44:41 -0700 (PDT) Received: by 10.223.69.3 with HTTP; Sun, 11 Mar 2012 17:44:41 -0700 (PDT) In-Reply-To: <20120311214723.GB21499@slice> References: <20120306002849.8209.942.idtracker@ietfa.amsl.com> <20120311214723.GB21499@slice> Date: Sun, 11 Mar 2012 20:44:41 -0400 Message-ID: From: Brian Dickson To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d04426f1437c7b404bb010c57 Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 00:44:43 -0000 --f46d04426f1437c7b404bb010c57 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 11, 2012 at 5:47 PM, Jeffrey Haas wrote: > Brian, > > On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote: > > Greetings, SIDR folks, > > > > Here is the notice on the ID for the route leak "requirements" document. > > I am likely misunderstanding something in this document, but my > interpretation of it is that routes are always colored based on link role. > > This is correct. This is an extension of common operational mechanisms, where ISPs frequently color route internally. The distinction is, this coloring would be universal end-to-end, at least where contiguous areas using the mechanism exist. The down-side is, it is nearly impossible to bridge gaps where the mechanisms are not used. > Consider some prefix, P, sent from AS 1 to AS 2 on two different links. > Link 1 is primarily used for peering traffic. Link 2 is used for transit > traffic. If I'm understanding the draft properly, routes received on Link > 1 > should not be propagated to AS 3 even though it's the same prefix (and path > attribute set) as P received on Link 2. Is that correct? > Correct. This is normally the case anyway, since routes can only be advertised to AS3 if they are selected as "best". This means that for transit to function, the customer side of the transit link must be preferred over the peering link, in one direction. Typically, in combined transit+peering relationships, the benefit is not having the transit link used for "on-net" routes of AS 2. And typically, the peering link is "settlement-free", so this reduces the costs for AS 1. Having the choice of link being determined by source address, is "policy routing", which tends not to be supported at the hardware level. The announcements at the inter-AS level (based on color) is independent on the handling of routing and forwarding at the intra-AS level. Coloring announcements based on link type, and restricting route propagation based on color, does not preclude internal policy routing. (This scenario was one that was explicitly analyzed in developing the three documents.) > > -- Jeff > > Brian --f46d04426f1437c7b404bb010c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Mar 11, 2012 at 5:47 PM, Jeffrey= Haas <jhaas@pfrc.or= g> wrote:
Brian,

On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote:
> Greetings, SIDR folks,
>
> Here is the notice on the ID for the route leak "requirements&quo= t; document.

I am likely misunderstanding something in this document, but my
interpretation of it is that routes are always colored based on link role.<= br>

This is correct.

<= div>This is an extension of common operational mechanisms, where ISPs frequ= ently color route internally.

The distinction is, = this coloring would be universal end-to-end, at least where contiguous area= s using the mechanism exist.

The down-side is, it is nearly impossible to bridge gap= s where the mechanisms are not used.
=A0
Consider some prefix, P, sent from AS 1 to AS 2 on two different links.
Link 1 is primarily used for peering traffic. =A0Link 2 is used for transit=
traffic. =A0If I'm understanding the draft properly, routes received on= Link 1
should not be propagated to AS 3 even though it's the same prefix (and = path
attribute set) as P received on Link 2. =A0Is that correct?

Correct.

This is normally the= case anyway, since routes can only be advertised to AS3 if they are select= ed as "best".

This means that for transit to function, the customer s= ide of the transit link must be preferred over the peering link, in one dir= ection.

Typically, in combined transit+peering rel= ationships, the benefit is not having the transit link used for "on-ne= t" routes of AS 2.

And typically, the peering link is "settlement-fre= e", so this reduces the costs for AS 1.

Havin= g the choice of link being determined by source address, is "policy ro= uting", which tends not to be supported at the hardware level.

The announcements at the inter-AS level (based on color= ) is independent on the handling of routing and forwarding at the intra-AS = level.

Coloring announcements based on link type, = and restricting route propagation based on color, does not preclude interna= l policy routing.

(This scenario was one that was explicitly analyzed in = developing the three documents.)
=A0

-- Jeff


Brian=A0

--f46d04426f1437c7b404bb010c57-- From brian.peter.dickson@gmail.com Sun Mar 11 17:51:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9481C21F86B5 for ; Sun, 11 Mar 2012 17:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGtXeVjbykhM for ; Sun, 11 Mar 2012 17:51:25 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A344721F863C for ; Sun, 11 Mar 2012 17:51:22 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2349645wib.13 for ; Sun, 11 Mar 2012 17:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HRC4uM6/42HlgzV7dEiBeVHbHsSjwSOFmS6LfFmAAjM=; b=nWYs7xlIJMhspp3HLoL+AHrk01t9YEKtiKXF0vikKCYNjCDlB/+L4hqFsf4FjUCKV+ t0qoExIN+ONBO+B5z+Ebv4fzJw2EgthypWQwXLc9JASo7MI2yqTawGh0aOp/PwtcTCxe g2kdbvQ5ly2jQSYq5fJcVPNKHf63wScioZG61M1V8Ywa8t7KCqwaBcnCugJU250vAvoI co3QYRiVOlCbOyQoWU1ELr3fAbY4AHfLXCdNwXxPV9ihce5IUzZqfDQ3SmHBDhxmGrBv XE8NRhyrsLElvjVPkpuHNv8JfaKJwOOYduNcmtry71RTU44BM0Wuo15ZkZcBQeR/D/en wBjQ== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr8475379wib.3.1331513481512; Sun, 11 Mar 2012 17:51:21 -0700 (PDT) Received: by 10.223.69.3 with HTTP; Sun, 11 Mar 2012 17:51:21 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3CAF63CE@EUSAACMS0701.eamcs.ericsson.se> References: <20120306002849.8209.942.idtracker@ietfa.amsl.com> <20120311214723.GB21499@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3CAF63CE@EUSAACMS0701.eamcs.ericsson.se> Date: Sun, 11 Mar 2012 20:51:21 -0400 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: multipart/alternative; boundary=f46d0444ee2d14451c04bb01249a Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-reqts-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 00:51:26 -0000 --f46d0444ee2d14451c04bb01249a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 11, 2012 at 6:00 PM, Jakob Heitz wrote: > The essence IMO: > > If A sends a packet to B, > then A must trust A's provider and B's provider > and by extension, their providers and so on. > > A does not trust other customers of those providers > and does not want his packet transiting any of them. > > Now, design the routing to make that happen. > > Thanks, that is a correct summation of what my documents are intended to do. Link coloring identifies route leaks. Even if the enhancements to not prevent intermediaries from propagation of route leaks, they make it possible to identify route leaks. However, without strong-ish enforcement for stopping propagation of route leaks, non-leak paths may be suppressed (because only locally-selected "best" paths get announced). So, while it may mean a semantic tightening of the notion of "local policy can do anything", the fact that changing link types (which in turn changes link coloring) can accomplish everything that "leaks" can do, means there isn't a strong case for adopting the "opt-in" mentality. In other words, adding anti-leak techniques to the protocol spec, does this ("make that happen"). Brian > -- > Jakob Heitz. > > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Sunday, March 11, 2012 2:47 PM > To: Brian Dickson > Cc: sidr wg list > Subject: Re: [sidr] Fwd: New Version Notification for > draft-dickson-sidr-route-leak-reqts-02.txt > > Brian, > > On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote: > > Greetings, SIDR folks, > > > > Here is the notice on the ID for the route leak "requirements" document. > > I am likely misunderstanding something in this document, but my > interpretation of it is that routes are always colored based on link role. > > Consider some prefix, P, sent from AS 1 to AS 2 on two different links. > Link 1 is primarily used for peering traffic. Link 2 is used for transit > traffic. If I'm understanding the draft properly, routes received on Link > 1 > should not be propagated to AS 3 even though it's the same prefix (and path > attribute set) as P received on Link 2. Is that correct? > > -- Jeff > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --f46d0444ee2d14451c04bb01249a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Mar 11, 2012 at 6:00 PM, Jakob H= eitz <jako= b.heitz@ericsson.com> wrote:
--
Jakob Heitz.

-----Original Message-----
From: sidr-bounces@ietf.org [m= ailto:sidr-bounces@ietf.org] O= n Behalf Of Jeffrey Haas
Sent: Sunday, March 11, 2012 2:47 PM
To: Brian Dickson
Cc: sidr wg list
Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-ro= ute-leak-reqts-02.txt

Brian,

On Mon, Mar 05, 2012 at 07:32:25PM -0500, Brian Dickson wrote:
> Greetings, SIDR folks,
>
> Here is the notice on the ID for the route leak "requirements&quo= t; document.

I am likely misunderstanding something in this document, but my
interpretation of it is that routes are always colored based on link role.<= br>
Consider some prefix, P, sent from AS 1 to AS 2 on two different links.
Link 1 is primarily used for peering traffic. =A0Link 2 is used for transit=
traffic. =A0If I'm understanding the draft properly, routes received on= Link 1
should not be propagated to AS 3 even though it's the same prefix (and = path
attribute set) as P received on Link 2. =A0Is that correct?

-- Jeff

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

--f46d0444ee2d14451c04bb01249a-- From brian.peter.dickson@gmail.com Sun Mar 11 18:15:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF15721F8592 for ; Sun, 11 Mar 2012 18:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtxiqbmqouVY for ; Sun, 11 Mar 2012 18:15:02 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E48AF21F8569 for ; Sun, 11 Mar 2012 18:15:01 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2548986wib.1 for ; Sun, 11 Mar 2012 18:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i7tF2FlYDF0YsjfC0NacnQQGOgdCHCEsbUn7WJZMFEI=; b=lEu06D7kWSHYJ85/1aUh7xBXEaB4ebkfFDZTtWsmu6rbJ7LhjkZQl0jYSX4Ejqd1VF bsO0vUnlSVPWlYGoN2hmksuIuZLkpOjfLxaZcZI9EBUtVZnnCguZEkF0pYLpx9rE7SRh 9j3d1Tc2RKLRVxXz4aiW7a8JHtrT8nV6aIdf2tUlICbbqv6xDTcOkb2hrvbq0+k//si0 duYtB9RCh+z2e7ReVeOOYY6MchH0zcO06VD1EIqP6T/sJcvZ7PChCDyxdmKnNEsK6XyM Ylpoeaa6wMzwd9nfwMW90DMjUaXRemngJt4fKuoSU9g6eYj81j0/pkhyjNSDVs42x01U eWbw== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr2857391wib.3.1331514900817; Sun, 11 Mar 2012 18:15:00 -0700 (PDT) Received: by 10.223.69.3 with HTTP; Sun, 11 Mar 2012 18:15:00 -0700 (PDT) In-Reply-To: <20120311213644.GA21499@slice> References: <20120305180943.16641.16867.idtracker@ietfa.amsl.com> <20120311213644.GA21499@slice> Date: Sun, 11 Mar 2012 21:15:00 -0400 Message-ID: From: Brian Dickson To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d04426f14ad25f504bb017831 Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification for draft-dickson-sidr-route-leak-def-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 01:15:03 -0000 --f46d04426f14ad25f504bb017831 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 11, 2012 at 5:36 PM, Jeffrey Haas wrote: > Brian, > > On Mon, Mar 05, 2012 at 07:31:23PM -0500, Brian Dickson wrote: > > Here is the first of three IDs, concerning the definitions of "route > leak". > > > : 1.1. Rationale > : > : > : A route-leak occurs when a prefix is originated by one party, > : propagated by other parties, and received by the observer, where the > : path used was not intentional end-to-end. It is a leak if the > : receiver did not want the route, from a generic policy perspective. > > If the receiver didn't want the route? While that's perhaps true in many > cases, the impacted party is usually someone whose route was distributed > outside the scope where they intended it to be distributed. > > -- Jeff > Yes, you are correct. We can expand the language however folks would prefer. (But it is different from saying, "It is a leak _only_ if"... that was definitely not the intention of the description.) It should also be noted that, based on the definition(s), it would appear to be a leak, to every recipient after it became a leak. And, in most instances, it would also meet other leak-like criteria, including intended scope. The important thing is to reduce it to the smallest set of consistently present conditions -- a basis, if you will -- to make it possible to build rules into the protocol to stop leaks. Brian --f46d04426f14ad25f504bb017831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Mar 11, 2012 at 5:36 PM, Jeffrey= Haas <jhaas@pfrc.or= g> wrote:
Brian,

On Mon, Mar 05, 2012 at 07:31:23PM -0500, Brian Dickson wrote:
> Here is the first of three IDs, concerning the definitions of "ro= ute leak".


: 1.1. Rationale
:
:
: =A0 =A0A route-leak occurs when a prefix is originated by one party,
: =A0 =A0propagated by other parties, and received by the observer, where t= he
: =A0 =A0path used was not intentional end-to-end. =A0It is a leak if the : =A0 =A0receiver did not want the route, from a generic policy perspective= .

If the receiver didn't want the route? =A0While that's perhaps true= in many
cases, the impacted party is usually someone whose route was distributed outside the scope where they intended it to be distributed.

-- Jeff

Yes, you are correct. We can expand the languag= e however folks would prefer.

(But it is different= from saying, "It is a leak _only_ if"... that was definitely not= the intention of the description.)

It should also be noted that, based on the definition(s= ), it would appear to be a leak, to every recipient after it became a leak.=

And, in most instances, it would also meet other = leak-like criteria, including intended scope.

The important thing is to reduce it to the smallest set= of consistently present conditions -- a basis, if you will -- to make it p= ossible to build rules into the protocol to stop leaks.

Brian
--f46d04426f14ad25f504bb017831-- From rogaglia@cisco.com Mon Mar 12 04:03:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70D21F86B9 for ; Mon, 12 Mar 2012 04:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.635 X-Spam-Level: X-Spam-Status: No, score=-9.635 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDJmqw5lwF6Y for ; Mon, 12 Mar 2012 04:03:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD1221F867E for ; Mon, 12 Mar 2012 04:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7417; q=dns/txt; s=iport; t=1331550187; x=1332759787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/LZ4h0Z2051ZUtegmNw8z5zNO993QX1KE7OOfw7cGZ0=; b=PDpw8oMklv+fuTxtLMVQUJAczEza2TyyxvyM4G+vERDcL6kihqwBy/bV Mc5fwQfWDupgF54ikjdERvHTOSlkzM66hHJFYC3M6zDXKlovpejn0YRaB g0peP82RoezmtTTBJ5s/bvKlvebI1uMzuf8z2c3XI18H9gJRiIIo3710U 4=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAE3XXU+tJXG//2dsb2JhbABBtViBB4IJAQEBAwEBAQEPAVsLBQsCAQgYLgIlCyUCBA4FDhSHYwULn3EBllYEkQEEjluBH4VSkCOCYw X-IronPort-AV: E=Sophos;i="4.73,570,1325462400"; d="p7s'?scan'208";a="65602461" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2012 11:03:06 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CB36pI016870; Mon, 12 Mar 2012 11:03:06 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Mon, 12 Mar 2012 04:03:06 -0700 From: "Roque Gagliano (rogaglia)" To: "Montgomery, Douglas" Thread-Topic: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: AQHNAD+zohc8hbKDCUC2csKF9ZB9BA== Date: Mon, 12 Mar 2012 11:03:06 +0000 Message-ID: <4783C9D9-FBD6-42E9-9639-026971819846@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18768.005 x-tm-as-result: No--37.736200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-117-1055667989"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 11:03:08 -0000 --Apple-Mail-117-1055667989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Douglas, On Mar 9, 2012, at 4:10 PM, Montgomery, Douglas wrote: > At least part of my quantum state was there. >=20 > If draft-rogaglia-sidr-bgpsec-rollover-00 becomes the way to control = stale > updates, the two issues will be intertwined. >=20 > I was just pointing out that you need the ability to key, re-key = anyway, > independent of its use in the above. Agreed, and I though we captured it with Sections 1 and 2 of the = document. Roque. > Wonder where else my qbits were that week? >=20 > dougm > --=20 > Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / = NIST >=20 >=20 >=20 >=20 >=20 >=20 > On 3/9/12 9:54 AM, "Randy Bush" wrote: >=20 >>> If rekeying is our approach to control the validity period of stale >>> updates, then the issues become inter-related. >>=20 >> shame you could not make the san diego interim >>=20 >> randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-117-1055667989 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MTIxMTAzMDZaMCMGCSqGSIb3DQEJBDEWBBT/46za5/A65f8pvDCKLeU/uinwCTCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQA+NRJYqdosxtQFHUMa87StbzN6z1W/hfGIiC6BUJVgoIJk BzbTrePAb1T60dWGLmiRfSe1W7nAyxyGeI4GDDgZQC0LZLTwVol5vyYNpLoLDRBVbJs+XigTIXaS BALaDTFeot8RJqBx//mzaIuL57gVyf06cTKUOpvdydJ50qVMXIJiBFW2YpaFg3Z/kVbVTt5xTiv/ yhaTLtcILtGmRWNN2eVRKIqMCAWau0EtjHQGH0B6SGadvOzo6JC1lRoFbyJPGWxdR5LHFGDcLiTs 5cH1YSBuDmRQRegNcKjiv7KIjYSV48TegKyCfMEA6evRenoPsuCgbzpPPdKdasgCmR7jAAAAAAAA --Apple-Mail-117-1055667989-- From turners@ieca.com Mon Mar 12 13:13:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A7A21F898C for ; Mon, 12 Mar 2012 13:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcygqRaJCeTn for ; Mon, 12 Mar 2012 13:13:56 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.44.15]) by ietfa.amsl.com (Postfix) with ESMTP id D199421F892D for ; Mon, 12 Mar 2012 13:13:47 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 400F674D3241; Mon, 12 Mar 2012 15:13:47 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 359CC74D3221 for ; Mon, 12 Mar 2012 15:13:47 -0500 (CDT) Received: from [96.241.1.58] (port=41891 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S7Bcm-00023O-3G; Mon, 12 Mar 2012 15:13:47 -0500 Message-ID: <4F5E58EF.2000908@ieca.com> Date: Mon, 12 Mar 2012 16:13:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.1.58]:41891 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:13:57 -0000 Well I'd like to see it adopted and I promise to work on it ;) spt On 3/7/12 6:07 PM, Murphy, Sandra wrote: > An alert eye pointed out that the URL below is incorrect. The correct pointer is > > http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 > > --Sandy, speaking as clumsy wg co-chair > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com] > Sent: Wednesday, March 07, 2012 5:40 PM > To: sidr@ietf.org > Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt > > The following request has been made for wg adoption of draft-ymbk-bgpsec-rtr-rekeying-00.txt. > > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. > > Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. > > This call will end 21 Mar 2012. > > --Sandy, speaking as wg co-chair > > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy Bush [randy@psg.com] > Sent: Monday, March 05, 2012 8:54 PM > To: sidr wg list > Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt > > chairs, please consider as a wg work item. thanks. > > randy > > --- > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ymbk-bgpsec-rtr-rekeying-00.txt > > A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been succes= > sfully submitted by Sean Turner and posted to the IETF repository. > > Filename: draft-ymbk-bgpsec-rtr-rekeying > Revision: 00 > Title: Router Keying for BGPsec > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 7 > > Abstract: > BGPsec-speaking routers must be provisioned with private keys and the > corresponding public key must be published in the global Resource > PKI. This document describes two ways of doing so, router-driven and > operator-driven. > _______________________________________________ > 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 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@sparta.com Mon Mar 12 13:25:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A811E8086 for ; Mon, 12 Mar 2012 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.65 X-Spam-Level: X-Spam-Status: No, score=-101.65 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YpWclCkCYQ1 for ; Mon, 12 Mar 2012 13:25:31 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0B11E8094 for ; Mon, 12 Mar 2012 13:25:30 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2CKPURB000694 for ; Mon, 12 Mar 2012 15:25:30 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2CKPT67017351 for ; Mon, 12 Mar 2012 15:25:30 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 16:25:29 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: nagging about agenda requests Thread-Index: Ac0AjkOS2BCtTQvKRyu6G2atfsPJaA== Date: Mon, 12 Mar 2012 20:25:28 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C718A@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] nagging about agenda requests X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:25:31 -0000 I have seen few requests for agenda time at the sidr meeting. The draft agendas are due Wed of this week. If you think you have somethin= g to address to the entire group, now would be a good time to ask for a tim= e slot. --Sandy= From internet-drafts@ietf.org Mon Mar 12 13:53:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40A11E811D; Mon, 12 Mar 2012 13:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akpBvIMZdRyy; Mon, 12 Mar 2012 13:53:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB99911E8104; Mon, 12 Mar 2012 13:53:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312205331.1904.65803.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 13:53:31 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:53:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : A Publication Protocol for the Resource Public Key Infra= structure (RPKI) Author(s) : Samuel Weiler Anuja Sonalker Rob Austein Filename : draft-ietf-sidr-publication-02.txt Pages : 19 Date : 2012-03-12 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-publication-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-publication-02.txt From kent@bbn.com Mon Mar 12 14:12:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A383821F8957 for ; Mon, 12 Mar 2012 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98MvpZQpXvmn for ; Mon, 12 Mar 2012 14:12:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19121F894B for ; Mon, 12 Mar 2012 14:12:40 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49319) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7CXd-000IeZ-QF; Mon, 12 Mar 2012 17:12:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 Mar 2012 17:12:36 -0400 To: "Montgomery, Douglas" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:12:47 -0000 At 9:45 AM -0500 3/9/12, Montgomery, Douglas wrote: >Just so we understand that they are distinct issues. How to key, re-key >routers and reflect that in the RPKI is necessary even if we don't take on >the "stale update problem". > >If rekeying is our approach to control the validity period of stale >updates, then the issues become inter-related. If we use other methods to >control validity periods, they are not. > >dougm >-- >Doug Montgomery - Mgr. Internet & Scalable Systems Research / ITL / NIST Doug, A minor quibble. Whether we view router cert validity intervals as the primary way to manage signed advertisement lifetimes, or not, the two are related, at least in principle. Steve From dougm@nist.gov Mon Mar 12 14:26:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161111E80EF for ; Mon, 12 Mar 2012 14:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83FjTkfXtA2h for ; Mon, 12 Mar 2012 14:26:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4811E8088 for ; Mon, 12 Mar 2012 14:26:37 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Mar 2012 17:26:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 12 Mar 2012 17:23:10 -0400 From: "Montgomery, Douglas" To: Stephen Kent Date: Mon, 12 Mar 2012 17:26:30 -0400 Thread-Topic: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) Thread-Index: Ac0AllJ05I38ffRZRUGgItxZdAxgMA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:26:38 -0000 Sure. Put another way, validity of an PATH_SIG can expire, whether we intended it to, or not. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/12/12 5:12 PM, "Stephen Kent" wrote: >At 9:45 AM -0500 3/9/12, Montgomery, Douglas wrote: >>Just so we understand that they are distinct issues. How to key, re-key >>routers and reflect that in the RPKI is necessary even if we don't take >>on >>the "stale update problem". >> >>If rekeying is our approach to control the validity period of stale >>updates, then the issues become inter-related. If we use other methods >>to >>control validity periods, they are not. >> >>dougm >>-- >>Doug Montgomery - Mgr. Internet & Scalable Systems Research / ITL / NIST > >Doug, > >A minor quibble. > >Whether we view router cert validity intervals as the primary way to >manage >signed advertisement lifetimes, or not, the two are related, at least >in principle. > >Steve From internet-drafts@ietf.org Mon Mar 12 15:59:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E5C21F8A4E; Mon, 12 Mar 2012 15:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4edJ06M1TVGP; Mon, 12 Mar 2012 15:59:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD9D21F8984; Mon, 12 Mar 2012 15:59:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312225942.31152.76661.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:59:42 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:59:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPsec Operational Considerations Author(s) : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-04.txt Pages : 8 Date : 2012-03-12 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-04.txt From internet-drafts@ietf.org Mon Mar 12 16:15:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD2A21F8AB3; Mon, 12 Mar 2012 16:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwtibs7I4Zp6; Mon, 12 Mar 2012 16:15:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08321E8046; Mon, 12 Mar 2012 16:15:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312231528.10972.16819.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:15:28 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:15:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPSEC Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-02.txt Pages : 27 Date : 2012-03-12 This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-02.txt From internet-drafts@ietf.org Mon Mar 12 16:27:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C524A21E8049; Mon, 12 Mar 2012 16:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBeju3UzG6kI; Mon, 12 Mar 2012 16:27:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F321F8A3B; Mon, 12 Mar 2012 16:27:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:27:02 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:27:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGP Prefix Origin Validation Author(s) : Pradosh Mohapatra John Scudder David Ward Randy Bush Rob Austein Filename : draft-ietf-sidr-pfx-validate-04.txt Pages : 11 Date : 2012-03-12 To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt From randy@psg.com Mon Mar 12 16:35:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8C721E8217 for ; Mon, 12 Mar 2012 16:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAdvIKjiNA8w for ; Mon, 12 Mar 2012 16:35:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 230F821E8219 for ; Mon, 12 Mar 2012 16:35:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7EmU-000Fye-OE for sidr@ietf.org; Mon, 12 Mar 2012 23:35:58 +0000 Date: Tue, 13 Mar 2012 08:35:57 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:35:59 -0000 i have two serious disagreements with this draft. o a prefix against which validation has not been run (no validation at all or some knob turned off) should not be marked Valid. that would be a lie. it should be marked NotFound. o routes learned by ibgp and routes originated on this router should be checked and marked. i do not want to hear from a neighboring noc that i am originating or propagating garbage. the ibgp case is particularly egregious in partial deployment, where my ibgp peer may not be validating at all. some vendor engs do not seem to realize how extensively ops apply policy to ibgp. the example i like is that we are driven to it by droids who sell both local peering and global transit to the same bgp peer. maz also gave a nice example in a workshop we did here a few years back . randy From jakob.heitz@ericsson.com Mon Mar 12 16:50:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E2B21E827B for ; Mon, 12 Mar 2012 16:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlxisaQwDphL for ; Mon, 12 Mar 2012 16:49:59 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD821E8272 for ; Mon, 12 Mar 2012 16:49:59 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2CNnwNb030874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Mar 2012 18:49:59 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 12 Mar 2012 19:49:58 -0400 From: Jakob Heitz To: Randy Bush , sidr wg list Date: Mon, 12 Mar 2012 19:49:57 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt Thread-Index: Ac0AqPsI5gxFBAIsSdG32ZiLVfw+ggAAXe5g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3CB798A2@EUSAACMS0701.eamcs.ericsson.se> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:50:00 -0000 -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Ran= dy Bush Sent: Monday, March 12, 2012 4:36 PM To: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt i have two serious disagreements with this draft. o a prefix against which validation has not been run (no validation at all or some knob turned off) should not be marked Valid. that would be a lie. it should be marked NotFound. It isn't quite NotFound either. How about a new value: NotChecked. -- Jakob Heitz. From hannes@juniper.net Mon Mar 12 17:50:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7AE21E80EC for ; Mon, 12 Mar 2012 17:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWYceJeEE5sk for ; Mon, 12 Mar 2012 17:50:54 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 213E921E806F for ; Mon, 12 Mar 2012 17:50:52 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT16Z6wC/qUK/azQNBB0KGaTpnkb9+XC5@postini.com; Mon, 12 Mar 2012 17:50:53 PDT Received: from sa-nc-finance-45.static.jnpr.net (172.23.5.45) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Mon, 12 Mar 2012 17:49:57 -0700 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Tue, 13 Mar 2012 01:49:57 +0100 Content-Transfer-Encoding: 7bit Message-ID: <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.1257) X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:50:54 -0000 On Mar 13, 2012, at 12:35 AM, Randy Bush wrote: > o a prefix against which validation has not been run (no validation at > all or some knob turned off) should not be marked Valid. that would > be a lie. it should be marked NotFound. FWIW - the JUNOS implementation has got this 4th state, called "Unverified". its intended use is to spot routes which haven't been properly evaluated using BGP import policy. /hannes From randy@psg.com Mon Mar 12 18:27:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE16E21F88CA for ; Mon, 12 Mar 2012 18:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l28-R1sJwoNq for ; Mon, 12 Mar 2012 18:27:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1021F8582 for ; Mon, 12 Mar 2012 18:27:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7GW2-000Gmx-Fh; Tue, 13 Mar 2012 01:27:06 +0000 Date: Tue, 13 Mar 2012 10:27:05 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:27:07 -0000 >> o a prefix against which validation has not been run (no validation >> at all or some knob turned off) should not be marked Valid. that >> would be a lie. it should be marked NotFound. > FWIW - the JUNOS implementation has got this 4th state, called > "Unverified". the only problem i see with this is that, if i do not test for it in policy, i will fall off the end. policy-statement route-validation { term valid { from { protocol bgp; validation-state valid; } then { local-preference 110; validation-state valid; accept; } } term invalid { from { protocol bgp; validation-state invalid; } then { local-preference 90; validation-state invalid; deny; } } term unknown { from { protocol bgp; validation-state unknown; } then { validation-state unknown; accept; } } } randy From joelja@bogus.com Mon Mar 12 23:42:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7321F88A5 for ; Mon, 12 Mar 2012 23:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as2ogb7jcf9j for ; Mon, 12 Mar 2012 23:42:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B91C121F88A4 for ; Mon, 12 Mar 2012 23:42:14 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2D6gDMo066901 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 06:42:14 GMT (envelope-from joelja@bogus.com) Message-ID: <4F5EEC45.1080306@bogus.com> Date: Mon, 12 Mar 2012 23:42:13 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 13 Mar 2012 06:42:14 +0000 (UTC) Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:42:16 -0000 sorry I normally follow sidr on the archive... > To: sidr wg list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt > From: Randy Bush > Date: Tue, 13 Mar 2012 08:35:57 +0900 > Delivered-to: sidr at ietfa.amsl.com > In-reply-to: <20120312232702.17194.34028.idtracker at ietfa.amsl.com> > List-archive: > List-help: > List-id: Secure Interdomain Routing > List-post: > List-subscribe: , > List-unsubscribe: , > References: <20120312232702.17194.34028.idtracker at ietfa.amsl.com> > User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) > i have two serious disagreements with this draft. > > o a prefix against which validation has not been run (no validation at > all or some knob turned off) should not be marked Valid. that would > be a lie. it should be marked NotFound. So this this seems to be a split between how we intend to treat unvalidated prefixes and their state. E.G today we'd accept them because the alternative is a rather empty table. tomorrow maybe not. not marking prefixes valid unless they've been validated seems like the least surprise approach. > o routes learned by ibgp and routes originated on this router should > be checked and marked. i do not want to hear from a neighboring noc > that i am originating or propagating garbage. the ibgp case is > particularly egregious in partial deployment, where my ibgp peer may > not be validating at all. not all IBGP sources are under the same domain of control in a big AS, so just as I apply extensive policy controls to routes that I accept from a datacenter for example I imagine myself validating routes that I revived from an ibgp peer at some point if, perhaps not anytime soon. In any event I imagine what gets validated being a product of policy rather than source. > some vendor engs do not seem to realize how extensively ops apply policy > to ibgp. the example i like is that we are driven to it by droids who > sell both local peering and global transit to the same bgp peer. maz > also gave a nice example in a workshop we did here a few years back > . > > randy From hannes@juniper.net Tue Mar 13 03:39:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011E021F87D0 for ; Tue, 13 Mar 2012 03:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2cILHlEsia7 for ; Tue, 13 Mar 2012 03:39:36 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0721F86C4 for ; Tue, 13 Mar 2012 03:39:34 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT18j5WsSbEziyYxsFB79uQALji84a6Ra@postini.com; Tue, 13 Mar 2012 03:39:36 PDT Received: from sa-nc-spg-172.static.jnpr.net (172.23.1.172) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Mar 2012 03:37:25 -0700 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Tue, 13 Mar 2012 11:37:26 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> To: Randy Bush X-Mailer: Apple Mail (2.1257) X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 10:39:37 -0000 On Mar 13, 2012, at 2:27 AM, Randy Bush wrote: >>> o a prefix against which validation has not been run (no validation >>> at all or some knob turned off) should not be marked Valid. that >>> would be a lie. it should be marked NotFound. >> FWIW - the JUNOS implementation has got this 4th state, called >> "Unverified". Unverified is the default state for all prefixes =85 so if you do "fall = off the end" then the system will set it to its default values. > the only problem i see with this is that, if i do not test for it in > policy, i will fall off the end. >=20 > policy-statement route-validation { > term valid { > from { > protocol bgp; > validation-state valid; > } > then { > local-preference 110; > validation-state valid; > accept; > } > } > term invalid { > from { > protocol bgp; > validation-state invalid; > } > then { > local-preference 90; > validation-state invalid; > deny; > } > } > term unknown { > from { =20 > protocol bgp; > validation-state unknown; > } > then { > validation-state unknown; > accept; > } > } > } >=20 > randy From randy@psg.com Tue Mar 13 04:16:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF021F87A4 for ; Tue, 13 Mar 2012 04:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDgZk1kzf3Br for ; Tue, 13 Mar 2012 04:16:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2F69421F878E for ; Tue, 13 Mar 2012 04:16:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7Pid-000Hnf-PY; Tue, 13 Mar 2012 11:16:44 +0000 Date: Tue, 13 Mar 2012 20:16:42 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> User-Agent: Wanderlust/2.15.9 (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=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:16:46 -0000 > Unverified is the default state for all prefixes =E2=80=A6 so if you do "= fall > off the end" then the system will set it to its default values. >> the only problem i see with this is that, if i do not test for it in >> policy, i will fall off the end. >> term unknown { >> from { =20 >> protocol bgp; >> validation-state unknown; >> } >> then { >> validation-state unknown; >> accept; >> } >> } >> } but is that an accept or reject? and whichever you answer, some people would have wanted the other :) randy From wesley.george@twcable.com Tue Mar 13 07:18:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807721F88A0; Tue, 13 Mar 2012 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAtj2Dy8XAgZ; Tue, 13 Mar 2012 07:18:00 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBD621F88A8; Tue, 13 Mar 2012 07:17:59 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,575,1325480400"; d="scan'208";a="352940371" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 13 Mar 2012 10:17:03 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 13 Mar 2012 10:17:33 -0400 From: "George, Wes" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Tue, 13 Mar 2012 10:17:32 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt Thread-Index: Ac0Ap6RFsar2H0CpR2WtVMIn0YwcwgAeXJkw Message-ID: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> In-Reply-To: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:18:00 -0000 Not replying to a specific message, since I'm replying to several issues si= multaneously. In section 2: "No ROA can match an origin AS number of "NONE". No Route can match a ROA whose origin AS number is zero." I'm wondering if there should be a 2119 normative or two in there? This sou= nds like a validation instruction. (eg MUST/SHOULD declare prefixes covered= by an origin AS number of none/zero invalid) "If validation is not performed on a Route, the implementation SHOULD initialize the validation state of such a route to "Valid"." No. Absolutely not. I agree with Randy that default for unchecked !=3D vali= d. I can manage the handling of unknwon routes via route policy such that d= uring incremental deployment I don't make a decision to prefer valid over u= nknown if that's what you're trying to prevent with this choice. Valid need= s to have an explicit "permit" such that I know categorically that everythi= ng with the status of valid was in fact validated. We already have a status= for the ones that we don't know, whether it's because they weren't validat= ed or aren't participating/no covering ROA exists -- unknown. I don't understand the suggestion of a 4th value NotChecked. What additiona= l information is that providing? I saw Hannes's response regarding JunOS, b= ut I think that's implementation-specific enough that it's not necessary to= codify in the standard. What am I missing? Lastly: "We observe that a Route can be Matched or Covered by more than one ROA. This procedure does not mandate an order in which ROAs must be visited; however, the "validation state" output is fully determined." Is there guidance on this in one of the other documents? If so, please refe= rence it here. Does longest-match still apply? This seems a fairly big ques= tion to simply leave open to implementation. Please apply cluebrick liberally if I'm being thick. Thanks Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, March 12, 2012 7:27 PM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt > > > 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 : BGP Prefix Origin Validation > Author(s) : Pradosh Mohapatra > John Scudder > David Ward > Randy Bush > Rob Austein > Filename : draft-ietf-sidr-pfx-validate-04.txt > Pages : 11 > Date : 2012-03-12 > > To help reduce well-known threats against BGP including prefix mis- > announcing and monkey-in-the-middle attacks, one of the security > requirements is the ability to validate the origination AS of BGP > routes. More specifically, one needs to validate that the AS number > claiming to originate an address prefix (as derived from the AS_PATH > attribute of the BGP route) is in fact authorized by the prefix > holder to do so. This document describes a simple validation > mechanism to partially satisfy this requirement. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Sandra.Murphy@sparta.com Tue Mar 13 07:22:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0F21F88D4 for ; Tue, 13 Mar 2012 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kGJhykBkBcz for ; Tue, 13 Mar 2012 07:22:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id EC78F21F88B4 for ; Tue, 13 Mar 2012 07:22:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2DEMgwQ006168 for ; Tue, 13 Mar 2012 09:22:42 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2DEMfPH031842 for ; Tue, 13 Mar 2012 09:22:42 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 13 Mar 2012 10:22:41 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IA== Date: Tue, 13 Mar 2012 14:22:41 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:22:44 -0000 In the interim meeting, the consensus was that we needed idr to be involved= in any definition and solution for route leaks. It was decided to discuss= a message to the idr wg on the sidr list. Brian Dickson has submitted drafts about route leaks, as he offered in the = meeting. So here is a first draft at a messate to idr. Comments please. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The sidr interim meeting in February discussed the problem of route leaks. While those in the room could recognize route leaks in a diagram, they coul= d not determine a way to determine that from information communicated in BG= P. Proposals to stop route leaks add information to BGP updates that would be = used to restrict the propagation of those updates by the neighbor onward to= providers, customers, peers, etc. This is a change to BGP behavior, which now relies on local configuration o= nly to choose a best path and advertise it. Adding features to stop route = leaks would restrict that advertisement and restrict what local policy coul= d choose. The consensus in the room was that adding a new feature to a protocol as pa= rt of a security protection (i.e., not just ensuring an already defined be= havior but producing brand new behavior) is unwise and leads to problems. The sidr working group requests that idr discuss the route leaks problem wi= th sidr and determine the best path forward. The idr wg should also be aware that drafts have been submitted about route= leaks, so work is underway. http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help= -01 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Sandy= From kotikalapudi.sriram@nist.gov Tue Mar 13 07:39:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5D21F88C5 for ; Tue, 13 Mar 2012 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBtORfzqYS18 for ; Tue, 13 Mar 2012 07:39:38 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 273B521F8857 for ; Tue, 13 Mar 2012 07:39:38 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Mar 2012 10:39:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 13 Mar 2012 10:39:37 -0400 From: "Sriram, Kotikalapudi" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Tue, 13 Mar 2012 10:39:36 -0400 Thread-Topic: route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAABwudQ Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:39:39 -0000 I think your message reads good. Should Brian be encouraged to present his route-leak drafts in the IDR WG meeting? Do we know if he is he planning to? Sriram >-----Original Message----- >From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >Murphy, Sandra >Sent: Tuesday, March 13, 2012 10:23 AM >To: sidr@ietf.org >Subject: [sidr] route leaks message to IDR > >In the interim meeting, the consensus was that we needed idr to be involved in >any definition and solution for route leaks. It was decided to discuss a message to >the idr wg on the sidr list. > >Brian Dickson has submitted drafts about route leaks, as he offered in the >meeting. > >So here is a first draft at a messate to idr. Comments please. > >============== > >The sidr interim meeting in February discussed the problem of route leaks. > >While those in the room could recognize route leaks in a diagram, they could not >determine a way to determine that from information communicated in BGP. > >Proposals to stop route leaks add information to BGP updates that would be used >to restrict the propagation of those updates by the neighbor onward to providers, >customers, peers, etc. > >This is a change to BGP behavior, which now relies on local configuration only to >choose a best path and advertise it. Adding features to stop route leaks would >restrict that advertisement and restrict what local policy could choose. > >The consensus in the room was that adding a new feature to a protocol as part of >a security protection (i.e., not just ensuring an already defined behavior but >producing brand new behavior) is unwise and leads to problems. > >The sidr working group requests that idr discuss the route leaks problem with sidr >and determine the best path forward. > >The idr wg should also be aware that drafts have been submitted about route >leaks, so work is underway. > >http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01 >http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 >http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 >http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 > >=================== > >--Sandy >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From hannes@juniper.net Tue Mar 13 07:58:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DDA21F86E8 for ; Tue, 13 Mar 2012 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtyDdCwVuBJT for ; Tue, 13 Mar 2012 07:58:58 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id D1C2421F86D9 for ; Tue, 13 Mar 2012 07:58:57 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT19gr7M8fqgpEbHjsWHkxERBf9z6AdNK@postini.com; Tue, 13 Mar 2012 07:58:57 PDT Received: from ubuntu (172.23.1.172) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Mar 2012 07:58:27 -0700 Received: by ubuntu (Postfix, from userid 1000) id 2A543295AF; Tue, 13 Mar 2012 15:58:27 +0100 (CET) Date: Tue, 13 Mar 2012 15:58:27 +0100 From: Hannes Gredler To: Randy Bush Message-ID: <20120313145826.GB3557@juniper.net> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> <0589BCF9-C6C2-4CE5-AF8F-0896A285608C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:58:58 -0000 On Tue, Mar 13, 2012 at 08:16:42PM +0900, Randy Bush wrote: | > Unverified is the default state for all prefixes … so if you do "fall | > off the end" then the system will set it to its default values. | >> the only problem i see with this is that, if i do not test for it in | >> policy, i will fall off the end. | >> term unknown { | >> from { | >> protocol bgp; | >> validation-state unknown; | >> } | >> then { | >> validation-state unknown; | >> accept; | >> } | >> } | >> } | | but is that an accept or reject? and whichever you answer, some people | would have wanted the other :) depends on the route. consider that this is a BGP route and this is a a BGP import policy then the system implicitly sets the default acction to accept; this is system default (since JUNOS 3.3 ;-)) From pmohapat@cisco.com Tue Mar 13 13:06:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FB121F86B5; Tue, 13 Mar 2012 13:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfrgWtvj+LID; Tue, 13 Mar 2012 13:06:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCD21F86AA; Tue, 13 Mar 2012 13:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1214; q=dns/txt; s=iport; t=1331669210; x=1332878810; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NJlEkYZ1nLjfp1FGVICA2eKNmLLzMVchDrhw5TknyJI=; b=FYIaZnG7bWo/751Khw3caQmGKeQb71XbUUjoCrDmbpiByhEvbFCH6w0Y xaMGDg7tlr6w1FvgFCL+LhDBy1n/3WRxKFM4cz8dq8yj2dQ4tHoaYOO0I t4B2YAz3aZ41x7M2TQfWdxwTQNVYWVj/pYr1sgGXKCfFzeVzY1sGRBWmf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAAeoX0+rRDoH/2dsb2JhbABDgwmyY4EHggkBAQEDARIBJQI/BQsLRlcGNYdjBJx0AZ59kAJjBIhVjHuFaYo6gwWBNhc X-IronPort-AV: E=Sophos;i="4.73,579,1325462400"; d="scan'208";a="32935019" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Mar 2012 20:06:50 +0000 Received: from [10.155.35.3] ([10.155.35.3]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DK6oCV008833; Tue, 13 Mar 2012 20:06:50 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: Date: Tue, 13 Mar 2012 13:07:20 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> To: "George, Wes" X-Mailer: Apple Mail (2.1075.2) Cc: "sidr@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:06:52 -0000 Hi Wes, > In section 2: > "No ROA can match an origin > AS number of "NONE". No Route can match a ROA whose origin AS > number is zero." > > I'm wondering if there should be a 2119 normative or two in there? > This sounds like a validation instruction. (eg MUST/SHOULD declare > prefixes covered by an origin AS number of none/zero invalid) Could you suggest text with 2119 language? > Lastly: > "We observe that a Route can be Matched or Covered by more than one > ROA. This procedure does not mandate an order in which ROAs must be > visited; however, the "validation state" output is fully > determined." > Is there guidance on this in one of the other documents? If so, > please reference it here. Does longest-match still apply? This seems > a fairly big question to simply leave open to implementation. > Please apply cluebrick liberally if I'm being thick. I looked around in sidr-usecases and origin-ops, but couldn't find an example. May be we should add one. But is there anything that you are specifically worried about? All that the text says is that ordering is not relevant. It's a classic OR operation for the match. - Pradosh From randy@psg.com Tue Mar 13 14:03:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B174A21F862F for ; Tue, 13 Mar 2012 14:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UsZN3QTVV-f for ; Tue, 13 Mar 2012 14:03:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F05CD21F862B for ; Tue, 13 Mar 2012 14:03:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7YsI-000JG1-Jv; Tue, 13 Mar 2012 21:03:18 +0000 Date: Wed, 14 Mar 2012 06:03:17 +0900 Message-ID: From: Randy Bush To: Wes George In-Reply-To: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 21:03:20 -0000 > "We observe that a Route can be Matched or Covered by more than one > ROA. This procedure does not mandate an order in which ROAs must be > visited; however, the "validation state" output is fully determined." > > Is there guidance on this in one of the other documents? If so, please > reference it here. Does longest-match still apply? This seems a fairly > big question to simply leave open to implementation. you want the inclusive or, if any one matches it's Valid. otherwise, you can not do a make-before-break provider switch, for example. as to the matching rules, i have extracted a few slides from a recent hands-on workshop, see . randy From jayb@zoe.braeburn.org Tue Mar 13 19:18:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9847821F84D2 for ; Tue, 13 Mar 2012 19:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP5QsnYZsj9y for ; Tue, 13 Mar 2012 19:18:53 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id BF1B021F84CF for ; Tue, 13 Mar 2012 19:18:52 -0700 (PDT) X-Env-Sender: jayb@zoe.braeburn.org X-Msg-Ref: server-6.tower-119.messagelabs.com!1331691530!18641873!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11807 invoked from network); 14 Mar 2012 02:18:50 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2012 02:18:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2E2JKbF007001 for ; Tue, 13 Mar 2012 22:19:20 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2E2JHtk006984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 22:19:17 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 13 Mar 2012 22:18:20 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2E2IK2j002220 for ; Tue, 13 Mar 2012 22:18:20 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2E2IIvT002151 for ; Tue, 13 Mar 2012 22:18:18 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id DD0F62BF2C; Tue, 13 Mar 2012 22:18:17 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20319.65510.564622.734169@oz.mt.att.com> Date: Tue, 13 Mar 2012 22:18:14 -0400 From: Jay Borkenhagen To: sidr@ietf.org In-Reply-To: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 Sender: jayb@zoe.braeburn.org X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 02:18:53 -0000 I also have some problems with aspects of the draft-ietf-sidr-pfx-validate-04.txt draft, particularly this bit from Section 2: When a BGP speaker receives an UPDATE from one of its EBGP peers, it SHOULD perform a lookup as described above for each of the Routes in the UPDATE message. [...] This procedure SHOULD NOT be performed for Routes learned from peers of types other than EBGP. ... and this from Section 5: In some cases (particularly when the selection algorithm is influenced by the adjustment of a route property that is not propagated into IBGP) it could be necessary for routing correctness to propagate the validation state to the IBGP peer. [...] Regarding the latter: What kind of route property is envisioned that is not propagated into IBGP, but _is_ propagated via EBGP? Regarding the former: I expect many networks to be faced with partial-deployment of origin validation for some time: some older edge routers will never be upgraded to be rpki-cognizant, while most newer edges and route reflectors will be. When a route reflector learns a route from an rpki-ignorant edge, I would want the RR to perform its own origin validation, deciding the validation state based on its own local cache. But taking this further: why _wouldn't_ we want the RR to perform the same origin validation on every prefix it learns, based again on contents of local cache and local policy? I think we would. Going still further: rpki-cognizant edge routers should themselves perform origin validation on all BGP-learned routes, even those learned via IBGP from RRs. At a minimum, if the draft's authors persist in recommending that origin validation is only for EBGP, they should describe why that is. Jay B. From wesley.george@twcable.com Wed Mar 14 06:55:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2286F21F8789 for ; Wed, 14 Mar 2012 06:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq-g+fMEoZPf for ; Wed, 14 Mar 2012 06:55:41 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6808621F8514 for ; Wed, 14 Mar 2012 06:55:41 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,583,1325480400"; d="scan'208";a="337121094" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 14 Mar 2012 09:54:51 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 14 Mar 2012 09:55:40 -0400 From: "George, Wes" To: Randy Bush Date: Wed, 14 Mar 2012 09:55:39 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt Thread-Index: Ac0BXLlx92KJm0CpT5CbS84ZSlzm0gAjJ1Aw Message-ID: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:55:42 -0000 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, March 13, 2012 5:03 PM > > you want the inclusive or, if any one matches it's Valid. otherwise, > you can not do a make-before-break provider switch, for example. > > as to the matching rules, i have extracted a few slides from a recent > hands-on workshop, see . > > randy [WEG] makes perfect sense, thanks. Do you think that it's worth saying this= more explicitly here? Something like - " We observe that a Route can be Matched or Covered by more than one ROA. This procedure does not mandate an order in which ROAs must be Visited, because the match is a logical OR, which makes the order irrelev= ant. This enables, among other things, a make-before-break change for such = things as changing providers." Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nlniyer2@gmail.com Wed Mar 14 07:20:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793D221F881F for ; Wed, 14 Mar 2012 07:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpLD6e4Vta8I for ; Wed, 14 Mar 2012 07:20:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA0FD21F881E for ; Wed, 14 Mar 2012 07:20:25 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2424281vcb.31 for ; Wed, 14 Mar 2012 07:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rSGvz7/cq4vhB4Bs+7Kjv6SWZoNOBvFFjqyiV2uyG0c=; b=AWyPTIKKo+8n8JWLsMfFOq9wnkGXeipbkV5uKeneSp1+2SCRBn10z3AV8knBtl/2eG 3I3cPyScuQN3cj/mhi4zEi9shGisSGw4NwG+WLrfn2Ex5YxH4bDG3zrogCRtWDqnVjsy x0Ot7QkyU77J5EV6J6kT02znIlqzX6ku3FdqTuUO1HQ66YhWja3qdRlAgIXKic0Lxn/m aSHfR0PRYebtKWto3LApVLmEdQfEcJIQdZ1SEfguw7DxKcS2anw8bZuupDcrFL8Yq0Mq daeysf+JrNxBdlJ/cYHpDiyqKDWpiUXwVxFXoBq5sjk1E16NcVdk9Dodj22D2GuRZZa+ 9u+A== MIME-Version: 1.0 Received: by 10.52.71.80 with SMTP id s16mr1901339vdu.131.1331734825362; Wed, 14 Mar 2012 07:20:25 -0700 (PDT) Received: by 10.220.151.205 with HTTP; Wed, 14 Mar 2012 07:20:25 -0700 (PDT) Date: Wed, 14 Mar 2012 10:20:25 -0400 Message-ID: From: nalini iyer To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] question on SKI and router public key retrieval in signature attribute in BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:20:26 -0000 Sorry for asking this but despite looking at likely sources off the documents list on the SIDR page am still in the dark, and would like to confirm suspicions. The SKI in the signature attribute is a hash of the signing router's public key, a) Is this hashed with the CA's pvt key? b) How is the corresponding CA certificate (to de-hash the SKI) obtained? c) From where is the router EE cert identified by the SKI then obtained, or is getting the router's cert considered unnecessary as the router public key is contained in the de-hashed SKI? thank you, N.I. From kotikalapudi.sriram@nist.gov Wed Mar 14 07:39:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239A721F87F2 for ; Wed, 14 Mar 2012 07:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyQU5cz7d4GI for ; Wed, 14 Mar 2012 07:39:26 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6121F87F9 for ; Wed, 14 Mar 2012 07:39:26 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Mar 2012 10:39:19 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 14 Mar 2012 10:39:24 -0400 From: "Sriram, Kotikalapudi" To: Pradosh Mohapatra , "George, Wes" Date: Wed, 14 Mar 2012 10:39:24 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt Thread-Index: Ac0BVF2r+7U+BcpLRESDaDL9EmbMdQAlw2gA Message-ID: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:39:27 -0000 >> "We observe that a Route can be Matched or Covered by more than one >> ROA. This procedure does not mandate an order in which ROAs must be >> visited; however, the "validation state" output is fully >> determined." >> Is there guidance on this in one of the other documents? If so, >> please reference it here. Does longest-match still apply? This seems >> a fairly big question to simply leave open to implementation. >> Please apply cluebrick liberally if I'm being thick. > > >I looked around in sidr-usecases and origin-ops, but couldn't find an >example. May be we should add one. But is there anything that you are >specifically worried about? All that the text says is that ordering is >not relevant. It's a classic OR operation for the match. I agree that it is an "OR" operation in general. Let me just note that in Section 7.2 in the sidr-usecases document, we talked about use cases when a cert expires or a CRL is received that affects a ROA and in turn affects an existing BGP update that was validated with support of that ROA. Then the relying party should check if there is another ROA (or another entry in ROA white-list) for a parent (i.e., less specific) prefix that may sustain the "Valid" status for the update in question. Perhaps the sidr-pfx-validate document should also talk about what the algorithm should do in reaction to a cert expiry or CRL receipt or an RPKI-rtr withdraw message (for a ROA white-list entry)? Sriram From kent@bbn.com Wed Mar 14 08:24:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9561521F86FA for ; Wed, 14 Mar 2012 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.443 X-Spam-Level: X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQPH20NX1t6G for ; Wed, 14 Mar 2012 08:24:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7F21F86F8 for ; Wed, 14 Mar 2012 08:24:43 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49168) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7q41-0004nS-TQ; Wed, 14 Mar 2012 11:24:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Mar 2012 11:09:52 -0400 To: nalini iyer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] question on SKI and router public key retrieval in signature attribute in BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:24:44 -0000 At 10:20 AM -0400 3/14/12, nalini iyer wrote: >Sorry for asking this but despite looking at likely sources off the >documents list on the SIDR page am still in the dark, and would like >to confirm suspicions. > >The SKI in the signature attribute is a hash of the signing router's >public key, yes, and it is computed as described in RFC 5280, 4.2.1.2. > >a) Is this hashed with the CA's pvt key? no. a one-way hash function (in contrast to a hash-based MAC function such as HMAC) does not make use of a key. And, hash-based MACs used symmetric keys, not private keys of a public key pair. >b) How is the corresponding CA certificate (to de-hash the SKI) obtained? de-hash? the SKI for the router's cert is verified using the router's cert, not using the cert of the CA that issued the router's cert. anyway, the CA cert under which the router's cert was issued would be obtained from the RPKI repository, as it is the CA cert associated with the ISP operating the router. >c) From where is the router EE cert identified by the SKI then >obtained, or is getting the router's cert considered unnecessary as >the router public key is contained in the de-hashed SKI? >thank you, as above, router certs are obtained from the RPKI repository system. Steve From wesley.george@twcable.com Wed Mar 14 08:57:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7C21F85D6; Wed, 14 Mar 2012 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUBbXJguTPan; Wed, 14 Mar 2012 08:57:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 14AEA21F85CC; Wed, 14 Mar 2012 08:57:42 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,584,1325480400"; d="scan'208";a="353624045" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Mar 2012 11:56:37 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 14 Mar 2012 11:57:09 -0400 From: "George, Wes" To: Pradosh Mohapatra Date: Wed, 14 Mar 2012 11:57:06 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt Thread-Index: Ac0BVNUs+c6Dnf/3TK2U3kLseh4cmAAlVvvA Message-ID: References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:57:44 -0000 > -----Original Message----- > From: Pradosh Mohapatra [mailto:pmohapat@cisco.com] > Sent: Tuesday, March 13, 2012 4:07 PM > To: George, Wes > Cc: internet-drafts@ietf.org; i-d-announce@ietf.org; sidr@ietf.org > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt > > > In section 2: > > "No ROA can match an origin > > AS number of "NONE". No Route can match a ROA whose origin AS > > number is zero." > > > > I'm wondering if there should be a 2119 normative or two in there? > > This sounds like a validation instruction. (eg MUST/SHOULD declare > > prefixes covered by an origin AS number of none/zero invalid) > > > Could you suggest text with 2119 language? [WEG] Originally I stopped short of fully suggesting text because I didn't = think that I had a complete grasp of what the authors are suggesting should= happen here based on the combination of the text above. In rereading the surrounding text to make another attempt at it, I don't th= ink that this sentence belongs in the definition for Route Origin ASN at al= l, because it's not really part of the definition. This is instructional ab= out a special case of match/cover, and should probably be moved down a few = sentences to where you talk about valid/invalid/unknown. The same is also t= rue for the following from the definition of Matched. "keeping in mind that a ROA ASN of zero can never be matched, nor c= an a route origin AS number of "NONE"." So I would strike the references to ASN 0 and origin AS NONE from the defin= itions altogether, and then reword the next section as follows: CURRENT TEXT " Given these definitions, any given BGP Route will be found to have one of the following "validation states": o NotFound: No ROA Covers the Route Prefix. o Valid: At least one ROA Matches the Route Prefix. o Invalid: At least one ROA Covers the Route Prefix, but no ROA Matches it." NEW TEXT "Given these definitions, any given BGP route MUST [SHOULD?] be found to ha= ve one of the following "validation states": o NotFound: No ROA Covers the Route Prefix. o Valid: At least one ROA Matches the Route Prefix. o Invalid: At least one ROA Covers the Route Prefix, but no ROA Matches it. It should be noted that a ROA ASN of zero or a route origin AS number of "N= ONE" MUST NOT ever be considered matches. This means that routes with a cov= ering ROA ASN of zero MUST be declared Invalid, and routes with a route ori= gin AS number of "NONE" and one or more covering ROAs MUST be declared Inva= lid." Is that a reasonably accurate interpretation of the intent? > > > Lastly: > > "We observe that a Route can be Matched or Covered by more than one > > ROA. This procedure does not mandate an order in which ROAs must be > > visited; however, the "validation state" output is fully > > determined." > > Is there guidance on this in one of the other documents? If so, > > please reference it here. Does longest-match still apply? This seems > > a fairly big question to simply leave open to implementation. > > Please apply cluebrick liberally if I'm being thick. > > > I looked around in sidr-usecases and origin-ops, but couldn't find an > example. May be we should add one. But is there anything that you are > specifically worried about? All that the text says is that ordering is > not relevant. It's a classic OR operation for the match. [WEG] I didn't get "ordering not relevant" from the current text, but now t= hat you say it, I see how it could be interpreted that way. See my suggeste= d change as a reply to Randy's explanation. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Wed Mar 14 09:49:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB221F8624 for ; Wed, 14 Mar 2012 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2KiCiVy+vOu for ; Wed, 14 Mar 2012 09:49:10 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4482021F8600 for ; Wed, 14 Mar 2012 09:49:10 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,584,1325480400"; d="scan'208";a="337257270" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 14 Mar 2012 12:48:20 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 14 Mar 2012 12:49:09 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Wed, 14 Mar 2012 12:49:08 -0400 Thread-Topic: route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAA3lj8w Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:49:11 -0000 I'm basically fine with the wording below. The only thing I might add would= be some mention of the reason why we're talking about route leaks, why the= y're considered a problem that should be solved in the context of SIDR, etc= - mainly that there are those among the WG and operator community that bel= ieve BGPSec as currently proposed is incomplete without a method to prevent= route leaks, and given the costs to deploy and manage BGPSec, the inabilit= y to protect against this problem limits its attractiveness for deployment. This is covered in detail in the referenced drafts, but is worth including = in the summary text. Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Tuesday, March 13, 2012 10:23 AM > To: sidr@ietf.org > Subject: [sidr] route leaks message to IDR > > In the interim meeting, the consensus was that we needed idr to be involv= ed in > any definition and solution for route leaks. It was decided to discuss a > message to the idr wg on the sidr list. > > Brian Dickson has submitted drafts about route leaks, as he offered in th= e > meeting. > > So here is a first draft at a messate to idr. Comments please. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The sidr interim meeting in February discussed the problem of route leaks= . > > While those in the room could recognize route leaks in a diagram, they co= uld > not determine a way to determine that from information communicated in BG= P. > > Proposals to stop route leaks add information to BGP updates that would b= e > used to restrict the propagation of those updates by the neighbor onward = to > providers, customers, peers, etc. > > This is a change to BGP behavior, which now relies on local configuration= only > to choose a best path and advertise it. Adding features to stop route le= aks > would restrict that advertisement and restrict what local policy could ch= oose. > > The consensus in the room was that adding a new feature to a protocol as = part > of a security protection (i.e., not just ensuring an already defined beh= avior > but producing brand new behavior) is unwise and leads to problems. > > The sidr working group requests that idr discuss the route leaks problem = with > sidr and determine the best path forward. > > The idr wg should also be aware that drafts have been submitted about rou= te > leaks, so work is underway. > > http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-he= lp-01 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Sandra.Murphy@sparta.com Wed Mar 14 10:16:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3973F21F86EF for ; Wed, 14 Mar 2012 10:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4GbM+BUsmAi for ; Wed, 14 Mar 2012 10:16:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F42821F86AD for ; Wed, 14 Mar 2012 10:16:00 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2EHFxCC018809 for ; Wed, 14 Mar 2012 12:15:59 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2EHFxxZ006907 for ; Wed, 14 Mar 2012 12:15:59 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 13:15:58 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] question on SKI and router public key retrieval in signature attribute in BGPSEC Thread-Index: AQHNAe2dMJJAJLI6IEaTkCDFY5H/dJZp2cxfgAAuHic= Date: Wed, 14 Mar 2012 17:15:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7C9D@Hermes.columbia.ads.sparta.com> References: , <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7BEA@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7BEA@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] FW: question on SKI and router public key retrieval in signature attribute in BGPSEC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:16:01 -0000 Sorry, did not reply to the list. --Sandy ________________________________________ From: Murphy, Sandra Sent: Wednesday, March 14, 2012 10:40 AM To: nalini iyer Subject: RE: [sidr] question on SKI and router public key retrieval in sign= ature attribute in BGPSEC Speaking as regular ol' member. If I understand your questions correctly: (a) This is just a hash, not a signature or MAC - no key required (b) There is no de-hashing of the SKI - it is just a way to index into your= pile of certs to find the right one. (c) Again, no de-hashing of the key - the SKI is a way to identify the righ= t certificate. See page 18 of the protocol spec: o (Step I): Locate the public key needed to verify the signature (in the current Signature-Segment). To do this, consult the valid RPKI end-entity certificate data and look for an SKI that matches the value in the Subject Key Identifier 1 field of the Signature- Segment. And section 4.8.2 page 9 of rfc6487 (the old res-certs draft) The Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the Subject Public Key, as described in Section 4.2.1.2 of [RFC5280]. No key involved. Just a cryptographic hash. No crypto operations, just an= indexing/matching into a store of data. --Sandy, speaking as regular ol' member ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of nalini iye= r [nlniyer2@gmail.com] Sent: Wednesday, March 14, 2012 10:20 AM To: sidr@ietf.org Subject: [sidr] question on SKI and router public key retrieval in signatur= e attribute in BGPSEC Sorry for asking this but despite looking at likely sources off the documents list on the SIDR page am still in the dark, and would like to confirm suspicions. The SKI in the signature attribute is a hash of the signing router's public= key, a) Is this hashed with the CA's pvt key? b) How is the corresponding CA certificate (to de-hash the SKI) obtained? c) From where is the router EE cert identified by the SKI then obtained, or is getting the router's cert considered unnecessary as the router public key is contained in the de-hashed SKI? thank you, N.I. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr= From eosterweil@verisign.com Wed Mar 14 11:38:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAADE21F87AB for ; Wed, 14 Mar 2012 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgYt0zsB-t1F for ; Wed, 14 Mar 2012 11:38:20 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6ED21F8657 for ; Wed, 14 Mar 2012 11:38:17 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKT2DlkoHCKBKgGF1XFkaFDNETmPHElUAi@postini.com; Wed, 14 Mar 2012 11:38:20 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2EIc6HN003418; Wed, 14 Mar 2012 14:38:06 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.34]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:38:06 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 14 Mar 2012 19:38:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Mar 2012 18:38:06.0428 (UTC) FILETIME=[98C3C9C0:01CD0211] Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:38:21 -0000 I'd also like to add that (if I'm not mistaken) much of the BGPSEC work = is _already_ proposing to "add information to BGP updates." For = example, I'm pretty sure there aren't any signatures in BGP right now, = right? I don't think this text is completely on the level, because my = recollection of many of the sidr drafts is that they _ARE_ proposing to = add data, semantics, and processes to the current operation of BGP. By = my reading of the text below, it sounds like we would only add these = things if we were going to add route leak protection, and that sentiment = seems wrong to me. Moreover, the text below conflates the need for leak = protection with some as-yet-unspecified approach that must use inline = protocol changes. I don't know that this has been openly agreed to by = all (which is fine at this stage), but in reaching out to grow w/ this = as a starting point I think we present both a problem and an unratified = straw-man. I think the text needs to be clarified. =20 Also, I'd like to request in the 5th para (or the 6th sentence?): s/The consensus in the room was/The consensus in the room = (though it is not clear what portion of the wg agrees) was/ Thanks, Eric On Mar 14, 2012, at 5:49 PM, George, Wes wrote: > I'm basically fine with the wording below. The only thing I might add = would be some mention of the reason why we're talking about route leaks, = why they're considered a problem that should be solved in the context of = SIDR, etc - mainly that there are those among the WG and operator = community that believe BGPSec as currently proposed is incomplete = without a method to prevent route leaks, and given the costs to deploy = and manage BGPSec, the inability to protect against this problem limits = its attractiveness for deployment. >=20 > This is covered in detail in the referenced drafts, but is worth = including in the summary text. >=20 > Thanks, >=20 > Wes >=20 >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >> Murphy, Sandra >> Sent: Tuesday, March 13, 2012 10:23 AM >> To: sidr@ietf.org >> Subject: [sidr] route leaks message to IDR >>=20 >> In the interim meeting, the consensus was that we needed idr to be = involved in >> any definition and solution for route leaks. It was decided to = discuss a >> message to the idr wg on the sidr list. >>=20 >> Brian Dickson has submitted drafts about route leaks, as he offered = in the >> meeting. >>=20 >> So here is a first draft at a messate to idr. Comments please. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The sidr interim meeting in February discussed the problem of route = leaks. >>=20 >> While those in the room could recognize route leaks in a diagram, = they could >> not determine a way to determine that from information communicated = in BGP. >>=20 >> Proposals to stop route leaks add information to BGP updates that = would be >> used to restrict the propagation of those updates by the neighbor = onward to >> providers, customers, peers, etc. >>=20 >> This is a change to BGP behavior, which now relies on local = configuration only >> to choose a best path and advertise it. Adding features to stop = route leaks >> would restrict that advertisement and restrict what local policy = could choose. >>=20 >> The consensus in the room was that adding a new feature to a protocol = as part >> of a security protection (i.e., not just ensuring an already defined = behavior >> but producing brand new behavior) is unwise and leads to problems. >>=20 >> The sidr working group requests that idr discuss the route leaks = problem with >> sidr and determine the best path forward. >>=20 >> The idr wg should also be aware that drafts have been submitted about = route >> leaks, so work is underway. >>=20 >> = http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-hel= p-01 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> --Sandy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > 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 From weiler@watson.org Wed Mar 14 13:19:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777721F8772 for ; Wed, 14 Mar 2012 13:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=1.153, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJIFBhtUbfO7 for ; Wed, 14 Mar 2012 13:19:55 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id AE55C21F8767 for ; Wed, 14 Mar 2012 13:19:55 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2EKJsqf057665; Wed, 14 Mar 2012 16:19:54 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2EKJrxD057661; Wed, 14 Mar 2012 16:19:54 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 14 Mar 2012 16:19:53 -0400 (EDT) From: Samuel Weiler To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4@Hermes.columbia.ads.sparta.com> Message-ID: References: <2123587110.18271331158152285.JavaMail.nobody@grsj2rmd005.webex.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EB4@Hermes.columbia.ads.sparta.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 14 Mar 2012 16:19:54 -0400 (EDT) Cc: "sidr@ietf.org" Subject: Re: [sidr] FW: Invitation to Web seminar: Virtual meeting - Mar 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:19:56 -0000 On Wed, 7 Mar 2012, Murphy, Sandra wrote: > The co-chairs have arranged a virtual meeting for Mar 24, 2012. ... > Saturday, March 24, 2012 8:00 am, GMT Time (London, GMT) Given the season, a caution is in order: Europe is not yet on daylight savings time, but the US is. This meeting is scheduled to start at 9am local time in Paris, 4am local time in New York, and 1am local time in SFO. Daylight savings time in Paris starts on Sunday, 25 March, the day AFTER this meeting. -- Sam From Sandra.Murphy@sparta.com Wed Mar 14 13:24:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794EF21F8823 for ; Wed, 14 Mar 2012 13:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EYkI6IiczNh for ; Wed, 14 Mar 2012 13:24:38 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9216C21F8822 for ; Wed, 14 Mar 2012 13:24:38 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2EKObZG021074; Wed, 14 Mar 2012 15:24:37 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2EKOa2p013702; Wed, 14 Mar 2012 15:24:36 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 16:24:36 -0400 From: "Murphy, Sandra" To: Eric Osterweil , "George, Wes" Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAA3lj8wAA1+0AD//8zZTQ== Date: Wed, 14 Mar 2012 20:24:36 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> , <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> In-Reply-To: <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:24:40 -0000 I am afraid that you missed the point that I was trying to make. Adding information is not the problem. Adding a new *routing feature* is the problem. BGP presently has no feature that lets the sender restrict where the receiv= er might propagate a route. So the security protections would have to in= vent the feature and secure it at the same time. The consensus of the meeting was that this is a bad way to do design. Addi= ng a new feature as part of adding a new security protection has been found= to lead to problems. =20 Note that the current sidr work does not conflict with this. The protectio= ns we are developing are there to protect features that already exist in th= e BGP spec, but are vulnerable to misuse. The protections eliminate "bad" = behavior, but they do not produce new routing features. Wrt the interim meeting. The minutes and jabber logs are available. Comme= nting on the list is always possible. The drafts were mentioned to show that people are actively beginning to wor= k on this, not as pointers to a candidate. The message below asks for idr's (not grow's) consideration of how to proce= ed. Do you have some objection to idr being part of the definition of a ne= w routing feature? --Sandy ________________________________________ From: Eric Osterweil [eosterweil@verisign.com] Sent: Wednesday, March 14, 2012 2:38 PM To: George, Wes Cc: Murphy, Sandra; sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is = _already_ proposing to "add information to BGP updates." For example, I'm = pretty sure there aren't any signatures in BGP right now, right? I don't t= hink this text is completely on the level, because my recollection of many = of the sidr drafts is that they _ARE_ proposing to add data, semantics, and= processes to the current operation of BGP. By my reading of the text belo= w, it sounds like we would only add these things if we were going to add ro= ute leak protection, and that sentiment seems wrong to me. Moreover, the t= ext below conflates the need for leak protection with some as-yet-unspecifi= ed approach that must use inline protocol changes. I don't know that this = has been openly agreed to by all (which is fine at this stage), but in reac= hing out to grow w/ this as a starting point I think we present both a prob= lem and an unratified straw-man. I think the text needs to be clarified. Also, I'd like to request in the 5th para (or the 6th sentence?): s/The consensus in the room was/The consensus in the room (though i= t is not clear what portion of the wg agrees) was/ Thanks, Eric On Mar 14, 2012, at 5:49 PM, George, Wes wrote: > I'm basically fine with the wording below. The only thing I might add wou= ld be some mention of the reason why we're talking about route leaks, why t= hey're considered a problem that should be solved in the context of SIDR, e= tc - mainly that there are those among the WG and operator community that b= elieve BGPSec as currently proposed is incomplete without a method to preve= nt route leaks, and given the costs to deploy and manage BGPSec, the inabil= ity to protect against this problem limits its attractiveness for deploymen= t. > > This is covered in detail in the referenced drafts, but is worth includin= g in the summary text. > > Thanks, > > Wes > > >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >> Murphy, Sandra >> Sent: Tuesday, March 13, 2012 10:23 AM >> To: sidr@ietf.org >> Subject: [sidr] route leaks message to IDR >> >> In the interim meeting, the consensus was that we needed idr to be invol= ved in >> any definition and solution for route leaks. It was decided to discuss = a >> message to the idr wg on the sidr list. >> >> Brian Dickson has submitted drafts about route leaks, as he offered in t= he >> meeting. >> >> So here is a first draft at a messate to idr. Comments please. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> The sidr interim meeting in February discussed the problem of route leak= s. >> >> While those in the room could recognize route leaks in a diagram, they c= ould >> not determine a way to determine that from information communicated in B= GP. >> >> Proposals to stop route leaks add information to BGP updates that would = be >> used to restrict the propagation of those updates by the neighbor onward= to >> providers, customers, peers, etc. >> >> This is a change to BGP behavior, which now relies on local configuratio= n only >> to choose a best path and advertise it. Adding features to stop route l= eaks >> would restrict that advertisement and restrict what local policy could c= hoose. >> >> The consensus in the room was that adding a new feature to a protocol as= part >> of a security protection (i.e., not just ensuring an already defined be= havior >> but producing brand new behavior) is unwise and leads to problems. >> >> The sidr working group requests that idr discuss the route leaks problem= with >> sidr and determine the best path forward. >> >> The idr wg should also be aware that drafts have been submitted about ro= ute >> leaks, so work is underway. >> >> http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-h= elp-01 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 >> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> --Sandy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > 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 kent@bbn.com Wed Mar 14 13:51:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B321E800C for ; Wed, 14 Mar 2012 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD8fkTPQyHPt for ; Wed, 14 Mar 2012 13:51:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF3B21E8045 for ; Wed, 14 Mar 2012 13:51:51 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49182) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S7vAY-000Eo9-Vs; Wed, 14 Mar 2012 16:51:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> Date: Wed, 14 Mar 2012 16:50:20 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:51:53 -0000 At 7:38 PM +0100 3/14/12, Eric Osterweil wrote: >I'd also like to add that (if I'm not mistaken) much of the BGPSEC >work is _already_ proposing to "add information to BGP updates." >For example, I'm pretty sure there aren't any signatures in BGP >right now, right? The addition of sigs to provide integrity and authentication for AS_path info does not add new semantics to BGP. The sigs are used to secure the existing semantics. I think that's what Sandy meant to convey in her message, but maybe the wording needs to be improved. > I don't think this text is completely on the level, because my >recollection of many of the sidr drafts is that they _ARE_ proposing >to add data, semantics, and processes to the current operation of >BGP. New data, yes, new semantics, no. We were heading in that direction with the "beaconing" mechanism, but that seems to have gone away. > By my reading of the text below, it sounds like we would only add >these things if we were going to add route leak protection, and that >sentiment seems wrong to me. Add which "things?" > Moreover, the text below conflates the need for leak protection >with some as-yet-unspecified approach that must use inline protocol >changes. That is a fair observation, i.e., if there is agreement that route leaks can be defined in a rigorous, unambiguous fashion, then it is appropriate to explore various ways of detecting them. > I don't know that this has been openly agreed to by all (which is >fine at this stage), but in reaching out to grow w/ this as a >starting point I think we present both a problem and an unratified >straw-man. I think the text needs to be clarified. I think the message asks IDR to look into this, not GROW. > >Also, I'd like to request in the 5th para (or the 6th sentence?): > s/The consensus in the room was/The consensus in the room >(though it is not clear what portion of the wg agrees) was/ seems like a reasonable edit. Steve From Sandra.Murphy@sparta.com Wed Mar 14 14:23:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC1321F886F for ; Wed, 14 Mar 2012 14:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHTpXpI4dLBE for ; Wed, 14 Mar 2012 14:23:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 62BBD21F8869 for ; Wed, 14 Mar 2012 14:23:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2ELN6Br021866 for ; Wed, 14 Mar 2012 16:23:06 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2ELN6uU016093 for ; Wed, 14 Mar 2012 16:23:06 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 17:23:05 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda uploaded Thread-Index: Ac0CKKRH/j4ttSAESZiByPsdD6tmQw== Date: Wed, 14 Mar 2012 21:23:04 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7DAB@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:23:12 -0000 A draft agenda for the IETF 83 meeting has been uploaded. If you believe that you requested time on the agenda, or you want to make a= request to be on the agenda, there's still time to contact the chairs and/= or list. There may be movement of presentations to accommodate the presenters or to = make room for additional presentations. So stay tuned for the final agenda= . --Sandy= From eosterweil@verisign.com Wed Mar 14 14:31:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08E611E8087 for ; Wed, 14 Mar 2012 14:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJI5Qr-4jztU for ; Wed, 14 Mar 2012 14:31:25 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC111E807F for ; Wed, 14 Mar 2012 14:31:22 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKT2EOKjJC+xRYdvz0JczWoVFn2DLee2AT@postini.com; Wed, 14 Mar 2012 14:31:24 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2ELVH0c008709; Wed, 14 Mar 2012 17:31:17 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.34]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 17:31:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> Date: Wed, 14 Mar 2012 22:31:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> , <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Mar 2012 21:31:17.0428 (UTC) FILETIME=[CA488F40:01CD0229] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:31:25 -0000 On Mar 14, 2012, at 9:24 PM, Murphy, Sandra wrote: > I am afraid that you missed the point that I was trying to make. >=20 > Adding information is not the problem. >=20 > Adding a new *routing feature* is the problem. >=20 > BGP presently has no feature that lets the sender restrict where the = receiver might propagate a route. So the security protections would = have to invent the feature and secure it at the same time. This presumes the protections are to be incorporated into the control = plane. I don't know that everyone feels that way, which is why I = suggested my second comment. >=20 > The consensus of the meeting was that this is a bad way to do design. = Adding a new feature as part of adding a new security protection has = been found to lead to problems. =20 So, now maybe I'm confused... Is BGPSEC not adding a new feature, or is = it a bad way to do design? >=20 > Note that the current sidr work does not conflict with this. The = protections we are developing are there to protect features that already = exist in the BGP spec, but are vulnerable to misuse. The protections = eliminate "bad" behavior, but they do not produce new routing features. By adding information to BGP updates. Again, this thread started with a = statement to (as you corrected): idr. I think the wording needs work... >=20 > Wrt the interim meeting. The minutes and jabber logs are available. = Commenting on the list is always possible. I did not invalidate your summary of the minutes. I simply clarified = that those at the interim meeting do not (in this case) speak for all of = us, and it's not clear how many of us agree. Why is that not fair? >=20 > The drafts were mentioned to show that people are actively beginning = to work on this, not as pointers to a candidate. >=20 > The message below asks for idr's (not grow's) consideration of how to = proceed. Do you have some objection to idr being part of the definition = of a new routing feature? Nope, I think it's great, but lets not conflate issues and use vagaries = where we can be specific. ;) Eric >=20 > --Sandy >=20 > ________________________________________ > From: Eric Osterweil [eosterweil@verisign.com] > Sent: Wednesday, March 14, 2012 2:38 PM > To: George, Wes > Cc: Murphy, Sandra; sidr@ietf.org > Subject: Re: [sidr] route leaks message to IDR >=20 > I'd also like to add that (if I'm not mistaken) much of the BGPSEC = work is _already_ proposing to "add information to BGP updates." For = example, I'm pretty sure there aren't any signatures in BGP right now, = right? I don't think this text is completely on the level, because my = recollection of many of the sidr drafts is that they _ARE_ proposing to = add data, semantics, and processes to the current operation of BGP. By = my reading of the text below, it sounds like we would only add these = things if we were going to add route leak protection, and that sentiment = seems wrong to me. Moreover, the text below conflates the need for leak = protection with some as-yet-unspecified approach that must use inline = protocol changes. I don't know that this has been openly agreed to by = all (which is fine at this stage), but in reaching out to grow w/ this = as a starting point I think we present both a problem and an unratified = straw-man. I think the text needs to be clarified. >=20 > Also, I'd like to request in the 5th para (or the 6th sentence?): > s/The consensus in the room was/The consensus in the room = (though it is not clear what portion of the wg agrees) was/ >=20 > Thanks, >=20 > Eric >=20 > On Mar 14, 2012, at 5:49 PM, George, Wes wrote: >=20 >> I'm basically fine with the wording below. The only thing I might add = would be some mention of the reason why we're talking about route leaks, = why they're considered a problem that should be solved in the context of = SIDR, etc - mainly that there are those among the WG and operator = community that believe BGPSec as currently proposed is incomplete = without a method to prevent route leaks, and given the costs to deploy = and manage BGPSec, the inability to protect against this problem limits = its attractiveness for deployment. >>=20 >> This is covered in detail in the referenced drafts, but is worth = including in the summary text. >>=20 >> Thanks, >>=20 >> Wes >>=20 >>=20 >>> -----Original Message----- >>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >>> Murphy, Sandra >>> Sent: Tuesday, March 13, 2012 10:23 AM >>> To: sidr@ietf.org >>> Subject: [sidr] route leaks message to IDR >>>=20 >>> In the interim meeting, the consensus was that we needed idr to be = involved in >>> any definition and solution for route leaks. It was decided to = discuss a >>> message to the idr wg on the sidr list. >>>=20 >>> Brian Dickson has submitted drafts about route leaks, as he offered = in the >>> meeting. >>>=20 >>> So here is a first draft at a messate to idr. Comments please. >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> The sidr interim meeting in February discussed the problem of route = leaks. >>>=20 >>> While those in the room could recognize route leaks in a diagram, = they could >>> not determine a way to determine that from information communicated = in BGP. >>>=20 >>> Proposals to stop route leaks add information to BGP updates that = would be >>> used to restrict the propagation of those updates by the neighbor = onward to >>> providers, customers, peers, etc. >>>=20 >>> This is a change to BGP behavior, which now relies on local = configuration only >>> to choose a best path and advertise it. Adding features to stop = route leaks >>> would restrict that advertisement and restrict what local policy = could choose. >>>=20 >>> The consensus in the room was that adding a new feature to a = protocol as part >>> of a security protection (i.e., not just ensuring an already = defined behavior >>> but producing brand new behavior) is unwise and leads to problems. >>>=20 >>> The sidr working group requests that idr discuss the route leaks = problem with >>> sidr and determine the best path forward. >>>=20 >>> The idr wg should also be aware that drafts have been submitted = about route >>> leaks, so work is underway. >>>=20 >>> = http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-hel= p-01 >>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 >>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 >>> http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> --Sandy >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> 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 From eosterweil@verisign.com Wed Mar 14 14:35:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F7711E8083 for ; Wed, 14 Mar 2012 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YrarEbmp7oQ for ; Wed, 14 Mar 2012 14:35:14 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61B11E807F for ; Wed, 14 Mar 2012 14:35:11 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKT2EPDQj5FgXSu3zYhxDx05BTd+22fWBN@postini.com; Wed, 14 Mar 2012 14:35:13 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2ELZ8aa008825; Wed, 14 Mar 2012 17:35:08 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.34]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 17:35:08 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 14 Mar 2012 22:35:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Mar 2012 21:35:08.0153 (UTC) FILETIME=[53CE6690:01CD022A] Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:35:15 -0000 On Mar 14, 2012, at 9:50 PM, Stephen Kent wrote: > At 7:38 PM +0100 3/14/12, Eric Osterweil wrote: >> I'd also like to add that (if I'm not mistaken) much of the BGPSEC = work is _already_ proposing to "add information to BGP updates." For = example, I'm pretty sure there aren't any signatures in BGP right now, = right? >=20 > The addition of sigs to provide integrity and authentication for = AS_path info does not add new semantics to BGP. The sigs are used to = secure the existing semantics. I think that's what Sandy meant to convey = in her message, but maybe the wording needs to be improved. Yup, I do think the wording needs some work, thnx for the ack. >=20 >> I don't think this text is completely on the level, because my = recollection of many of the sidr drafts is that they _ARE_ proposing to = add data, semantics, and processes to the current operation of BGP. >=20 > New data, yes, new semantics, no. We were heading in that direction = with > the "beaconing" mechanism, but that seems to have gone away. So, what happens (for example) when a sig on an update can't be = verified? Is an update not processed and applied as it otherwise would = be? I guess it seems to me that the semantics of an update have changed = if a new portion of that update (the sig) can cause interpretation of = the meaning of that update to change (i.e. drop updates with = unverifiable sigs, update RIB if the sigs are verifiable). >=20 >> By my reading of the text below, it sounds like we would only add = these things if we were going to add route leak protection, and that = sentiment seems wrong to me. >=20 > Add which "things?" When you break the paragraph up, the pronouns are not as easy to = associate w/ their common nouns. ;) "Things," was referring to "data, = semantics, and processes." >=20 >> Moreover, the text below conflates the need for leak protection with = some as-yet-unspecified approach that must use inline protocol changes. >=20 > That is a fair observation, i.e., if there is agreement that route = leaks > can be defined in a rigorous, unambiguous fashion, then it is = appropriate > to explore various ways of detecting them. I think we agree that defining leaks and discussing any mechanisms to = remediate them are separate. >=20 >> I don't know that this has been openly agreed to by all (which is = fine at this stage), but in reaching out to grow w/ this as a starting = point I think we present both a problem and an unratified straw-man. I = think the text needs to be clarified. >=20 > I think the message asks IDR to look into this, not GROW. Yup... I had a brain fart. It's been a long week already... :-P >=20 >>=20 >> Also, I'd like to request in the 5th para (or the 6th sentence?): >> s/The consensus in the room was/The consensus in the room = (though it is not clear what portion of the wg agrees) was/ >=20 > seems like a reasonable edit. Kewl, thanks again for the ack! Eric= From brian.peter.dickson@gmail.com Thu Mar 15 08:27:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F321F84EA for ; Thu, 15 Mar 2012 08:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz3ch6J42n-F for ; Thu, 15 Mar 2012 08:27:54 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 012D721F84E7 for ; Thu, 15 Mar 2012 08:27:52 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2620109bku.31 for ; Thu, 15 Mar 2012 08:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yyDzHx5c2B/KH0zQQisk0gOd1gv1Zx8oKlSWp1qcUWU=; b=zv+qC5HrVyyuIpEGbQ3aC1fRqwkI6j5RPd5VWz+Lgp2aTTukE1ijbE4lGofiFmStbV saO8sv7oDhmDKEgvEh4zIln3+zk9uHlUCeHoW2BLwZLSyIDLqUkcjhGozi/d/rv1oIGL VDdeGW6Cx7JGOrMdIPP65MiiGiqlL1bgkDEpcEDhJVkoscz66eNp4BrUAqkaHPgNB5SX w7hvacKRW/qUpVho5MMx4qC+RaqO8u1wpQPw3S5kENPyXaXS2cWIkeFOnJ0tP2tCELm6 90UEfVPOIjJ1l0F86lWM0DmJRXkFebS1LPCjp6nhtuyPOuTEqenOohnAnpF1wMG8kQ3S LbEg== MIME-Version: 1.0 Received: by 10.204.136.200 with SMTP id s8mr2543212bkt.97.1331825272024; Thu, 15 Mar 2012 08:27:52 -0700 (PDT) Received: by 10.205.47.67 with HTTP; Thu, 15 Mar 2012 08:27:51 -0700 (PDT) Date: Thu, 15 Mar 2012 11:27:51 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=0015175cfe6c3dee3504bb49bc55 Cc: "sidr@ietf.org" Subject: [sidr] BGP behavior - changed or not? Was Re: route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:27:57 -0000 --0015175cfe6c3dee3504bb49bc55 Content-Type: text/plain; charset=ISO-8859-1 I've given the issue (of whether the proposal(s) for mechanisms to stop route leaks constitute(s) changes to BGP behavior) some more thought. Here's how I think the _mechanisms_ can be characterized: (The following presumes familiarity with the proposals. If you are concerned about the issue of BGP behavior, I encourage you to read them.) - The proposals use "link coloring" (where "link" refers to a specific BGP peering session, with a particular policy that falls into one of four classifications). - A given "link" has a policy that is mutually agreed upon by the parties on either end of the link. Only if they agree, does the "link" (BGPSEC-enabled peering session) get established. The possible choices are fall-back to non-BGPSEC, or err-disable the peering session. - The "link policy" is one of four policies - transit, customer, peer, or mutual transit. The purpose of the policy is to put scope on what classes of routes are mutually agreed on as acceptable, in each direction. - The proposals include enforcement of the agreed-upon "link policy" at the protocol level, i.e. that they cannot be over-ridden by the operator. Only unmarked routes, or policy-matching marked routes, get sent (and accepted). - One of the four "link policies" is "mutual transit", which equates to "anything can be announced in either direction". So, in essence, if there is a need to announce routes that would be blocked by all other policy settings, _and both operators agree_, this policy can be used. - The set of four policies is consistent with any conceivable local policy / peering policy. More restrictions on what is announced or filtered can be applied on top of this policy mechanism. Here is why I do not believe the mechanisms change BGP behavior: - _Both_ parties agree to (not send, or block upon receipt) certain classes of routes. This is the same in principal as "route filtering", and in particular RFC 5291, ORF (outbound route filtering). - The rules are to block routes received, which have the "color" applied to them (i.e. via BGPSEC with these enhancements), which violate the particular link color's restrictions - The rules are to block routes from being sent, if they would violate the link color vs route color restrictions - The doubling up of filtering (sender _and_ receiver) is consistent with best practices, and with the semantics of 5291 - The _result_ is non-propagation of routes that constitute leaks, and this is the intent. However, the _mechanics_ involve only blocking routes, not modifications of forwarding of received routes - The specific restrictions on reception and advertisement of routes, _are_ local policy. It merely provides a stronger semantic for identifying leaked routes, and for implementing the desired local policy. - It does not prevent local policy from choosing and advertising routes. However, like RFC 5291, the recipient can advise the sender that routes would not be accepted, and the sender should not bother sending them. - It does not differ from RFC 5291 in terms of mechanical semantics. When the receiver would block a route (because of link coloring vs prefix color), the sender doesn't send the route. - If the rules were enforced by receiver-only, the semantics would be identical to BGP with filtering. The sender-blocking is an optimization, really. (And reduces overhead in terms of useless BGPSEC signatures.) In essence, the information added is exactly analogous to what BGPSEC already does - add signatures which permit validation of path data - with one additional element, the ability to identify if/when announcements have violated agreed-upon peering policy (and validate that that information has not been modified). The behavior of BGP is not changed. What is added is a coarse-grained "knob" for local policy on a per-neighbor-session basis. Links which use the knob, always apply color to routes that are accepted. Local policy either blocks routes (on send and/or receipt) or allow routes. The one critical requirement is that operators know the policy of a particular neighbor BGP session. This requirement is borne out by operational experience, and common sense. It passes the "smell" test trivially. IMHO, the consensus of the room was based on poor description of the mechanisms, rather than the mechanisms actually causing new behavior. That was my fault, and in part due to my remote participation. However, the three IDs are meant to clarify this issue, and promote discussion/evaluation of the appropriateness of including route-leak protection into SIDR, the rigor and precision of the definition of route leaks, and evaluation of the requirements document. In particular, I think a determination of whether the proposals do or do not change BGP behavior, should be one of the goals of the discussions. I would request that this last statement be incorporated, in some form or another, in the message to IDR. Sincerely, Brian On Tue, Mar 13, 2012 at 10:22 AM, Murphy, Sandra wrote: > In the interim meeting, the consensus was that we needed idr to be > involved in any definition and solution for route leaks. It was decided to > discuss a message to the idr wg on the sidr list. > > Brian Dickson has submitted drafts about route leaks, as he offered in the > meeting. > > So here is a first draft at a messate to idr. Comments please. > > ============== > > The sidr interim meeting in February discussed the problem of route leaks. > > While those in the room could recognize route leaks in a diagram, they > could not determine a way to determine that from information communicated > in BGP. > > Proposals to stop route leaks add information to BGP updates that would be > used to restrict the propagation of those updates by the neighbor onward to > providers, customers, peers, etc. > > This is a change to BGP behavior, which now relies on local configuration > only to choose a best path and advertise it. Adding features to stop route > leaks would restrict that advertisement and restrict what local policy > could choose. > > The consensus in the room was that adding a new feature to a protocol as > part of a security protection (i.e., not just ensuring an already defined > behavior but producing brand new behavior) is unwise and leads to problems. > > The sidr working group requests that idr discuss the route leaks problem > with sidr and determine the best path forward. > > The idr wg should also be aware that drafts have been submitted about > route leaks, so work is underway. > > > http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02 > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01 > > =================== > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --0015175cfe6c3dee3504bb49bc55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've given the issue (of whether the proposal(s) for mechanisms to stop= route leaks constitute(s) changes to BGP behavior) some more thought.
<= br>Here's how I think the _mechanisms_ can be characterized:

(The following presumes familiarity with the proposals. If you are concerne= d about the issue of BGP behavior, I encourage you to read them.)

  • The proposals use "link coloring" (where "link" r= efers to a specific BGP peering session, with a particular policy that fall= s into one of four classifications).
  • A given "link" has a policy that is mutually agreed upon by t= he parties on either end of the link. Only if they agree, does the "li= nk" (BGPSEC-enabled peering session) get established. The possible cho= ices are fall-back to non-BGPSEC, or err-disable the peering session.
  • The "link policy" is one of four policies - transit, cus= tomer, peer, or mutual transit. The purpose of the policy is to put scope o= n what classes of routes are mutually agreed on as acceptable, in each dire= ction.
  • The proposals include enforcement of the agreed-upon "link policy&= quot; at the protocol level, i.e. that they cannot be over-ridden by the op= erator. Only unmarked routes, or policy-matching marked routes, get sent (a= nd accepted).
  • One of the four "link policies" is "mutual transit&= quot;, which equates to "anything can be announced in either direction= ". So, in essence, if there is a need to announce routes that would be= blocked by all other policy settings, _and both operators agree_, this pol= icy can be used.
  • The set of four policies is consistent with any conceivable local polic= y / peering policy. More restrictions on what is announced or filtered can = be applied on top of this policy mechanism.

    • Here is why I = do not believe the mechanisms change BGP behavior:
    • _Both_ parties agree to (not send, or block upon receipt) certain c= lasses of routes. This is the same in principal as "route filtering&qu= ot;, and in particular RFC 5291, ORF (outbound route filtering).
    • The rules are to block routes received, which have the "color" ap= plied to them (i.e. via BGPSEC with these enhancements), which violate the = particular link color's restrictions
    • The rules are to block rou= tes from being sent, if they would violate the link color vs route color re= strictions
    • The doubling up of filtering (sender _and_ receiver) is consistent with= best practices, and with the semantics of 5291
    • The _result_ is non= -propagation of routes that constitute leaks, and this is the intent. Howev= er, the _mechanics_ involve only blocking routes, not modifications of forw= arding of received routes
    • The specific restrictions on reception and advertisement of routes, _ar= e_ local policy. It merely provides a stronger semantic for identifying lea= ked routes, and for implementing the desired local policy.
    • It does = not prevent local policy from choosing and advertising routes. However, lik= e RFC 5291, the recipient can advise the sender that routes would not be ac= cepted, and the sender should not bother sending them.
    • It does not differ from RFC 5291 in terms of mechanical semantics. When= the receiver would block a route (because of link coloring vs prefix color= ), the sender doesn't send the route.
    • If the rules were enforce= d by receiver-only, the semantics would be identical to BGP with filtering.= The sender-blocking is an optimization, really. (And reduces overhead in t= erms of useless BGPSEC signatures.)

    In essence, the information added is exactly analogous to what BGPS= EC already does - add signatures which permit validation of path data - wit= h one additional element, the ability to identify if/when announcements hav= e violated agreed-upon peering policy (and validate that that information h= as not been modified).

    The behavior of BGP is not changed. What is added is a coarse-grained &q= uot;knob" for local policy on a per-neighbor-session basis. Links whic= h use the knob, always apply color to routes that are accepted. Local polic= y either blocks routes (on send and/or receipt) or allow routes.

    The one critical requirement is that operators know the policy of a part= icular neighbor BGP session. This requirement is borne out by operational e= xperience, and common sense. It passes the "smell" test trivially= .

    IMHO, the consensus of the room was based on poor description of the= mechanisms, rather than the mechanisms actually causing new behavior. That= was my fault, and in part due to my remote participation.

    Howeve= r, the three IDs are meant to clarify this issue, and promote discussion/ev= aluation of the appropriateness of including route-leak protection into SID= R,=A0 the rigor and precision of the definition of route leaks, and evaluat= ion of the requirements document.

    In particular, I think a determination of whether the proposals do or do= not change BGP behavior, should be one of the goals of the discussions.

    I would request that this last statement be incorporated, in some form = or another, in the message to IDR.

    Sincerely,

    Brian

    On Tue, Mar= 13, 2012 at 10:22 AM, Murphy, Sandra <Sandra.Murphy@sparta.com> wrote:=
    In the interim meeting, the consensus was th= at we needed idr to be involved in any definition and solution for route le= aks. =A0It was decided to discuss a message to the idr wg on the sidr list.=

    Brian Dickson has submitted drafts about route leaks, as he offered in the = meeting.

    So here is a first draft at a messate to idr. =A0Comments please.

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

    The sidr interim meeting in February discussed the problem of route leaks.<= br>
    While those in the room could recognize route leaks in a diagram, they coul= d not determine a way to determine that from information communicated in BG= P.

    Proposals to stop route leaks add information to BGP updates that would be = used to restrict the propagation of those updates by the neighbor onward to= providers, customers, peers, etc.

    This is a change to BGP behavior, which now relies on local configuration o= nly to choose a best path and advertise it. =A0Adding features to stop rout= e leaks would restrict that advertisement and restrict what local policy co= uld choose.

    The consensus in the room was that adding a new feature to a protocol as pa= rt of a security protection =A0(i.e., not just ensuring an already defined = behavior but producing brand new behavior) is unwise and leads to problems.=

    The sidr working group requests that idr discuss the route leaks problem wi= th sidr and determine the best path forward.

    The idr wg should also be aware that drafts have been submitted about route= leaks, so work is underway.

    http://tools.ietf.org/html/draft-foo-sidr= -simple-leak-attack-bgpsec-no-help-01
    http://tools.ietf.org/html/draft-dickson-sidr-route-leak= -def-01
    http://tools.ietf.org/html/draft-dickson-sidr-route-le= ak-reqts-02
    http://tools.ietf.org/html/draft-dickson-sidr-route-le= ak-solns-01

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

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

    --0015175cfe6c3dee3504bb49bc55-- From kent@bbn.com Thu Mar 15 15:09:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092DE21E8025 for ; Thu, 15 Mar 2012 15:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG7NDlhH-wLq for ; Thu, 15 Mar 2012 15:09:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6921E8010 for ; Thu, 15 Mar 2012 15:09:37 -0700 (PDT) Received: from dhcp89-089-054.bbn.com ([128.89.89.54]:49208) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S8IrL-000DsD-BS; Thu, 15 Mar 2012 18:09:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> Date: Thu, 15 Mar 2012 18:07:26 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-880273124==_ma============" Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 22:09:38 -0000 --============_-880273124==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:35 PM +0100 3/14/12, Eric Osterweil wrote: >... > >So, what happens (for example) when a sig on an update can't be >verified? Is an update not processed and applied as it otherwise >would be? I guess it seems to me that the semantics of an update >have changed if a new portion of that update (the sig) can cause >interpretation of the meaning of that update to change (i.e. drop >updates with unverifiable sigs, update RIB if the sigs are >verifiable). I see your point, but disagree. Let me try to explain. Whenever we add secruity mechanisms to a protocol we create new ways to cause the protocol to fail to forward data, fail to establish a connection, etc. The model I have long (>30 years) employed is that if the secruity checks succeed, the protocol should operate as before (i.e., w/o the added secruity mechanisms), because the environment is seen as benign. If the checks fail, the protocol should behave differently, e.g., something should fail, because the environment is now perceived as hostile and the protocol (w/o benefit of the secruity mechanisms) was not engineered to work properly in a hostile environment. Consider for example the fact that many protocols incorporate an integrity check. If the check fails, that causes a packet to be dropped. Typically the integrity check mechanism is not secure against attacks; is just a mechanism designed to detect benign errors. We frequently introduce crypto-based integrity mechanisms when we want to counter attacks. Those mechanisms will cause the protocol to behave differently in attack scenarios, e.g., an attack that might have yielded a valid checksum will yield an invalid HMAC, and that will cause a packet to be dropped. This is generally viewed not as a change to the protocol semantics, but rather an appropriate and natural effect of operating the protocol in a secure manner. I'd like to think that the BGPSEC mechanisms are being developed in a way that tries to adhere to this paradigm. >... > > >> Add which "things?" > >When you break the paragraph up, the pronouns are not as easy to >associate w/ their common nouns. ;) "Things," was referring to >"data, semantics, and processes." I read the text before the paragraph was sliced and diced, and I felt that "things" was ambiguous. Now that the ambiguity is removed, I just disagree with your reading of the text :-). >. > >I think we agree that defining leaks and discussing any mechanisms >to remediate them are separate. separate, but very interdependent. If the definition is squishy, countermeasures are likely to be messy, at best. Steve --============_-880273124==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] route leaks message to IDR
    At 10:35 PM +0100 3/14/12, Eric Osterweil wrote:
    ...

    So, what happens (for example) when a sig on an update can't be verified?  Is an update not processed and applied as it otherwise would be?  I guess it seems to me that the semantics of an update have changed if a new portion of that update (the sig) can cause interpretation of the meaning of that update to change (i.e. drop updates with unverifiable sigs, update RIB if the sigs are verifiable).

    I see your point, but disagree. Let me try to explain.

    Whenever we add secruity mechanisms to a protocol we create new ways to cause the protocol to fail to forward data, fail to establish a connection, etc. The model I have long (>30 years) employed is that if the secruity checks succeed, the protocol should operate as before (i.e., w/o the added secruity mechanisms), because the environment is seen as benign. If the checks fail, the protocol should behave differently, e.g., something should fail, because the environment is now perceived as hostile and the protocol (w/o benefit of the secruity mechanisms) was not engineered to work properly in a hostile environment.

    Consider for example the fact that many protocols incorporate an integrity check. If the check fails, that causes a packet to be dropped. Typically the integrity check mechanism is not secure against attacks; is just a mechanism designed to detect benign errors. We frequently introduce crypto-based integrity mechanisms when we want to counter attacks. Those mechanisms will cause the protocol to behave differently in attack scenarios, e.g., an  attack that might have yielded a valid checksum will yield an invalid HMAC, and that will cause a packet to be dropped. This is generally viewed not as a change to the protocol semantics, but rather an appropriate and natural effect of operating the protocol in a secure manner.

    I'd like to think that the BGPSEC mechanisms are being developed in a way that tries to adhere to this paradigm.


    ...
    >
    > Add which "things?"
    When you break the paragraph up, the pronouns are not as easy to associate w/ their common nouns. ;)  "Things," was referring to "data, semantics, and processes."

    I read the text before the paragraph was sliced and diced, and I felt that "things" was ambiguous. Now that the ambiguity is removed, I just disagree with your reading of the text :-).

    .

    I think we agree that defining leaks and discussing any mechanisms to remediate them are separate.

    separate, but very interdependent. If the definition is squishy, countermeasures are likely to be messy, at best.

    Steve

    --============_-880273124==_ma============-- From Sandra.Murphy@sparta.com Thu Mar 15 17:22:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD62221E804C for ; Thu, 15 Mar 2012 17:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqm3ZRb-A5oC for ; Thu, 15 Mar 2012 17:22:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DC23E21E800F for ; Thu, 15 Mar 2012 17:22:16 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2G0MECD032498; Thu, 15 Mar 2012 19:22:15 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2G0ME6q018402; Thu, 15 Mar 2012 19:22:14 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 20:22:14 -0400 From: "Murphy, Sandra" To: Eric Osterweil Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAA3lj8wAA1+0AD//8zZTYAAY4eAgAF9xvc= Date: Fri, 16 Mar 2012 00:22:13 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> , <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com>, <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> In-Reply-To: <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:22:17 -0000 speaking more as regular ol' member On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil said: >> BGP presently has no feature that lets the sender restrict where the >>receiver might propagate a route. So the security protections would >>have to invent the fea ture and secure it at the same time. >This presumes the protections are to be incorporated into the control >plane. I don't know that everyone feels that way, which is why I >suggested my second comment. My understanding of the desired outcome is that the sending ISP wishes to put restrictions on what the receiving ISP can do with the update. Whether that restriction is communicated inband or outofband, the intent to restrict BGP update propagation is the same. That is a new feature for BGP. >>=20 >> The consensus of the meeting was that this is a bad way to do >>design. Adding a new feature as part of adding a new security >>protection has been found to lead to problems. >So, now maybe I'm confused... Is BGPSEC not adding a new feature, or >is it a bad way to do design? BGPSEC is not a new *routing* feature. It is protections for existing routing features. BGPSEC eliminates certain *bad* routing behavior, but it should not create *new* routing features. The ability to restrict where a receiver can propagate an update is not presently BGP behavior. Brand new routing behavior. That's the difference. >By adding information to BGP updates. The information added to BGP updates for BGPSEC is there only to eliminate bad behaviors. Adding information is not the same as adding a new BGP routing feature. >I did not invalidate your summary of the minutes. I simply clarified >that those a t the interim meeting do not (in this case) speak for all >of us, and it's not clear how many of us agree. Why is that not >fair? You spoke of those who might not agree with the interim meeting. I was only suggesting that you and anyone not in attendance could comment on the mailing list, by referring to the archive. >> The message below asks for idr's (not grow's) consideration of how >>to proceed. Do you have some objection to idr being part of the >>definition of a new routing feature? >Nope, I think it's great, but lets not conflate issues and use >vagaries where we can be specific. ;) Glad you agree with the strategy. --Sandy, explaining a message sent as wg co-chair but giving my own regular ol' member opinion= From brian.peter.dickson@gmail.com Fri Mar 16 08:56:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A580421F8682 for ; Fri, 16 Mar 2012 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El8i6J1BN+Hj for ; Fri, 16 Mar 2012 08:56:45 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62F21F85D8 for ; Fri, 16 Mar 2012 08:56:45 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so158543wgb.13 for ; Fri, 16 Mar 2012 08:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EOVMJ2yovGr/k/fkU5JOQLO3lydJvTrI3znHQAqE/ms=; b=AAlC5baEazjgM+L+RnM/YaGRa96973QL2qo+J0BYd82XJRWB3p1eMvZR+ihkc6KLJi rdvKfcAbB2jYLP4wIoXAeqxJMXZU93I3D28dogKxbPh4qwhAL9yaQFnvZWuX+a6nF+v3 ZkCg5Hzvp9AhLsiOuQavqYUPk28sWzmz3C2y9oO/mM6qYvwlggYc/KQu3puZMhxTKAIZ w0AF/BgR07iPYOLCpwIAkWIwJ5ewluWr4/EacjXM6JkuOLnxEvPVO+3rCgmyJSzNuUGu Sv2dwmTC8eCVFYbLlqWbLuQFJZMcXzdpFULQQ2bPNFF0pL1QUTbqA2UoMbNVMSfv2MrS cPtg== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr8134219wib.3.1331913404477; Fri, 16 Mar 2012 08:56:44 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Fri, 16 Mar 2012 08:56:44 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Date: Fri, 16 Mar 2012 11:56:44 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=f46d0444ee2d58700a04bb5e41ca Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:56:46 -0000 --f46d0444ee2d58700a04bb5e41ca Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra wrote: > speaking more as regular ol' member > > On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil said: > > >> BGP presently has no feature that lets the sender restrict where the > >>receiver might propagate a route. So the security protections would > >>have to invent the fea ture and secure it at the same time. > > >This presumes the protections are to be incorporated into the control > >plane. I don't know that everyone feels that way, which is why I > >suggested my second comment. > > My understanding of the desired outcome is that the sending ISP wishes > to put restrictions on what the receiving ISP can do with the update. > That is not correct, i.e. you misunderstand. The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent, and the protocol merely enforces what has been agreed upon. The automatic enforcement of this high-level policy, is what stops route leaks from being initiated or propagated. The policy is still determined by the operators at both ends of a peering session. Just like the IP addresses and ASNs, the policies have to match for BGP session establishment. Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced or propagated route leaks, are prevented. The proposal(s) provide all the mechanisms to express any mutually-agreeable policy, including "send all routes in both directions". They do not preclude other refinements, such as AS-path filters, prefix filters, communities-related processing, or anything else. Nothing is unilateral, in what is proposed, so saying that the sending ISP puts restrictions on what the receiver can do, is actually a gross mischaracterization. (No intent is inferred, of course - it is clearly just a misunderstanding of the purpose and intent of the proposals.) > Whether that restriction is communicated inband or outofband, the > intent to restrict BGP update propagation is the same. > > (Incorrect.) > That is a new feature for BGP. > Correct, although whether this is part of BGPSEC (itself a new feature) or not, is the main thing to be discussed, inclusive of IDR's input. > > >> > >> The consensus of the meeting was that this is a bad way to do > >>design. Adding a new feature as part of adding a new security > >>protection has been found to lead to problems. > > >So, now maybe I'm confused... Is BGPSEC not adding a new feature, or > >is it a bad way to do design? > > BGPSEC is not a new *routing* feature. It is protections for existing > routing features. BGPSEC eliminates certain *bad* routing behavior, > but it should not create *new* routing features. > > Pot_ay_to, pot_ah_to. It should fall to the _WG_ to determine whether BGPSEC _is_, and/or _should_, be treated as a new feature. I do not believe the charter explicitly forces the WG onto one side of the line in the sand (feature/not-feature). And, I believe fundamentally, it _needs_ to be a new feature (set) on BGP, with all that goes along with it. There seems to be a strong reluctance among a subset of folks, to say this is a new feature set. This reluctance is appearing to fracture the WG into an us/them dichotomy, which is antithetical to the IETF philosophy. If BGPSEC were not a new feature, there would not be any need to add the BGP options negotiation between peers doing BGPSEC. And, if we acknowledge that it is a new feature, it then is incumbent on the WG members and chairs, to listen to all the WG participants, regarding what the requirements are in reaching the charter's goals, whether they are explicitly in the charter, or implicit consequences of what is necessary and sufficient in reaching those goals. This would potentially include other attributes being added, other data being cryptographically protected, and/or other negotiated peering parameters. Brian --f46d0444ee2d58700a04bb5e41ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra <Sandra.Murphy@sparta.com> wrote:
    speaking more as regular ol' member

    On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil =A0said:

    >> BGP presently has no feature that lets the sender restrict where t= he
    >>receiver might propagate a route. =A0So the security protections wo= uld
    >>have to invent the fea ture and secure it at the same time.

    >This presumes the protections are to be incorporated into the control >plane. =A0I don't know that everyone feels that way, which is why I=
    >suggested my second comment.

    My understanding of the desired outcome is that the sending ISP wishe= s
    to put restrictions on what the receiving ISP can do with the update.


    That is not correct, i.e. you misunderstand.
    The desired outcome is that sender/receiver _negotiate_ what is or is not = to be sent,
    and the protocol merely enforces what has been agreed upon. The automatic e= nforcement
    of this high-level policy, is what stops route leaks from bei= ng initiated or propagated.
    The policy is still determined by the operat= ors at both ends of a peering session.
    Just like the IP addresses and ASNs, the policies have to match for BGP ses= sion establishment.
    Unilateral misconfiguration (whether by accident or = deliberate act), which could have introduced
    or propagated route leaks, = are prevented.

    The proposal(s) provide all the mechanisms to express any mutually-agre= eable policy,
    including "send all routes in both directions". = They do not preclude other refinements,
    such as AS-path filters, prefix = filters, communities-related processing, or anything else.

    Nothing is unilateral, in what is proposed, so saying that the sending = ISP puts restrictions
    on what the receiver can do, is actually a gross m= ischaracterization. (No intent is inferred,
    of course - it is clearly ju= st a misunderstanding of the purpose and intent of the proposals.)
    =A0
    Whether that restriction is communicated inband or outofband, the
    intent to restrict BGP update propagation is the same.


    (Incorrect.)
    =A0
    That is a new feature for BGP.

    Correct, although w= hether this is part of BGPSEC (itself a new feature)
    or not, is the main= thing to be discussed, inclusive of IDR's input.
    =A0

    >>
    >> The consensus of the meeting was that this is a bad way to do
    >>design. =A0Adding a new feature as part of adding a new security >>protection has been found to lead to problems.

    >So, now maybe I'm confused... Is BGPSEC not adding a new feature, o= r
    >is it a bad way to do design?

    BGPSEC is not a new *routing* feature. =A0It is protections for exist= ing
    routing features. =A0BGPSEC eliminates certain *bad* routing behavior,
    but it should not create *new* routing features.


    Pot_ay_to, pot_ah_to.

    It should fall to th= e _WG_ to determine whether BGPSEC _is_,
    and/or _should_, be treated as = a new feature.
    I do not believe the charter explicitly forces
    the WG = onto one side of the line in the sand (feature/not-feature).

    And, I believe fundamentally, it _needs_ to be a new feature (set)
    o= n BGP, with all that goes along with it. There seems to be a strong
    relu= ctance among a subset of folks, to say this is a new feature set.
    This r= eluctance is appearing to fracture the WG into an us/them
    dichotomy, which is antithetical to the IETF philosophy.

    If BGPSEC w= ere not a new feature, there would not be any need
    to add the BGP option= s negotiation between peers doing BGPSEC.

    And, if we acknowledge tha= t it is a new feature, it then is incumbent
    on the WG members and chairs, to listen to all the WG participants,
    rega= rding what the requirements are in reaching the charter's goals,
    whe= ther they are explicitly in the charter, or implicit consequences
    of wha= t is necessary and sufficient in reaching those goals. This
    would potentially include other attributes being added, other data
    being= cryptographically protected, and/or other negotiated peering
    parameters= .
    =A0
    Brian
    --f46d0444ee2d58700a04bb5e41ca-- From christopher.morrow@gmail.com Fri Mar 16 13:54:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73621F861C for ; Fri, 16 Mar 2012 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g06xmIkyxgT3 for ; Fri, 16 Mar 2012 13:54:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4D3721F8557 for ; Fri, 16 Mar 2012 13:54:08 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2233955yhk.31 for ; Fri, 16 Mar 2012 13:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ulOqUulM1PPOofHIiS4m+MSdh3a2LqS+kf6xishvV7U=; b=SnXZVD4miwTDavuXhhR1Xocf9YoZXZ3PKCtp2Md2H2j989AyT3OGdeaaV+hmvvQ51V hx7W+prZ58XuJM0nUP0PMaZx+M//sxSzpuFYGUSdXVxHJnrt7lk4rlo7uv8wjZhh+ECm 4sIyiJXE1E05BjiUJ34WuWfZO1TvAt3UrPIdjlUJl4K3j0PyfuBHnVwlXmnMwvLCPn7h uqqCR1OZNjvK42OtpCwwQXPvgSODmJp8+w4tOrYB1oIHQJfgM9Tc+sASiYUxANjJLgML d7lXhf/jGYKf7DjifDzqCxRxP+dtJdlmiV2PFKdrSaI3thw1C6swjeeKax+Eaa+PikPm rw+g== MIME-Version: 1.0 Received: by 10.60.4.106 with SMTP id j10mr4594348oej.47.1331931248269; Fri, 16 Mar 2012 13:54:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.220.100 with HTTP; Fri, 16 Mar 2012 13:54:08 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Date: Fri, 16 Mar 2012 16:54:08 -0400 X-Google-Sender-Auth: qDiM209s2xCTHq8W48RRwgtxtt0 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:54:17 -0000 (behind on my reading, but...) On Fri, Mar 16, 2012 at 11:56 AM, Brian Dickson wrote: > On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra > wrote: >> >> speaking more as regular ol' member >> >> On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil =A0said: >> >> >> BGP presently has no feature that lets the sender restrict where the >> >>receiver might propagate a route. =A0So the security protections would >> >>have to invent the fea ture and secure it at the same time. >> >> >This presumes the protections are to be incorporated into the control >> >plane. =A0I don't know that everyone feels that way, which is why I >> >suggested my second comment. >> >> My understanding of the desired outcome is that the sending ISP wishes >> to put restrictions on what the receiving ISP can do with the update. that's probably the high-level-goal... 'hi everyone, these routes are from a "peer", fyi!' to which the further away bgp receiver could then say: "Oh, I see "peer" routes between two other "peer" sets, that's not valid according to my policy setup." ?? this seems, to me, to get very confusing very quickly. Policed at the immediate transit/peer/customer boundaries it seems feasible to make this sort of decision, but further away, ouch. Especially if the attribute isn't mandated to be used, and if there's no place to check that 'oh, they set that flag properly for that relationship, good!'. > > > That is not correct, i.e. you misunderstand. > > The desired outcome is that sender/receiver _negotiate_ what is or is not= to > be sent, sender/receiver BGP SPEAKERS negotiate capabilities ('I have larger-packet capability' || 'only small packets for me') > and the protocol merely enforces what has been agreed upon. The automatic > enforcement bgp simply passes along the attributes (well, the protocol does, the 'process' does many other things, potentially). > of this high-level policy, is what stops route leaks from being initiated= or > propagated. policy per BGP PEER, right? > The policy is still determined by the operators at both ends of a peering > session. > Just like the IP addresses and ASNs, the policies have to match for BGP > session establishment. If you mean 'ip addresses' and 'ASNs' of the BGP PEERs in question... you're describing 2 different checks at 2 different layers, I think. ip-address is really a tcp-stack question here: "I tried to connect to 1.2.3.4 from 1.2.3.3, he expected 10.1.1.1 to connect to his 10.1.1.2" ASN is checked inside the BGP (application) process: "I am AS1 I am connecting to AS2, he said AS3 oops!" > Unilateral misconfiguration (whether by accident or deliberate act), whic= h > could have introduced > or propagated route leaks, are prevented. So, your check would exist at the application above: "I am AS1, i provide transit to AS2, he says he's AS2 but that he provides transit to me, OOPS!" ?? > > The proposal(s) provide all the mechanisms to express any mutually-agreea= ble > policy, > including "send all routes in both directions". They do not preclude othe= r > refinements, > such as AS-path filters, prefix filters, communities-related processing, = or > anything else. Those (aspath/prefix-filter/communities) happen on a per-session basis today in 'configured policy' (operator configured for example) but do not enter into the application 'session' setup, nor the tcp-stack parts of the setup. Moving the proposed check into the application 'session' setup is interesting. > Nothing is unilateral, in what is proposed, so saying that the sending IS= P > puts restrictions > on what the receiver can do, is actually a gross mischaracterization. (No Imagining the CPE config for this, is a default 'send all routes' desired here? (desired in all deployments with the assumption that CPE folk just config as they do today with no extra settings, but ISP/Transit folks have to do the 'complicated' part?) > intent is inferred, > of course - it is clearly just a misunderstanding of the purpose and inte= nt > of the proposals.) > >> >> Whether that restriction is communicated inband or outofband, the >> intent to restrict BGP update propagation is the same. >> > > (Incorrect.) how so? if you and I agree that I am a 'customer' and i want you to 'send all routes' from me, and I will 'not send all routes' from you... that's 'restricting update propogation' isn't it? I suppose the next step in the 'negotiate capabilities' in my simple example above is: If 'send-all-routes' add community TRANSIT-CUSTOMER followed by, at the isp/provider/transit edge: If community =3D=3D TRANSIT-CUSTOMER: accept-route-to-externals So, the capability itself doesn't 'restrict update propogation', "local policy" does, which seems good/fine. >> That is a new feature for BGP. > > > Correct, although whether this is part of BGPSEC (itself a new feature) > or not, is the main thing to be discussed, inclusive of IDR's input. >> >> >> >> >> >> The consensus of the meeting was that this is a bad way to do >> >>design. =A0Adding a new feature as part of adding a new security >> >>protection has been found to lead to problems. >> >> >So, now maybe I'm confused... Is BGPSEC not adding a new feature, or >> >is it a bad way to do design? >> >> BGPSEC is not a new *routing* feature. =A0It is protections for existing >> routing features. =A0BGPSEC eliminates certain *bad* routing behavior, >> but it should not create *new* routing features. >> > > Pot_ay_to, pot_ah_to. > > It should fall to the _WG_ to determine whether BGPSEC _is_, > and/or _should_, be treated as a new feature. which WG? (you mention plural above, and singular here) > I do not believe the charter explicitly forces > the WG onto one side of the line in the sand (feature/not-feature). no, the AD's had said (paraphrased): bgp-mechanics belong in idr security bgp belongs in Sidr Sandy is arguing here that the proposal is 'mechanics' nor 'securing of the idr' I think. > And, I believe fundamentally, it _needs_ to be a new feature (set) > on BGP, with all that goes along with it. There seems to be a strong > reluctance among a subset of folks, to say this is a new feature set. I'm not sure I see that, but ... how about this approach. Would adding the transit/not-transit bit (simplification) to BGP independent of any security be of interest to BGP/IDR people? Would it help to 'secure' BGP? > This reluctance is appearing to fracture the WG into an us/them > dichotomy, which is antithetical to the IETF philosophy. > > If BGPSEC were not a new feature, there would not be any need > to add the BGP options negotiation between peers doing BGPSEC. > > And, if we acknowledge that it is a new feature, it then is incumbent > on the WG members and chairs, to listen to all the WG participants, > regarding what the requirements are in reaching the charter's goals, > whether they are explicitly in the charter, or implicit consequences > of what is necessary and sufficient in reaching those goals. This > would potentially include other attributes being added, other data > being cryptographically protected, and/or other negotiated peering > parameters. Sure, sort of like deprecating as-set usage... which happened in IDR, but was a consequence of discussion in SIDR that said: "Hey, we have no idea how to secure this, it's non-deterministic data and the aggregator doesn't have required material in order to 'secure' the as-set which is in the as-path. Beyond that the usage of AS-SET in the wild is by and large broken/not-helpful, so deprecating this will not harm existing users of the system." Which I think is basically what's happening with this discussion, no? perhaps we/wgfolk did a "Exercise is left to the reader, but for now go talk to IDR"? -chris hoping to read the drafts during the next week... From brian.peter.dickson@gmail.com Fri Mar 16 16:33:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFF221E808E for ; Fri, 16 Mar 2012 16:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lABCtbvO07X for ; Fri, 16 Mar 2012 16:33:40 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDF021E8014 for ; Fri, 16 Mar 2012 16:33:39 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1229969wib.13 for ; Fri, 16 Mar 2012 16:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mjrcYTD2uPSW9ZV/M5oBxr7r+yLv8cbVElKOnytX9WM=; b=KjLRmUYwxIvpq5cWui3kHOeB0dD9l6IoZBNv41zrD4hoh2FbidAs8afKiuh8dcIfT2 I4FOVcpB2jQukdsyBB8RfZ9leHEX9GEYuOPzhWZS3KCm16dx4u47WIn51VsBWl4nuVe6 2rkyAS4AgPYhyihvoPbR+ZP5BnKdvAmgi1+vsnF5kLfu/4p+cEYfV1dTLiXPQjURg1St e1Wwfac2gi8OzHxrYRZm/IqzOl5NJa+4du1lV+c1oSOVLUQWgySwdc+pjrL/e8iEpEPw ztXQpawnrAOmO7+OkiqNCnEs1PoS9BtMg8AYOtwsKUcxZTgwh4xPQlyIGYcuVk3h3AGV b1ag== MIME-Version: 1.0 Received: by 10.216.132.6 with SMTP id n6mr2712323wei.26.1331940818684; Fri, 16 Mar 2012 16:33:38 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Fri, 16 Mar 2012 16:33:38 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Date: Fri, 16 Mar 2012 19:33:38 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=0016e6d784fd5c0c6504bb64a3d3 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 23:33:42 -0000 --0016e6d784fd5c0c6504bb64a3d3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 4:54 PM, Christopher Morrow wrote: > (behind on my reading, but...) > > On Fri, Mar 16, 2012 at 11:56 AM, Brian Dickson > wrote: > > On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra < > Sandra.Murphy@sparta.com> > > wrote: > >> > >> speaking more as regular ol' member > >> > >> On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil said: > >> > >> >> BGP presently has no feature that lets the sender restrict where the > >> >>receiver might propagate a route. So the security protections would > >> >>have to invent the fea ture and secure it at the same time. > >> > >> >This presumes the protections are to be incorporated into the control > >> >plane. I don't know that everyone feels that way, which is why I > >> >suggested my second comment. > >> > >> My understanding of the desired outcome is that the sending ISP wishes > >> to put restrictions on what the receiving ISP can do with the update. > > that's probably the high-level-goal... 'hi everyone, these routes are > from a "peer", fyi!' to which the further away bgp receiver could then > say: "Oh, I see "peer" routes between two other "peer" sets, that's > not valid according to my policy setup." ?? > > this seems, to me, to get very confusing very quickly. Policed at the > immediate transit/peer/customer boundaries it seems feasible to make > this sort of decision, but further away, ouch. Especially if the > attribute isn't mandated to be used, and if there's no place to check > that 'oh, they set that flag properly for that relationship, good!'. > > Yes, you are correct on all counts. Especially the confusing bit. It would need to be mandated (modulo peer capabilities negotiation). It would need to be tracked/recorded 1:1 with AS hops. It would need to be protected against clobbering, a la crypto. But, with those provisos, you can then validate that the path is sane, policy-wise, is consistent with your local peer/peer policy, and is un-fooled-around-with. Those together, give leak proofing. > > > > > > That is not correct, i.e. you misunderstand. > > > > The desired outcome is that sender/receiver _negotiate_ what is or is > not to > > be sent, > > sender/receiver BGP SPEAKERS negotiate capabilities ('I have > larger-packet capability' || 'only small packets for me') > > > and the protocol merely enforces what has been agreed upon. The automatic > > enforcement > > bgp simply passes along the attributes (well, the protocol does, the > 'process' does many other things, potentially). > > > of this high-level policy, is what stops route leaks from being > initiated or > > propagated. > > policy per BGP PEER, right? > > Yep - where "peer" here means not just neighbor AS, but peering instance with that AS. > > The policy is still determined by the operators at both ends of a peering > > session. > > Just like the IP addresses and ASNs, the policies have to match for BGP > > session establishment. > > If you mean 'ip addresses' and 'ASNs' of the BGP PEERs in question... > you're describing 2 different checks at 2 different layers, I think. > > ip-address is really a tcp-stack question here: > "I tried to connect to 1.2.3.4 from 1.2.3.3, he expected 10.1.1.1 > to connect to his 10.1.1.2" > ASN is checked inside the BGP (application) process: > "I am AS1 I am connecting to AS2, he said AS3 oops!" > > Yep. Add to that, "We both want to do (leak-proofing + bgpsec), I'm her transit provider, she's my transit customer, good." Or, "She think's I'm a Peer, I think she's my transit provider, oops!". It is a 4 x 4 matrix with only 4 "good" combos. > > Unilateral misconfiguration (whether by accident or deliberate act), > which > > could have introduced > > or propagated route leaks, are prevented. > > So, your check would exist at the application above: > "I am AS1, i provide transit to AS2, he says he's AS2 but that he > provides transit to me, OOPS!" ?? > > Yes, except that "we are doing mutual transit" is one of the valid combos. But, yes, strict transit both ways is "ooops!". > > > > The proposal(s) provide all the mechanisms to express any > mutually-agreeable > > policy, > > including "send all routes in both directions". They do not preclude > other > > refinements, > > such as AS-path filters, prefix filters, communities-related processing, > or > > anything else. > > Those (aspath/prefix-filter/communities) happen on a per-session basis > today in 'configured policy' (operator configured for example) but do > not enter into the application 'session' setup, nor the tcp-stack > parts of the setup. Moving the proposed check into the application > 'session' setup is interesting. > > > Nothing is unilateral, in what is proposed, so saying that the sending > ISP > > puts restrictions > > on what the receiver can do, is actually a gross mischaracterization. (No > > Imagining the CPE config for this, is a default 'send all routes' > desired here? (desired in all deployments with the assumption that CPE > folk just config as they do today with no extra settings, but > ISP/Transit folks have to do the 'complicated' part?) > > Yes, except now it becomes very easy on both parts while assuring the "right stuff" happens. (I would still advocate the complicated stuff until at least a couple of revs of code are debugged by my competitors.) CPE == "hey, I'm a noob. So I turn on BGP, it comes up, I'm your customer?" ISP == "Yep." CPE: neighbor IPv4|IPv6 as NNN.NNN transit ISP: neighbor IPv4|IPv6 as MMM.MMM customer where "customer" does leak-proofing by allowing properly colored routes from the customer (only), and sends everything. And "transit" does leak-proofing by allowing all routes and sending only properly colored routes. Coloring done on the links is: (self) == colored "customer"; (customer) == mark as non-customer on send, preserve color on receipt; (transit) == preserve color on receipt, preserve color on send. > > intent is inferred, > > of course - it is clearly just a misunderstanding of the purpose and > intent > > of the proposals.) > > > >> > >> Whether that restriction is communicated inband or outofband, the > >> intent to restrict BGP update propagation is the same. > >> > > > > (Incorrect.) > > how so? if you and I agree that I am a 'customer' and i want you to > 'send all routes' from me, and I will 'not send all routes' from > you... that's 'restricting update propogation' isn't it? > > It is what happens today, it just changes the mechanics and enforcement of this. It is policy, reduced to an absolute minimum, baked into the process/protocol. It does not change the policy per se, so long as one of the options is suitable, for every peering session. (It is.) > I suppose the next step in the 'negotiate capabilities' in my simple > example above is: > If 'send-all-routes' > add community TRANSIT-CUSTOMER > > followed by, at the isp/provider/transit edge: > If community == TRANSIT-CUSTOMER: > accept-route-to-externals > > So, the capability itself doesn't 'restrict update propogation', > "local policy" does, which seems good/fine. > > Yep - except that you need to use extended communities, include the ASN:TRANSIT-CUSTOMER in the community, and prevent modification or stripping of communities. Then, the logic becomes: match extcommunity ^(*:TRANSIT-CUSTOMER)* (*:PEER)? (*:TRANSIT-PROVIDER)*$ accept else reject (and more restrictive on peers and customers) > >> That is a new feature for BGP. > > > > > > Correct, although whether this is part of BGPSEC (itself a new feature) > > or not, is the main thing to be discussed, inclusive of IDR's input. > >> > >> > >> >> > >> >> The consensus of the meeting was that this is a bad way to do > >> >>design. Adding a new feature as part of adding a new security > >> >>protection has been found to lead to problems. > >> > >> >So, now maybe I'm confused... Is BGPSEC not adding a new feature, or > >> >is it a bad way to do design? > >> > >> BGPSEC is not a new *routing* feature. It is protections for existing > >> routing features. BGPSEC eliminates certain *bad* routing behavior, > >> but it should not create *new* routing features. > >> > > > > Pot_ay_to, pot_ah_to. > > > > It should fall to the _WG_ to determine whether BGPSEC _is_, > > and/or _should_, be treated as a new feature. > > which WG? (you mention plural above, and singular here) > > SIDR. > > I do not believe the charter explicitly forces > > the WG onto one side of the line in the sand (feature/not-feature). > > no, the AD's had said (paraphrased): > bgp-mechanics belong in idr > security bgp belongs in Sidr > > Sandy is arguing here that the proposal is 'mechanics' nor 'securing > of the idr' I think. > > What I'm suggesting is, implicit in the charter is that any mechanics necessary to achieve "security", can be read as delegated to SIDR. I'm not suggesting going overboard, but I do suggest that you can't make an omlette (adding security to BGP) without breaking eggs (touching, however slightly, BGP mechanics and semantics.) > > And, I believe fundamentally, it _needs_ to be a new feature (set) > > on BGP, with all that goes along with it. There seems to be a strong > > reluctance among a subset of folks, to say this is a new feature set. > > I'm not sure I see that, but ... how about this approach. Would adding > the transit/not-transit bit (simplification) to BGP independent of any > security be of interest to BGP/IDR people? Would it help to 'secure' > BGP? > > Yes, it would. There are only two problems I see with that, or maybe more if you combine them. (1) In order to achieve leak-proofing, the whole of the AS_PATH needs a corresponding COLOR_PATH. (Or, modulo information-hiding so no info leakage occurs via COLOR_PATH, see the third ID for how & why). That's a lot of overhead, and if the exact same kind of overhead is already needed for BGPSEC, it'd be easier to piggy-back one bit on the sig block (or encode via algorithm choice!!) (2) You still have to secure the result, for adding protection against malicious path manipulation, even in the case where BGPSEC signatures are on the paths. Otherwise, the color could be manipulated, defeating both leak-proofing and, to a lesser degree, BGPSEC. So, I see it as both a target-of-opportunity (how much lower do you need the fruit to hang??), and a synergistic way of making the added work of either, more attractive when the two are combined. > > This reluctance is appearing to fracture the WG into an us/them > > dichotomy, which is antithetical to the IETF philosophy. > > > > If BGPSEC were not a new feature, there would not be any need > > to add the BGP options negotiation between peers doing BGPSEC. > > > > And, if we acknowledge that it is a new feature, it then is incumbent > > on the WG members and chairs, to listen to all the WG participants, > > regarding what the requirements are in reaching the charter's goals, > > whether they are explicitly in the charter, or implicit consequences > > of what is necessary and sufficient in reaching those goals. This > > would potentially include other attributes being added, other data > > being cryptographically protected, and/or other negotiated peering > > parameters. > > Sure, sort of like deprecating as-set usage... which happened in IDR, > but was a consequence of discussion in SIDR that said: "Hey, we have > no idea how to secure this, it's non-deterministic data and the > aggregator doesn't have required material in order to 'secure' the > as-set which is in the as-path. Beyond that the usage of AS-SET in the > wild is by and large broken/not-helpful, so deprecating this will not > harm existing users of the system." > > Which I think is basically what's happening with this discussion, no? > perhaps we/wgfolk did a "Exercise is left to the reader, but for now > go talk to IDR"? > > I'm cool with that... > -chris > hoping to read the drafts during the next week... > --0016e6d784fd5c0c6504bb64a3d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Fri, Mar 16, 2012 at 4:54 PM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:
    (behind on my reading, but...)

    On Fri, Mar 16, 2012 at 11:56 AM, Brian Dickson
    <brian.peter.dickson@gm= ail.com> wrote:
    > On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra <Sandra.Murphy@sparta.com>
    > wrote:
    >>
    >> speaking more as regular ol' member
    >>
    >> On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil =A0said:
    >>
    >> >> BGP presently has no feature that lets the sender restric= t where the
    >> >>receiver might propagate a route. =A0So the security prote= ctions would
    >> >>have to invent the fea ture and secure it at the same time= .
    >>
    >> >This presumes the protections are to be incorporated into the = control
    >> >plane. =A0I don't know that everyone feels that way, which= is why I
    >> >suggested my second comment.
    >>
    >> My understanding of the desired outcome is that the sending ISP wi= shes
    >> to put restrictions on what the receiving ISP can do with the upda= te.

    that's probably the high-level-goal... 'hi everyone, these ro= utes are
    from a "peer", fyi!' to which the further away bgp receiver c= ould then
    say: "Oh, I see "peer" routes between two other "peer&q= uot; sets, that's
    not valid according to my policy setup." ??

    this seems, to me, to get very confusing very quickly. Policed at the
    immediate transit/peer/customer boundaries it seems feasible to make
    this sort of decision, but further away, ouch. Especially if the
    attribute isn't mandated to be used, and if there's no place to che= ck
    that 'oh, they set that flag properly for that relationship, good!'= .


    Yes, you are c= orrect on all counts. Especially the confusing bit.

    It would need to be mandated (modulo peer capabilities negotiation).
    It would need to be tracked/recorded 1:1 with AS hops.
    It wo= uld need to be protected against clobbering, a la crypto.

    But, with those provisos, you can then validate that the path is sa= ne,
    policy-wise, is consistent with your local peer/peer policy, and is un= -fooled-around-with.

    Those together, give leak pro= ofing.

    =A0
    >
    >
    > That is not correct, i.e. you misunderstand.
    >
    > The desired outcome is that sender/receiver _negotiate_ what is or is = not to
    > be sent,

    sender/receiver BGP SPEAKERS negotiate capabilities ('I have
    larger-packet capability' || 'only small packets for me')

    > and the protocol merely enforces what has been agreed upon. The automa= tic
    > enforcement

    bgp simply passes along the attributes (well, the protocol does, the<= br> 'process' does many other things, potentially).

    > of this high-level policy, is what stops route leaks from being initia= ted or
    > propagated.

    policy per BGP PEER, right?


    Yep - where &q= uot;peer" here means not just neighbor AS, but peering instance with t= hat AS.
    =A0
    > The policy is still determined by the operators at both ends of a peer= ing
    > session.
    > Just like the IP addresses and ASNs, the policies have to match for BG= P
    > session establishment.

    If you mean 'ip addresses' and 'ASNs' of the BGP PEER= s in question...
    you're describing 2 different checks at 2 different layers, I think.
    =A0ip-address is really a tcp-stack question here:
    =A0 =A0"I tried to connect to 1.2.3.4 from 1.2.3.3, he expected 10.1.= 1.1
    to connect to his 10.1.1.2"
    =A0ASN is checked inside the BGP (application) process:
    =A0 =A0"I am AS1 I am connecting to AS2, he said AS3 oops!"


    Yep. Add to th= at, "We both want to do (leak-proofing + bgpsec), I'm her transit = provider, she's my transit customer, good."
    Or, "Sh= e think's I'm a Peer, I think she's my transit provider, oops!&= quot;.
    It is a 4 x 4 matrix with only 4 "good" combos.
    = =A0
    > Unilateral misconfiguration (whether by accident or deliberate act), w= hich
    > could have introduced
    > or propagated route leaks, are prevented.

    So, your check would exist at the application above:
    =A0"I am AS1, i provide transit to AS2, he says he's AS2 but that= he
    provides transit to me, OOPS!" ??


    Yes, except th= at "we are doing mutual transit" is one of the valid combos. But,= yes, strict transit both ways is "ooops!".
    =A0
    >
    > The proposal(s) provide all the mechanisms to express any mutually-agr= eeable
    > policy,
    > including "send all routes in both directions". They do not = preclude other
    > refinements,
    > such as AS-path filters, prefix filters, communities-related processin= g, or
    > anything else.

    Those (aspath/prefix-filter/communities) happen on a per-session basi= s
    today in 'configured policy' (operator configured for example) but = do
    not enter into the application 'session' setup, nor the tcp-stack parts of the setup. Moving the proposed check into the application
    'session' setup is interesting.

    > Nothing is unilateral, in what is proposed, so saying that the sending= ISP
    > puts restrictions
    > on what the receiver can do, is actually a gross mischaracterization. = (No

    Imagining the CPE config for this, is a default 'send all routes&= #39;
    desired here? (desired in all deployments with the assumption that CPE
    folk just config as they do today with no extra settings, but
    ISP/Transit folks have to do the 'complicated' part?)


    Yes, except no= w it becomes very easy on both parts while assuring the "right stuff&q= uot; happens.
    (I would still advocate the complicated stuff until= at least a couple of revs of code are debugged by my competitors.)

    CPE =3D=3D "hey, I'm a noob. So I turn on BGP,= it comes up, I'm your customer?"
    ISP =3D=3D "Yep.&= quot;
    CPE: neighbor IPv4|IPv6 as NNN.NNN transit
    ISP: n= eighbor IPv4|IPv6 as MMM.MMM customer

    where "customer" does leak-proofing by allowi= ng properly colored routes from the customer (only), and sends everything.<= /div>
    And "transit" does leak-proofing by allowing all routes= and sending only properly colored routes.
    Coloring done on the links is: (self) =3D=3D colored "customer&qu= ot;; (customer) =3D=3D mark as non-customer on send, preserve color on rece= ipt; (transit) =3D=3D preserve color on receipt, preserve color on send.
    =A0
    > intent is inferred,
    > of course - it is clearly just a misunderstanding of the purpose and i= ntent
    > of the proposals.)
    >
    >>
    >> Whether that restriction is communicated inband or outofband, the<= br> >> intent to restrict BGP update propagation is the same.
    >>
    >
    > (Incorrect.)

    how so? if you and I agree that I am a 'customer' and i want = you to
    'send all routes' from me, and I will 'not send all routes'= from
    you... that's 'restricting update propogation' isn't it?

    It is what happens today, it just chan= ges the mechanics and enforcement of this.
    It is policy, reduced = to an absolute minimum, baked into the process/protocol.
    It does = not change the policy per se, so long as one of the options is suitable, fo= r every peering session. (It is.)
    =A0
    I suppose the next step in the 'negotiate capabilities' in my simpl= e
    example above is:
    =A0If 'send-all-routes'
    =A0 =A0add community TRANSIT-CUSTOMER

    followed by, at the isp/provider/transit edge:
    =A0If community =3D=3D TRANSIT-CUSTOMER:
    =A0 =A0accept-route-to-externals

    So, the capability itself doesn't 'restrict update propogation'= ,
    "local policy" does, which seems good/fine.


    Yep - except t= hat you need to use extended communities, include the ASN:TRANSIT-CUSTOMER = in the community, and prevent modification or stripping of communities.

    Then, the logic becomes:
    match extcommunity ^= (*:TRANSIT-CUSTOMER)* (*:PEER)? (*:TRANSIT-PROVIDER)*$
    =A0 accept=
    else
    =A0 reject

    (and more res= trictive on peers and customers)

    =A0
    >> That is a new feature for BGP.
    >
    >
    > Correct, although whether this is part of BGPSEC (itself a new feature= )
    > or not, is the main thing to be discussed, inclusive of IDR's inpu= t.
    >>
    >>
    >> >>
    >> >> The consensus of the meeting was that this is a bad way t= o do
    >> >>design. =A0Adding a new feature as part of adding a new se= curity
    >> >>protection has been found to lead to problems.
    >>
    >> >So, now maybe I'm confused... Is BGPSEC not adding a new f= eature, or
    >> >is it a bad way to do design?
    >>
    >> BGPSEC is not a new *routing* feature. =A0It is protections for ex= isting
    >> routing features. =A0BGPSEC eliminates certain *bad* routing behav= ior,
    >> but it should not create *new* routing features.
    >>
    >
    > Pot_ay_to, pot_ah_to.
    >
    > It should fall to the _WG_ to determine whether BGPSEC _is_,
    > and/or _should_, be treated as a new feature.

    which WG? (you mention plural above, and singular here)


    SIDR.=A0
    =
    =A0
    > I do not believe the charter explicitly forces
    > the WG onto one side of the line in the sand (feature/not-feature).
    no, the AD's had said (paraphrased):
    =A0bgp-mechanics belong in idr
    =A0security bgp belongs in Sidr

    Sandy is arguing here that the proposal is 'mechanics' nor 'sec= uring
    of the idr' I think.


    What I'm s= uggesting is, implicit in the charter is that any mechanics necessary to ac= hieve "security", can be read as delegated to SIDR.
    I'm not suggesting going overboard, but I do suggest that you can't= make an omlette (adding security to BGP) without breaking eggs (touching, = however slightly, BGP mechanics and semantics.)
    =A0
    > And, I believe fundamentally, it _needs_ to be a new feature (set)
    > on BGP, with all that goes along with it. There seems to be a strong > reluctance among a subset of folks, to say this is a new feature set.<= br>
    I'm not sure I see that, but ... how about this approach. Would a= dding
    the transit/not-transit bit (simplification) to BGP independent of any
    security be of interest to BGP/IDR people? Would it help to 'secure'= ;
    BGP?


    Yes, it would.= There are only two problems I see with that, or maybe more if you combine = them.
    (1) In order to achieve leak-proofing, the whole of the AS_= PATH needs a corresponding COLOR_PATH.
    (Or, modulo information-hiding so no info leakage occurs via COLOR_PAT= H, see the third ID for how & why).
    That's a lot of overh= ead, and if the exact same kind of overhead is already needed for BGPSEC, i= t'd be easier to piggy-back one bit on the sig block (or encode via alg= orithm choice!!)

    (2) You still have to secure the result, for adding pro= tection against malicious path manipulation, even in the case where BGPSEC = signatures are on the paths. Otherwise, the color could be manipulated, def= eating both leak-proofing and, to a lesser degree, BGPSEC.

    So, I see it as both a target-of-opportunity (how much = lower do you need the fruit to hang??), and a synergistic way of making the= added work of either, more attractive when the two are combined.
    =A0
    > This reluctance is appearing to fracture the WG into an us/them
    > dichotomy, which is antithetical to the IETF philosophy.
    >
    > If BGPSEC were not a new feature, there would not be any need
    > to add the BGP options negotiation between peers doing BGPSEC.
    >
    > And, if we acknowledge that it is a new feature, it then is incumbent<= br> > on the WG members and chairs, to listen to all the WG participants, > regarding what the requirements are in reaching the charter's goal= s,
    > whether they are explicitly in the charter, or implicit consequences > of what is necessary and sufficient in reaching those goals. This
    > would potentially include other attributes being added, other data
    > being cryptographically protected, and/or other negotiated peering
    > parameters.

    Sure, sort of like deprecating as-set usage... which happened in IDR,=
    but was a consequence of discussion in SIDR that said: "Hey, we have no idea how to secure this, it's non-deterministic data and the
    aggregator doesn't have required material in order to 'secure' = the
    as-set which is in the as-path. Beyond that the usage of AS-SET in the
    wild is by and large broken/not-helpful, so deprecating this will not
    harm existing users of the system."

    Which I think is basically what's happening with this discussion, no? perhaps we/wgfolk did a "Exercise is left to the reader, but for now go talk to IDR"?


    I'm cool with that...
    = =A0
    -chris
    hoping to read the drafts during the next week...

    --0016e6d784fd5c0c6504bb64a3d3-- From christopher.morrow@gmail.com Fri Mar 16 17:21:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0235721F8672 for ; Fri, 16 Mar 2012 17:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwXJDswTMgct for ; Fri, 16 Mar 2012 17:21:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6254D21F866C for ; Fri, 16 Mar 2012 17:21:52 -0700 (PDT) Received: by iazz13 with SMTP id z13so7138364iaz.31 for ; Fri, 16 Mar 2012 17:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AQR6zwYobdS9o+NvpyQSRofKvM6L3uZdB69Rozm1fI0=; b=ueQGZ3zm+qPMhhjR1YBSQfxcmVg1h6Epd78FBp5H+Lvy6kYeOci4FPzxOFolo00wnv w6S+/YdURCki3n0mg/WCx1biEqF8XewBounOI3SJM1JHr8Qz/uHqDua5PrYfvvRTA9v2 h1W5Azb3wKffwCTMqedhHMMidUqmUpfPtRdyWx0AuYfoXZYjpJh7v9eFg2C9iQwKU9r5 OYzsB1YFKj303FkYhwCmbtR5W9Rf3zqoEao3Haq10Kx0s/kLw8RN0h78OqGMvbXN1Ed6 ULjySjzsNpPrgKBydc9IY9gm6u787JTmnbYWt/09N18P2cs3h6ANVs7lPCNGSJlLZYKp XHUA== MIME-Version: 1.0 Received: by 10.182.231.38 with SMTP id td6mr4675348obc.47.1331943711879; Fri, 16 Mar 2012 17:21:51 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.220.100 with HTTP; Fri, 16 Mar 2012 17:21:51 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Date: Fri, 16 Mar 2012 20:21:51 -0400 X-Google-Sender-Auth: U6vYj_INAacMAAKoPkz9hztT_rE Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:21:53 -0000 quick response to a single point... below. On Fri, Mar 16, 2012 at 7:33 PM, Brian Dickson wrote: > > > On Fri, Mar 16, 2012 at 4:54 PM, Christopher Morrow > wrote: >> > And, if we acknowledge that it is a new feature, it then is incumbent >> > on the WG members and chairs, to listen to all the WG participants, >> > regarding what the requirements are in reaching the charter's goals, >> > whether they are explicitly in the charter, or implicit consequences >> > of what is necessary and sufficient in reaching those goals. This >> > would potentially include other attributes being added, other data >> > being cryptographically protected, and/or other negotiated peering >> > parameters. >> >> Sure, sort of like deprecating as-set usage... which happened in IDR, >> but was a consequence of discussion in SIDR that said: "Hey, we have >> no idea how to secure this, it's non-deterministic data and the >> aggregator doesn't have required material in order to 'secure' the >> as-set which is in the as-path. Beyond that the usage of AS-SET in the >> wild is by and large broken/not-helpful, so deprecating this will not >> harm existing users of the system." >> >> Which I think is basically what's happening with this discussion, no? >> perhaps we/wgfolk did a "Exercise is left to the reader, but for now >> go talk to IDR"? >> > > I'm cool with that... This part, I think, gets to the meat of the process part which really is that if the bit being done is not directly 'security' (which to some extent SIDR should have the say-so on) it ought to be done in IDR. It seems that having the sidr side folks discuss this and agree on direction is the right thing to do (which mostly happened here/on-list so far). Perhaps with at least some discussion in paris/sidr we'll circle to the answer completely. thanks! -chris (again, just a regular sidr person, which I forgot to say last time :( ) From Sandra.Murphy@sparta.com Sat Mar 17 19:49:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82221F85A8; Sat, 17 Mar 2012 19:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTB2MwKg6eLi; Sat, 17 Mar 2012 19:49:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24621F84A7; Sat, 17 Mar 2012 19:49:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2I2nNfA014832; Sat, 17 Mar 2012 21:49:23 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2I2nN3n027945; Sat, 17 Mar 2012 21:49:23 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Sat, 17 Mar 2012 22:49:22 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda for virtual meeting Mar 24 Thread-Index: AQHNBLGo4D/8pryt70y0ueB10MFWmA== Date: Sun, 18 Mar 2012 02:49:21 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C84EF@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg-secretary@ietf.org" Subject: [sidr] agenda for virtual meeting Mar 24 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 02:49:25 -0000 Here is the agenda for the sidr virtual meeting on Sat 24 Mar 2012. UTC 0800-1030. Protocol spec In depth protocol review, doc structure, forward path, etc. draft-ietf-sidr-bgpsec-protocol-02 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol UTC 1030-1230 Break UTC 1230-1330 draft-ietf-sidr-origin-ops-15 draft-ietf-sidr-bgpsec-reqs-03 draft-ietf-sidr-bgpsec-ops-04 http://tools.ietf.org/html/draft-ietf-sidr-origin-ops=20 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs=20 http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops=20 (if there is time, discussion of draft-ymbk-bgpsec-rtr-rekeying-00 http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying draft-rogaglia-sidr-bgpsec-rollover-00 http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00)=20 UTC 1330-1430 Alternate architectures RPKI delivery and scaling UTC 1430-1600 pfx-validate recent discussions on the sidr list. draft-ietf-sidr-pfx-validate-04 http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate=20 --Sandy, speaking as working group co-chair= From shane@castlepoint.net Sun Mar 18 18:55:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B5621F8548 for ; Sun, 18 Mar 2012 18:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_05=-1.11, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tROd2AtUONw for ; Sun, 18 Mar 2012 18:55:17 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B416021F8546 for ; Sun, 18 Mar 2012 18:55:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D11D4268063; Sun, 18 Mar 2012 19:55:16 -0600 (MDT) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sun, 18 Mar 2012 19:55:16 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=62644; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2012 19:55:00 -0600 Message-Id: <6AA0D32B-F02A-4801-AA59-74CA7A2EE381@castlepoint.net> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [sidr] draft-ietf-sidr-bgpsec-reqs-03: Support for ASN Migrations? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 01:55:18 -0000 Hi, May I kindly request the SIDR WG update the aforementioned WG draft to = state whether ASN Migration scenarios, specifically those that = manipulate the AS_PATH attribute to support "seamless" migration from = one globally unique ASN to a second globally unique ASN, are included in = the requirements for BGPsec? I had brought this up at SIDR WG meeting at IETF 82, in Taipei, (search = for my first name): http://tools.ietf.org/wg/sidr/minutes?item=3Dminutes82.html ... but have not seen anything reflected in the current version of the = this draft (-03). I realize that folks are likely extremely busy and = this may have accidentally fallen through the cracks, which is why I'm = following up with a note to the list in the hopes that this could be = queued up in an 'edit buffer' for the next rev of the requirements = draft. Thanks! -shane= From wesley.george@twcable.com Mon Mar 19 07:11:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C4521F86EC for ; Mon, 19 Mar 2012 07:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqBQ8qz1isau for ; Mon, 19 Mar 2012 07:11:22 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 59CD821F86E2 for ; Mon, 19 Mar 2012 07:11:22 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,611,1325480400"; d="scan'208";a="355669990" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 19 Mar 2012 10:10:38 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 19 Mar 2012 10:11:19 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" , "morrowc.lists@gmail.com" Date: Mon, 19 Mar 2012 10:11:23 -0400 Thread-Topic: agenda for virtual meeting Mar 24 Thread-Index: AQHNBLGo4D/8pryt70y0ueB10MFWmJZxn9oA Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C84EF@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C84EF@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel Subject: Re: [sidr] agenda for virtual meeting Mar 24 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:11:24 -0000 Was the WG consulted on scheduling this virtual meeting and I missed the me= ssage? The first message I see on the matter is the announcement of the meeting on= 3/7. I don't know about anyone else, but I'm traveling to Paris the day it= 's scheduled (actually ON the plane during the meeting), and based on a cou= ple of messages in response to the general announcement (on ietf@ietf), I'm= not the only one. My travel arrangements have been made for significantly = more than 3 weeks, as are most people's when planning a trip to IETF. Virtu= al meetings don't need as much advance notice due to the fact that no one n= eeds to travel to *attend* but scheduling conflicts do exist. As far as I can tell, there was no attempt to determine the appropriateness= of the date for this or the previous Interim with the WG prior to setting = the date. I know of several folks who found out about it during NANOG and w= ould have liked to attend, but couldn't rearrange their travel plans at the= last minute. In the future, I respectfully ask the chairs to solicit opinions on potenti= al scheduling of interim meetings PRIOR to setting the date. I have no prob= lem with there being a self-selecting core group of folks that make up a de= sign team, but when they are working directly with the chairs to schedule s= upposedly official WG interim meetings without involving the WG until the d= ates are already set, we have a problem. For that matter, I believe that this interim/virtual meeting should be resc= heduled once an appropriate date can be determined based on consensus of th= e *entire* WG. Put up a doodle poll with some potential dates, publish it a= long with the goal of the meeting to sidr@ietf.org and let those interested= in attending choose. Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Saturday, March 17, 2012 10:49 PM > To: sidr@ietf.org > Cc: iesg-secretary@ietf.org > Subject: [sidr] agenda for virtual meeting Mar 24 > > Here is the agenda for the sidr virtual meeting on Sat 24 Mar 2012. > > UTC 0800-1030. Protocol spec > In depth protocol review, doc structure, forward path, etc. > draft-ietf-sidr-bgpsec-protocol-02 > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol > > UTC 1030-1230 Break > > UTC 1230-1330 > draft-ietf-sidr-origin-ops-15 > draft-ietf-sidr-bgpsec-reqs-03 > draft-ietf-sidr-bgpsec-ops-04 > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops > (if there is time, discussion of > draft-ymbk-bgpsec-rtr-rekeying-00 > http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying > draft-rogaglia-sidr-bgpsec-rollover-00 > http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00) > > > UTC 1330-1430 Alternate architectures > RPKI delivery and scaling > > UTC 1430-1600 pfx-validate > recent discussions on the sidr list. > draft-ietf-sidr-pfx-validate-04 > http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate > > --Sandy, speaking as working group co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From tim@ripe.net Mon Mar 19 08:16:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5024821F87EF for ; Mon, 19 Mar 2012 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrBFMYGgWRSR for ; Mon, 19 Mar 2012 08:16:52 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 482C621F87C9 for ; Mon, 19 Mar 2012 08:16:52 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S9eKH-0000Q7-Rc; Mon, 19 Mar 2012 16:16:51 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1S9eKH-0005XK-FY; Mon, 19 Mar 2012 16:16:49 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Mon, 19 Mar 2012 16:16:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B8DCAA7-F1D0-48D5-9AE1-E417883D4A60@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C84EF@Hermes.columbia.ads.sparta.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1084) 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: 784d7acfe6559f2a0b602ec6519a0719bc0951ecbfa811744ffbca46a2f9e467 Cc: "sidr@ietf.org list" Subject: Re: [sidr] agenda for virtual meeting Mar 24 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:16:53 -0000 Hi WG, and Sandy as co-chair, On 19 Mar 2012, at 15:11, George, Wes wrote: > Was the WG consulted on scheduling this virtual meeting and I missed = the message? +1... I may have missed something, but I don't remember this... In any = case I can not attend, not even remotely, Saturday. Is there no option to have this meeting during the IETF so that more = people can attend? Yes, I understand that this will result in other collisions... So if it can't be helped this time, +1 on the doodle poll for future = events as well.. I am afraid that not being able to attend this meeting will make it hard = to catch up on, and chime into the discussion. Especially the afternoon = discussion is relevant to me as an implementer of RPKI software at an = RIR (RIPE NCC), and relying party software. Resilience, scalability and = local policy (empowerment) are all hot topics in our community as well = so I would have been very interested in exchanging thoughts on this with = the WG. Regards, Tim Bruijnzeels (Software Engineer, RIPE NCC)= From eosterweil@verisign.com Mon Mar 19 08:38:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DCA21F8838 for ; Mon, 19 Mar 2012 08:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okiNDRdM-BWG for ; Mon, 19 Mar 2012 08:38:23 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 64EEB21F884F for ; Mon, 19 Mar 2012 08:38:22 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT2dS6/+rKV6dcq6IYRk3UN1QdsbiZ2v9@postini.com; Mon, 19 Mar 2012 08:38:23 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2JFcHhO021390; Mon, 19 Mar 2012 11:38:17 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 11:38:16 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <2B8DCAA7-F1D0-48D5-9AE1-E417883D4A60@ripe.net> Date: Mon, 19 Mar 2012 11:38:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <276F1ADB-69D0-478C-B0A6-428658B6D354@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C84EF@Hermes.columbia.ads.sparta.com> <2B8DCAA7-F1D0-48D5-9AE1-E417883D4A60@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 19 Mar 2012 15:38:16.0859 (UTC) FILETIME=[4DBEF6B0:01CD05E6] Cc: Sandra Murphy , "sidr@ietf.org list" Subject: Re: [sidr] agenda for virtual meeting Mar 24 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 15:38:24 -0000 On Mar 19, 2012, at 11:16 AM, Tim Bruijnzeels wrote: > Hi WG, and Sandy as co-chair, >=20 > On 19 Mar 2012, at 15:11, George, Wes wrote: >=20 >> Was the WG consulted on scheduling this virtual meeting and I missed = the message? >=20 > +1... I may have missed something, but I don't remember this... In any = case I can not attend, not even remotely, Saturday. +1 from me too. I would happily have commented that I (and likely = others) were on flights at that time if there had been some kind of an = open call. >=20 > Is there no option to have this meeting during the IETF so that more = people can attend? > Yes, I understand that this will result in other collisions... +1 >=20 > So if it can't be helped this time, +1 on the doodle poll for future = events as well.. +1 Maybe we should just presume that there can be a SIDR meeting on each = of our flights too? We can use the same agenda and just merge the = results? Should be easy, right? ;) Eric= From stbryant@cisco.com Mon Mar 19 10:06:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAD921F885B; Mon, 19 Mar 2012 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.575 X-Spam-Level: X-Spam-Status: No, score=-110.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou1tzZ0gmDP3; Mon, 19 Mar 2012 10:06:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1953D21F8857; Mon, 19 Mar 2012 10:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=745; q=dns/txt; s=iport; t=1332176775; x=1333386375; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=g8D7epULR8cqQPhm+YQq3Z/wUn92Qg6UxELSab+R/OM=; b=dDVapjyjCsWINW0AXsXVc3FpEyFiGEJx9jYUYMmnQvt0PkFZi3ejW7I6 WxyF5nUn3LE6uZ3actD5+atgBlHpQEvqwWblFWnPs3YedKIjku5SVIibq Zh+PVlP4qqDIXm+Aj/Vq/jD1dS4307Polan8+C8pv4gxVru8ELRxAYhG3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEZTZ0+Q/khM/2dsb2JhbABCtkqBB4IiAQIjDzEBPBYYAwIBAgFLAQwBBQIBAR6HaJtCgzwQgU6LVI17kHwElWiOQIECZoJmgVQE X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208";a="132737154" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2012 17:06:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2JH6DIb019167; Mon, 19 Mar 2012 17:06:13 GMT Received: from dhcp-bdlk10-data-vlan300-64-103-107-173.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q2JH66t7011404; Mon, 19 Mar 2012 17:06:06 GMT Message-ID: <4F67677E.9040407@cisco.com> Date: Mon, 19 Mar 2012 17:06:06 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr wg list , "sidr-chairs@tools.ietf.org" , IETF-IESG-Support via RT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" Subject: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:06:28 -0000 The announcement of the SIDR virtual interim failed to reach iesg-secretary@ietf.org within the required two weeks notice. Additionally the agenda was published on Sunday 17th March and thus failed to meet the requirement that "The agenda must be published at least one week before the call or session" . The requirement to provide appropriate notice of the meeting and its agenda is fundamental to the IETF open standards process. Since the failure to meet these requirement may disadvantage some contributors, I regret that I find it necessary to cancel the proposed SIDR interim meeting scheduled for 24/March. I thank those that provided feedback on the matter and apologize for any inconvenience caused. Stewart From ietf-secretariat@ietf.org Mon Mar 19 14:02:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1021E802C; Mon, 19 Mar 2012 14:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BREIzFm3nIOS; Mon, 19 Mar 2012 14:02:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60F721E801C; Mon, 19 Mar 2012 14:02:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319210241.25432.28208.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 14:02:41 -0700 Cc: sidr@ietf.org Subject: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:02:42 -0000 The announcement of the SIDR virtual interim failed to reach iesg-secretary@ietf.org within the required two weeks notice. Additionally the agenda was published on Sunday 17th March and thus failed to meet the requirement that "The agenda must be published at least one week before the call or session" . The requirement to provide appropriate notice of the meeting and its agenda is fundamental to the IETF open standards process. Since the failure to meet these requirement may disadvantage some contributors, I regret that I find it necessary to cancel the proposed SIDR interim meeting scheduled for 24/March. I thank those that provided feedback on the matter and apologize for any inconvenience caused. Stewart From Sandra.Murphy@sparta.com Mon Mar 19 14:37:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6521E8045 for ; Mon, 19 Mar 2012 14:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSg5qqVL95bQ for ; Mon, 19 Mar 2012 14:37:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF921E8044 for ; Mon, 19 Mar 2012 14:37:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2JLbAMr028324 for ; Mon, 19 Mar 2012 16:37:10 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2JLb9B4002841 for ; Mon, 19 Mar 2012 16:37:09 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 17:37:09 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: possible additional meeting times Thread-Index: Ac0GGGkfWSfhktxIR7aWf13WWTnH/A== Date: Mon, 19 Mar 2012 21:37:08 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:37:15 -0000 The routing ADs have suggested that sidr could use the cancelled EAI and/o= r the cancelled CODEC slot to make up for the cancelled virtual meeting. EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. Please speak up as to whether either of these two spots would work. --Sandy= From kent@bbn.com Mon Mar 19 14:40:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B686721E8048 for ; Mon, 19 Mar 2012 14:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phKlxhS8gxwP for ; Mon, 19 Mar 2012 14:40:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B23AB21E8047 for ; Mon, 19 Mar 2012 14:40:55 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49186) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9kJn-000P5m-L9; Mon, 19 Mar 2012 17:40:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Date: Mon, 19 Mar 2012 17:40:52 -0400 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879929242==_ma============" Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:40:56 -0000 --============_-879929242==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Brian, ... >That is not correct, i.e. you misunderstand. > >The desired outcome is that sender/receiver _negotiate_ what is or >is not to be sent, >and the protocol merely enforces what has been agreed upon. The >automatic enforcement >of this high-level policy, is what stops route leaks from being >initiated or propagated. >The policy is still determined by the operators at both ends of a >peering session. >Just like the IP addresses and ASNs, the policies have to match for >BGP session establishment. >Unilateral misconfiguration (whether by accident or deliberate act), >which could have introduced >or propagated route leaks, are prevented. Pairwise enforcement may be useful, in general, but the bigger issue seems to be whether ASes farther along a path see the propagation as a violation of the pairwise agreement. So, it might be useful to view this in two parts: - adding a new feature to BGP that allows explicit negotiation of route marking to support detection of route leaks on a pairwise basis - adding a mechanism to enable ASes father along a path to detect when a route has been propagated in a fashion contrary to the pairwise agreement But, that work is appropriate relative to a later version of the charter (if I may skip ahead to what appears to be your major concern, cited below). >... > >Pot_ay_to, pot_ah_to. > >It should fall to the _WG_ to determine whether BGPSEC _is_, >and/or _should_, be treated as a new feature. >I do not believe the charter explicitly forces >the WG onto one side of the line in the sand (feature/not-feature). The SIDR charter talks about "security enhancement for inter-domain routing protocols" which, IMHO, supports the not new features, just securing extant features, perspective. >And, I believe fundamentally, it _needs_ to be a new feature (set) >on BGP, with all that goes along with it. There seems to be a strong >reluctance among a subset of folks, to say this is a new feature set. >This reluctance is appearing to fracture the WG into an us/them >dichotomy, which is antithetical to the IETF philosophy. At this stage it seems that at most a subset of folks believe these need to be a set of new features, so whose responsible for the "fracture?" Also, I'm curious; what part of the IETF philosophy do you cite as being violated when not everyone in a WG sees eye-to-eye on the scope of the WG? As a WG co-chair I see this problem arise periodically. This WG has a reasonably well-specified charter, which was updated after the first charter (which was very narrow) was satisfied. Your argument seems to be that you don't like the scope of the charter. >If BGPSEC were not a new feature, there would not be any need >to add the BGP options negotiation between peers doing BGPSEC. That's one way to look at it. But, in my response to Eric I explained why one might not view these as new features per se, but rather as just security mechanisms added to the protocol to secure the semantics of the existing feature set in hostile environments. >And, if we acknowledge that it is a new feature, it then is incumbent >on the WG members and chairs, to listen to all the WG participants, >regarding what the requirements are in reaching the charter's goals, >whether they are explicitly in the charter, or implicit consequences >of what is necessary and sufficient in reaching those goals. This >would potentially include other attributes being added, other data >being cryptographically protected, and/or other negotiated peering >parameters. The WG charter defines what we're doing now. It specifies the two vulnerabilities that we are to address, and it specifies some parameters re what tools we are to use in addressing these vulnerabilities. So, for example, if "other data being cryptographically protected" is not directly related to the two vulnerabilities cited in the charter, then it's out of scope for now. Discussing whether the security mechanisms being discussed constitute new features for BGP is not relevant to the charter scope. Steve --============_-879929242==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] route leaks message to IDR
    Brian,

    ...
    That is not correct, i.e. you misunderstand.

    The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent,
    and the protocol merely enforces what has been agreed upon. The automatic enforcement
    of this high-level policy, is what stops route leaks from being initiated or propagated.
    The policy is still determined by the operators at both ends of a peering session.
    Just like the IP addresses and ASNs, the policies have to match for BGP session establishment.
    Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced
    or propagated route leaks, are prevented.

    Pairwise enforcement may be useful, in general, but the bigger issue seems to be whether ASes farther along a path see the propagation as a violation of the pairwise agreement. So, it might be useful to view this in two parts:

            - adding a new feature to BGP that allows explicit negotiation of route marking to support detection of route leaks on a pairwise basis

            - adding a mechanism to enable ASes father along a path to detect when
    a route has been propagated in a fashion contrary to the pairwise agreement

    But, that work is appropriate relative to a later version of the charter (if I may skip ahead to what appears to be your major concern, cited below).

    ...

    Pot_ay_to, pot_ah_to.

    It should fall to the _WG_ to determine whether BGPSEC _is_,
    and/or _should_, be treated as a new feature.
    I do not believe the charter explicitly forces
    the WG onto one side of the line in the sand (feature/not-feature).

    The SIDR charter talks about "security enhancement for inter-domain routing protocols" which, IMHO, supports the not new features, just securing extant features, perspective.

    And, I believe fundamentally, it _needs_ to be a new feature (set)
    on BGP, with all that goes along with it. There seems to be a strong
    reluctance among a subset of folks, to say this is a new feature set.
    This reluctance is appearing to fracture the WG into an us/them
    dichotomy, which is antithetical to the IETF philosophy.

    At this stage it seems that at most a subset of folks believe these need
    to be a set of new features, so whose responsible for the "fracture?"

    Also, I'm curious; what part of the IETF philosophy do you cite as being violated when not everyone in a WG sees eye-to-eye on the scope of the WG?
    As a WG co-chair I see this problem arise periodically.

    This WG has a reasonably well-specified charter, which was updated after the first charter (which was very narrow) was satisfied. Your argument seems to be that you don't like the scope of the charter.

    If BGPSEC were not a new feature, there would not be any need
    to add the BGP options negotiation between peers doing BGPSEC.

    That's one way to look at it. But, in my response to Eric I explained why
    one might not view these as new features per se, but rather as just security mechanisms added to the protocol to secure the semantics of the existing feature set in hostile environments.


    And, if we acknowledge that it is a new feature, it then is incumbent
    on the WG members and chairs, to listen to all the WG participants,
    regarding what the requirements are in reaching the charter's goals,
    whether they are explicitly in the charter, or implicit consequences
    of what is necessary and sufficient in reaching those goals. This
    would potentially include other attributes being added, other data
    being cryptographically protected, and/or other negotiated peering
    parameters.

    The WG charter defines what we're doing now. It specifies the two vulnerabilities that we are to address, and it specifies some parameters re what tools we are to use in addressing these vulnerabilities.

    So, for example, if "other data being cryptographically protected" is not directly related to the  two vulnerabilities cited in the charter, then it's out of scope for now.

    Discussing whether the security mechanisms being discussed constitute new features for BGP is not relevant to the charter scope.

    Steve
    --============_-879929242==_ma============-- From jakob.heitz@ericsson.com Mon Mar 19 14:41:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72A821E804E for ; Mon, 19 Mar 2012 14:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBla+LYpDYi2 for ; Mon, 19 Mar 2012 14:41:07 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6920921E804B for ; Mon, 19 Mar 2012 14:41:07 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2JLeK4Y031174; Mon, 19 Mar 2012 16:41:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 19 Mar 2012 17:41:04 -0400 From: Jakob Heitz To: "Murphy, Sandra" , "sidr@ietf.org" Date: Mon, 19 Mar 2012 17:41:03 -0400 Thread-Topic: possible additional meeting times Thread-Index: Ac0GGGkfWSfhktxIR7aWf13WWTnH/AAAIYqA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3CC676C1@EUSAACMS0701.eamcs.ericsson.se> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:41:08 -0000 Monday works for me. Friday not.=20 -- Jakob Heitz. -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Mur= phy, Sandra Sent: Monday, March 19, 2012 2:37 PM To: sidr@ietf.org Subject: [sidr] possible additional meeting times The routing ADs have suggested that sidr could use the cancelled EAI and/o= r the cancelled CODEC slot to make up for the cancelled virtual meeting. EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. Please speak up as to whether either of these two spots would work. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Mar 19 14:48:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8121E8036 for ; Mon, 19 Mar 2012 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld7ps6s2bYR4 for ; Mon, 19 Mar 2012 14:48:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 01DB621E8012 for ; Mon, 19 Mar 2012 14:48:13 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49189) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S9kQs-000PCd-IW; Mon, 19 Mar 2012 17:48:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> Date: Mon, 19 Mar 2012 17:46:33 -0400 To: "Murphy, Sandra" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:48:14 -0000 At 9:37 PM +0000 3/19/12, Murphy, Sandra wrote: >The routing ADs have suggested that sidr could use the cancelled EAI and/or >the cancelled CODEC slot to make up for the cancelled virtual meeting. > >EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. >CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. > >Please speak up as to whether either of these two spots would work. > >--Sandy Both slots are free on my calendar. Steve From Sandra.Murphy@sparta.com Mon Mar 19 14:58:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED53621E804A for ; Mon, 19 Mar 2012 14:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmBNO0CPnP+H for ; Mon, 19 Mar 2012 14:58:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 551B021E8045 for ; Mon, 19 Mar 2012 14:58:03 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2JLw2Gl028453 for ; Mon, 19 Mar 2012 16:58:02 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2JLw2M4003310 for ; Mon, 19 Mar 2012 16:58:02 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 17:58:02 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: replies needed quickly RE: possible additional meeting times Thread-Index: AQHNBhtaXDjtm3pASESImiw7au6itg== Date: Mon, 19 Mar 2012 21:58:02 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:58:04 -0000 One important point. The routing AD needs to know the decision by COB UTC time on Tuesday (tomor= row). So replies are needed quickly. --Sandy ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com] Sent: Monday, March 19, 2012 5:37 PM To: sidr@ietf.org Subject: [sidr] possible additional meeting times The routing ADs have suggested that sidr could use the cancelled EAI and/o= r the cancelled CODEC slot to make up for the cancelled virtual meeting. EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. Please speak up as to whether either of these two spots would work. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr= From robert@raszuk.net Mon Mar 19 15:20:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A5021F885C for ; Mon, 19 Mar 2012 15:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-5+46qGu1d0 for ; Mon, 19 Mar 2012 15:20:38 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7F54421F885B for ; Mon, 19 Mar 2012 15:20:38 -0700 (PDT) Received: (qmail 12007 invoked by uid 399); 19 Mar 2012 22:20:37 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.28.249.1) by mail1310.opentransfer.com with ESMTPM; 19 Mar 2012 22:20:37 -0000 X-Originating-IP: 83.28.249.1 Message-ID: <4F67B137.7050509@raszuk.net> Date: Mon, 19 Mar 2012 23:20:39 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:20:39 -0000 Hi, The virtual meeting agenda was supposed to take 6h (+2h lunch break). May I ask how below proposed time slots will make up for the cancelled virtual meeting if one is 2h and the other one is just 1h ? Many thx, R. > The routing ADs have suggested that sidr could use the cancelled EAI and/or > the cancelled CODEC slot to make up for the cancelled virtual meeting. > > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. > > Please speak up as to whether either of these two spots would work. > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From brian.peter.dickson@gmail.com Mon Mar 19 15:36:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF16D21E802F for ; Mon, 19 Mar 2012 15:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6DSIS-8CDQY for ; Mon, 19 Mar 2012 15:36:37 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4529221E8012 for ; Mon, 19 Mar 2012 15:36:36 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3855204wib.1 for ; Mon, 19 Mar 2012 15:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NwMX7jySX7lZ3W4nm6vsnnse2wxQCAaWzx80Wuv4Da0=; b=jMvxlBV6rYh/32MyfLl3GgP/N7RNPJw/knoK+mzo/4IhEcR580hG6NB3uPmlbJrOwc uiU1lFgyrdi7ooHD8mpzROhAoyzw5YZM0glHZy1qVkdUfoNwVpeVsLDF1C5F/OpGyaTD 26JIK+zADit+iPJvPgv5mHuM9FS8y5tPdMOyBtnu71neWheZxgj7K+At5XfKGlNIpvSN Ddgx5oCKRYkj4g5EnOxwT8TBIaIp7t/t2iGWA1AO42yfWmvWmEsqbsNz7GcCVHg1JhAw TNbsqEsk5xnKmfk/K0eLnpXaolg6VQDVCqYQUdsASsh1COMZZqswIyzPLKAVZtxHN6fV T2IA== MIME-Version: 1.0 Received: by 10.216.133.93 with SMTP id p71mr8295067wei.10.1332196595381; Mon, 19 Mar 2012 15:36:35 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Mon, 19 Mar 2012 15:36:35 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Date: Mon, 19 Mar 2012 18:36:35 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=0016e6dbde57d6b5e404bba030fd Cc: "sidr@ietf.org" Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:36:37 -0000 --0016e6dbde57d6b5e404bba030fd Content-Type: text/plain; charset=ISO-8859-1 Given that there is not a lot of lead time before this, *and* that the IDR meeting is immediate before this slot... And that there is a moratorium on -00 IDs (meaning any material under discussion is limited to already-submitted items)... Discussing the reqs doc then is fine. Perhaps the time slot adjacency to IDR might make for a good time to consider the issues relating to the material on route-leaks. I suspect that trying to conduct the full proposed agenda, would not be such a good idea. Too rushed, would do more harm than good. I would respectfully suggest that having an agenda of interest to the IDR folk, would actually be a good idea. It is entirely possible that insufficient input from IDR participants is leading to "group think", and that more diverse views would improve the WG output. I also suspect that attracting operator representation (who may be at IDR) would be beneficial as well. I think origin-ops, bgpsec-reqs, and bgpsec-ops would be a good slate. I do not think it would be timely to have a review of bgpsec-protocol, just yet, and in particular, might seem even more exclusionary to have this in the secondary SIDR slot. IMHO. Brian On Mon, Mar 19, 2012 at 5:58 PM, Murphy, Sandra wrote: > One important point. > > The routing AD needs to know the decision by COB UTC time on Tuesday > (tomorrow). > > So replies are needed quickly. > > --Sandy > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, > Sandra [Sandra.Murphy@sparta.com] > Sent: Monday, March 19, 2012 5:37 PM > To: sidr@ietf.org > Subject: [sidr] possible additional meeting times > > The routing ADs have suggested that sidr could use the cancelled EAI > and/or > the cancelled CODEC slot to make up for the cancelled virtual meeting. > > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. > > Please speak up as to whether either of these two spots would work. > > --Sandy > _______________________________________________ > 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 > --0016e6dbde57d6b5e404bba030fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that there is not a lot of lead time before this, *and* that the IDR = meeting is immediate before this slot...
    And that there is a=A0moratori= um on -00 IDs (meaning any material under discussion is limited to already-= submitted items)...

    Discussing the reqs doc then is fine.
    Perhaps= the time slot adjacency to IDR might make for a good time to consider the = issues relating
    to the material on route-leaks.

    I suspect that trying to conduct the full proposed agenda, would= not be such a good idea. Too rushed, would do more harm than good.

    I would respectfully suggest that having an agenda of int= erest to the IDR folk, would actually be a good idea.

    It is entirely possible that insufficient input from ID= R participants is leading to "group think", and that more diverse= views would improve the WG output.

    I also suspect= that attracting operator representation (who may be at IDR) would be benef= icial as well.

    I think origin-ops, bgpsec-reqs, and bgpsec-ops would b= e a good slate.

    I do not think it would be timely = to have a review of bgpsec-protocol, just yet, and in particular, might see= m even more exclusionary to have this in the secondary SIDR slot.

    IMHO.

    Brian

    On Mon, Mar 19, 2012 at 5:58 PM, Murphy, Sandra <Sandra.Murphy@sparta.com> wrote:
    One important point.

    The routing AD needs to know the decision by COB UTC time on Tuesday (tomor= row).

    So replies are needed quickly.

    --Sandy

    ________________________________________
    From: sidr-bounc= es@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com] Sent: Monday, March 19, 2012 5:37 PM
    To: sidr@ietf.org Subject: [sidr] possible additional meeting times

    The routing ADs have suggested that sidr could use the cancelled =A0EAI and= /or
    the cancelled CODEC slot to make up for the cancelled virtual meeting.

    EAI was to meet 1300-1500 Afternoon Session I on Monday March 26.
    CODEC was to meet 1120-1220 Afternoon Session I Friday March 30.

    Please speak up as to whether either of these two spots would work.

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

    --0016e6dbde57d6b5e404bba030fd-- From robert@raszuk.net Mon Mar 19 15:42:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E521E8052 for ; Mon, 19 Mar 2012 15:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWq4IDdt8kLn for ; Mon, 19 Mar 2012 15:42:15 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2738021E8051 for ; Mon, 19 Mar 2012 15:42:15 -0700 (PDT) Received: (qmail 5834 invoked by uid 399); 19 Mar 2012 22:42:14 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.28.249.1) by mail1310.opentransfer.com with ESMTPM; 19 Mar 2012 22:42:14 -0000 X-Originating-IP: 83.28.249.1 Message-ID: <4F67B647.10904@raszuk.net> Date: Mon, 19 Mar 2012 23:42:15 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Brian Dickson References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:42:15 -0000 Hi Brian, > The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent, > and the protocol merely enforces what has been agreed upon. The automatic enforcement > of this high-level policy, is what stops route leaks from being initiated or propagated. > The policy is still determined by the operators at both ends of a peering session. > Just like the IP addresses and ASNs, the policies have to match for BGP session establishment. > Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced > or propagated route leaks, are prevented. I have read your drafts reg route leaks however I would like to clarify one very basic question. When any provider creates a BGP peering relation to his customer it is a common best practice among most if not all ISPs that there is a strict BGP policy applied over the session to make sure only legitimate customer blocks are advertised. If such policy would be required to be share one could use prefix ORF. With this in mind I am really not clear what practical vs theoretical problems you are attempting to solve ? Best regards, R. From Sandra.Murphy@sparta.com Mon Mar 19 15:51:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D33921F87C7 for ; Mon, 19 Mar 2012 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIz73V9PR0aK for ; Mon, 19 Mar 2012 15:51:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 279F421F87C0 for ; Mon, 19 Mar 2012 15:51:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2JMp5Dt028831; Mon, 19 Mar 2012 17:51:05 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2JMp5d6004499; Mon, 19 Mar 2012 17:51:05 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 18:51:04 -0400 From: "Murphy, Sandra" To: Brian Dickson Thread-Topic: [sidr] replies needed quickly RE: possible additional meeting times Thread-Index: AQHNBhtaXDjtm3pASESImiw7au6itpZyeFKA///AMw8= Date: Mon, 19 Mar 2012 22:51:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8921@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6C8921Hermescolumbiaa_" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:51:08 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6C8921Hermescolumbiaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was just asking whether people thought that they coule make the additiona= l time slot. >From the tone of your message, you think you can. Thanks for the suggestion of choosing topics and the tie to idr, particular= ly the route leaks question. --Sandy, speaking as wg co-chair ________________________________ From: Brian Dickson [brian.peter.dickson@gmail.com] Sent: Monday, March 19, 2012 6:36 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] replies needed quickly RE: possible additional meeting = times Given that there is not a lot of lead time before this, *and* that the IDR = meeting is immediate before this slot... And that there is a moratorium on -00 IDs (meaning any material under discu= ssion is limited to already-submitted items)... Discussing the reqs doc then is fine. Perhaps the time slot adjacency to IDR might make for a good time to consid= er the issues relating to the material on route-leaks. I suspect that trying to conduct the full proposed agenda, would not be suc= h a good idea. Too rushed, would do more harm than good. I would respectfully suggest that having an agenda of interest to the IDR f= olk, would actually be a good idea. It is entirely possible that insufficient input from IDR participants is le= ading to "group think", and that more diverse views would improve the WG ou= tput. I also suspect that attracting operator representation (who may be at IDR) = would be beneficial as well. I think origin-ops, bgpsec-reqs, and bgpsec-ops would be a good slate. I do not think it would be timely to have a review of bgpsec-protocol, just= yet, and in particular, might seem even more exclusionary to have this in = the secondary SIDR slot. IMHO. Brian On Mon, Mar 19, 2012 at 5:58 PM, Murphy, Sandra > wrote: One important point. The routing AD needs to know the decision by COB UTC time on Tuesday (tomor= row). So replies are needed quickly. --Sandy ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@iet= f.org] on behalf of Murphy, Sandra [Sandra.Mu= rphy@sparta.com] Sent: Monday, March 19, 2012 5:37 PM To: sidr@ietf.org Subject: [sidr] possible additional meeting times The routing ADs have suggested that sidr could use the cancelled EAI and/o= r the cancelled CODEC slot to make up for the cancelled virtual meeting. EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. Please speak up as to whether either of these two spots would work. --Sandy _______________________________________________ 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 --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6C8921Hermescolumbiaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    I was just asking whether people thought that they coule make the additi= onal time slot.

     

    From the tone of  your message, you think you can.

     

    Thanks for the suggestion of choosing topics and the tie to idr, particu= larly the route leaks question.

     

    --Sandy, speaking as wg co-chair

     

    From: Brian Dickson [brian.peter.dickson@g= mail.com]
    Sent: Monday, March 19, 2012 6:36 PM
    To: Murphy, Sandra
    Cc: sidr@ietf.org
    Subject: Re: [sidr] replies needed quickly RE: possible additional m= eeting times

    Given that there is not a lot of lead time before this, *and* that the= IDR meeting is immediate before this slot...
    And that there is a moratorium on -00 IDs (meaning any material u= nder discussion is limited to already-submitted items)...

    Discussing the reqs doc then is fine.
    Perhaps the time slot adjacency to IDR might make for a good time to c= onsider the issues relating
    to the material on route-leaks.

    I suspect that trying to conduct the full proposed agenda, would not b= e such a good idea. Too rushed, would do more harm than good.

    I would respectfully suggest that having an agenda of interest to the = IDR folk, would actually be a good idea.

    It is entirely possible that insufficient input from IDR participants = is leading to "group think", and that more diverse views would im= prove the WG output.

    I also suspect that attracting operator representation (who may be at = IDR) would be beneficial as well.

    I think origin-ops, bgpsec-reqs, and bgpsec-ops would be a good slate.=

    I do not think it would be timely to have a review of bgpsec-protocol,= just yet, and in particular, might seem even more exclusionary to have thi= s in the secondary SIDR slot.

    IMHO.

    Brian

    On Mon, Mar 19, 2012 at 5:58 PM, Murphy, Sandra = <Sandra.Mu= rphy@sparta.com> wrote:
    One important point.

    The routing AD needs to know the decision by COB UTC time on Tuesday (tomor= row).

    So replies are needed quickly.

    --Sandy

    ________________________________________
    From: sidr-bounc= es@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com] Sent: Monday, March 19, 2012 5:37 PM
    To: sidr@ietf.org Subject: [sidr] possible additional meeting times

    The routing ADs have suggested that sidr could use the cancelled  EAI = and/or
    the cancelled CODEC slot to make up for the cancelled virtual meeting.

    EAI was to meet 1300-1500 Afternoon Session I on Monday March 26.
    CODEC was to meet 1120-1220 Afternoon Session I Friday March 30.

    Please speak up as to whether either of these two spots would work.

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

    --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6C8921Hermescolumbiaa_-- From brian.peter.dickson@gmail.com Mon Mar 19 16:18:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55A921F883D for ; Mon, 19 Mar 2012 16:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8GdOo3AnwVO for ; Mon, 19 Mar 2012 16:18:23 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9321F8834 for ; Mon, 19 Mar 2012 16:18:22 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3880298wib.1 for ; Mon, 19 Mar 2012 16:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=64jL7P5WieL3c4ZmaHNORt4ju3WZG9z8Xw3NvkyeGKA=; b=HRZxwpBzjfzyyIjm226U/iWje6ypsnXG3qTaHCb3y8S5qGyNyMy4VBaX3PnTm51HB8 raR4r2A6pTd0TVvKgYtiUwM5IEHTXJPtS86cAZAiLhf5s7W0tSwO4eSSL65iCO5DFQrp SB7hKk4tS50YIJdKaCuCb10YgEcldRKT8dIQO5b54f6l6ESvAm4th1oJnz4v7FdNzohF XOU1/sYXZ0fcm2nge4C8/AJHP18gy/FU/QK92pCg1f3Zg7B6EhX9t11Znkg2aWwR2tGx 3LRtSPGb8X86WrZ9tyKgPO4OrMiUvpqhary549K9XQ3WRrTKx8j7EdZkgvVImIMGOC4K aAMw== MIME-Version: 1.0 Received: by 10.180.95.74 with SMTP id di10mr34378643wib.1.1332199101940; Mon, 19 Mar 2012 16:18:21 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Mon, 19 Mar 2012 16:18:21 -0700 (PDT) In-Reply-To: <4F67B647.10904@raszuk.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F67B647.10904@raszuk.net> Date: Mon, 19 Mar 2012 19:18:21 -0400 Message-ID: From: Brian Dickson To: robert@raszuk.net Content-Type: multipart/alternative; boundary=f46d041825203dc50304bba0c642 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 23:18:23 -0000 --f46d041825203dc50304bba0c642 Content-Type: text/plain; charset=ISO-8859-1 Hi, Robert, The problem being solved is, that the current methodology places the entire onus on not allowing route leaks, on the immediate upstream provider - who may be small and inexperienced. What is being solved, in particular, is the ability to identify and block route-leaks when one is _more_ than one AS-hop away from the leak, in a guaranteed fashion. Blocking, or even noticing, route leaks via one's peers, can be difficult (or nearly impossible) today. Best practices are good, but consider the level of adoption of BCP-38. Clearly, best practices are not good enough, or we wouldn't have any interest in the "route leak" problem. Reducing the best practice to a "pick one of these four settings (and don't use #4 unless you REALLY know what you are doing)", is a deliberate choice. Make it easy. And, for the most part, the party benefiting significantly, is the person _using_ that setting. Route leaks _hurt_ the leaker/leakee probably as much or more than anyone else. If route filters are seat-belts, then this is an air-bag. Either is good, both is best. Especially when used. Brian On Mon, Mar 19, 2012 at 6:42 PM, Robert Raszuk wrote: > Hi Brian, > > > The desired outcome is that sender/receiver _negotiate_ what is or is not >> to be sent, >> and the protocol merely enforces what has been agreed upon. The automatic >> enforcement >> of this high-level policy, is what stops route leaks from being initiated >> or propagated. >> The policy is still determined by the operators at both ends of a peering >> session. >> Just like the IP addresses and ASNs, the policies have to match for BGP >> session establishment. >> Unilateral misconfiguration (whether by accident or deliberate act), >> which could have introduced >> or propagated route leaks, are prevented. >> > > I have read your drafts reg route leaks however I would like to clarify > one very basic question. > > When any provider creates a BGP peering relation to his customer it is a > common best practice among most if not all ISPs that there is a strict BGP > policy applied over the session to make sure only legitimate customer > blocks are advertised. > > If such policy would be required to be share one could use prefix ORF. > > With this in mind I am really not clear what practical vs theoretical > problems you are attempting to solve ? > > Best regards, > R. > > --f46d041825203dc50304bba0c642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Robert,

    The problem being solved is, that the curren= t methodology places the entire onus on not allowing route leaks, on the im= mediate upstream provider - who may be small and inexperienced.

    What is being solved, in particular, is the ability to identify = and block route-leaks when one is _more_ than one AS-hop away from the leak= , in a guaranteed fashion.

    Blocking, or even notic= ing, route leaks via one's peers, can be difficult (or nearly impossibl= e) today.

    Best practices are good, but consider the level of adop= tion of BCP-38. Clearly, best practices are not good enough, or we wouldn&#= 39;t have any interest in the "route leak" problem.

    Reducing the best practice to a "pick one of these four= settings (and don't use #4 unless you REALLY know what you are doing)&= quot;, is a deliberate choice. Make it easy.
    And, for the most pa= rt, the party benefiting significantly, is the person _using_ that setting.= Route leaks _hurt_ the leaker/leakee probably as much or more than anyone = else.

    If route filters are seat-belts, then this is an air-ba= g. Either is good, both is best. Especially when used.

    =
    Brian

    On Mon, Mar 19, 2012 at= 6:42 PM, Robert Raszuk <robert@raszuk.net> wrote:
    Hi Brian,


    The desired outcome is that sender/receiver _negotiate_ what is or is not t= o be sent,
    and the protocol merely enforces what has been agreed upon. The automatic e= nforcement
    of this high-level policy, is what stops route leaks from being initiated o= r propagated.
    The policy is still determined by the operators at both ends of a peering s= ession.
    Just like the IP addresses and ASNs, the policies have to match for BGP ses= sion establishment.
    Unilateral misconfiguration (whether by accident or deliberate act), which = could have introduced
    or propagated route leaks, are prevented.

    I have read your drafts reg route leaks however I would like to clarify one= very basic question.

    When any provider creates a BGP peering relation to his customer it is a co= mmon best practice among most if not all ISPs that there is a strict BGP po= licy applied over the session to make sure only legitimate customer blocks = are advertised.

    If such policy would be required to be share one could use prefix ORF.

    With this in mind I am really not clear what practical vs theoretical probl= ems you are attempting to solve ?

    Best regards,
    R.


    --f46d041825203dc50304bba0c642-- From kotikalapudi.sriram@nist.gov Mon Mar 19 20:39:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC64221F8843 for ; Mon, 19 Mar 2012 20:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2COQR85ObPzZ for ; Mon, 19 Mar 2012 20:39:07 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4010221F8842 for ; Mon, 19 Mar 2012 20:39:06 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Mar 2012 23:39:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 19 Mar 2012 23:39:03 -0400 From: "Sriram, Kotikalapudi" To: Stephen Kent , Eric Osterweil Date: Mon, 19 Mar 2012 23:35:25 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0C99PpCCdTTcY4Sb638Hu8KPPKTgDS+jFv Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 03:39:08 -0000 >The model I have long (>30 years) employed is that if the secruity checks succeed, >the protocol should operate as before (i.e., w/o the added secruity mechanisms), >because the environment is seen as benign. ---snip--- >I'd like to think that the BGPSEC mechanisms are being developed in a way that tries to adhere to this paradigm. Steve, In light of the your above observations, how do you reflect on the pCount field in BGPSEC? It is not part of the current BGP-4. In BGPSEC, pCount = 0 is used to denote a transparent IXP AS, and the transparent IXP AS number is included in the BGPSEC update (whereas BGP-4 practice was not to include it in the update). And the sum of pCounts for all ASs must now be used to determine the AS path length. Also, in the latest bgpsec-protocol document, we have eliminated the AS_PATH attribute. There are only the NLRI and Signature-Segment fields. The ASNs and the pCounts need to be pulled from the various Signature-Segments in order to construct the AS path. Would you or would you not characterize all this as a change in how the protocol operates (when the security checks have succeeded)? Sriram From wesley.george@twcable.com Mon Mar 19 21:32:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE41C21F88CC for ; Mon, 19 Mar 2012 21:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.573 X-Spam-Level: X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u52TaVo3AfKE for ; Mon, 19 Mar 2012 21:32:29 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id BF05421F88CA for ; Mon, 19 Mar 2012 21:32:28 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,616,1325480400"; d="scan'208";a="339624529" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Mar 2012 00:32:09 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 20 Mar 2012 00:32:27 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Tue, 20 Mar 2012 00:32:29 -0400 Thread-Topic: replies needed quickly RE: possible additional meeting times Thread-Index: AQHNBhtaXDjtm3pASESImiw7au6itpZymKcQ Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 04:32:36 -0000 Yes to either/both Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Monday, March 19, 2012 5:58 PM > To: sidr@ietf.org > Subject: [sidr] replies needed quickly RE: possible additional meeting ti= mes > > One important point. > > The routing AD needs to know the decision by COB UTC time on Tuesday > (tomorrow). > > So replies are needed quickly. > > --Sandy > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, > Sandra [Sandra.Murphy@sparta.com] > Sent: Monday, March 19, 2012 5:37 PM > To: sidr@ietf.org > Subject: [sidr] possible additional meeting times > > The routing ADs have suggested that sidr could use the cancelled EAI and= /or > the cancelled CODEC slot to make up for the cancelled virtual meeting. > > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. > > Please speak up as to whether either of these two spots would work. > > --Sandy > _______________________________________________ > 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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From terry.manderson@icann.org Mon Mar 19 21:36:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7E421F8693 for ; Mon, 19 Mar 2012 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KTKkTE+BduZ for ; Mon, 19 Mar 2012 21:36:00 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA321F8691 for ; Mon, 19 Mar 2012 21:36:00 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 19 Mar 2012 21:35:59 -0700 From: Terry Manderson To: "Murphy, Sandra" , "sidr@ietf.org" Date: Mon, 19 Mar 2012 21:35:53 -0700 Thread-Topic: [sidr] replies needed quickly RE: possible additional meeting times Thread-Index: AQHNBhtaXDjtm3pASESImiw7au6itpZymacd Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 04:36:02 -0000 Monday is my preference. Friday clashes with other work. Cheers Terry On 20/03/12 7:58 AM, "Murphy, Sandra" wrote: > One important point. >=20 > The routing AD needs to know the decision by COB UTC time on Tuesday > (tomorrow). >=20 > So replies are needed quickly. >=20 > --Sandy >=20 > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, > Sandra [Sandra.Murphy@sparta.com] > Sent: Monday, March 19, 2012 5:37 PM > To: sidr@ietf.org > Subject: [sidr] possible additional meeting times >=20 > The routing ADs have suggested that sidr could use the cancelled EAI and= /or > the cancelled CODEC slot to make up for the cancelled virtual meeting. >=20 > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. >=20 > Please speak up as to whether either of these two spots would work. >=20 > --Sandy > _______________________________________________ > 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 From tim@ripe.net Tue Mar 20 01:32:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8570A11E8075 for ; Tue, 20 Mar 2012 01:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuGuaEcmYrvM for ; Tue, 20 Mar 2012 01:32:49 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id B9DE711E8074 for ; Tue, 20 Mar 2012 01:32:48 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S9uUn-0008Ux-M0; Tue, 20 Mar 2012 09:32:48 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1S9uUn-0002eo-G6; Tue, 20 Mar 2012 09:32:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--409636472 From: Tim Bruijnzeels In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Date: Tue, 20 Mar 2012 09:32:45 +0100 Message-Id: <422BE3BA-E08C-4CFA-B54B-05BB30B93C53@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) 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] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719db1c1cabb010943b4537bf84f5c3a765 Cc: "sidr@ietf.org" Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 08:32:49 -0000 --Apple-Mail-1--409636472 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Sandy, WG, Thanks for looking to reschedule this. On 19 Mar 2012, at 22:58, Murphy, Sandra wrote: > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. Monday is perfect for me, Friday is a little close to my train out. Tim --Apple-Mail-1--409636472 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Sandy, WG,

    Thanks for looking to reschedule = this.

    On 19 Mar 2012, at 22:58, Murphy, Sandra = wrote:
    EAI was to = meet 1300-1500 Afternoon Session I on Monday March 26.
    CODEC was to = meet 1120-1220 Afternoon Session I Friday March = 30.

    Monday is perfect for me, = Friday is a little close to my train = out.

    Tim
    = --Apple-Mail-1--409636472-- From weiler@watson.org Tue Mar 20 02:15:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494DE21F885F; Tue, 20 Mar 2012 02:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-QgnI1V+9-Q; Tue, 20 Mar 2012 02:15:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9642121F885C; Tue, 20 Mar 2012 02:15:49 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2K7ZTuQ042930; Tue, 20 Mar 2012 03:35:29 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2K74erY027192; Tue, 20 Mar 2012 03:04:40 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 20 Mar 2012 03:04:40 -0400 (EDT) From: Samuel Weiler To: Stewart Bryant In-Reply-To: <4F67677E.9040407@cisco.com> Message-ID: References: <4F67677E.9040407@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 20 Mar 2012 03:35:30 -0400 (EDT) Cc: IETF-IESG-Support via RT , "iesg@ietf.org" , sidr wg list Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 09:15:50 -0000 On Mon, 19 Mar 2012, Stewart Bryant wrote: > The announcement of the SIDR virtual interim failed to reach > iesg-secretary@ietf.org within the required two weeks notice. I'm puzzled as to why you're raising this now given that you argued on the IETF list last Friday that it was a minor failing: http://www.ietf.org/mail-archive/web/ietf/current/msg72510.html > Additionally the agenda was published on Sunday 17th March and thus > failed to meet the requirement that "The agenda must be published at > least one week before the call or session" . The 17th was Saturday, not Sunday. One could bicker about timezones, but it would be useless splitting of hairs. > The requirement to provide appropriate notice > of the meeting and its agenda is fundamental > to the IETF open standards process. > > Since the failure to meet these requirement may > disadvantage some contributors, I regret that > I find it necessary to cancel the proposed SIDR > interim meeting scheduled for 24/March. > > I thank those that provided feedback on the matter > and apologize for any inconvenience caused. While there may be other substantive reasons to cancel the interim meeting (some of which have been raised on the WG list), the two points cited don't seem to justify that action. -- Sam From stbryant@cisco.com Tue Mar 20 03:12:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4521F861A for ; Tue, 20 Mar 2012 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.575 X-Spam-Level: X-Spam-Status: No, score=-110.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKaa6Ko70G2x for ; Tue, 20 Mar 2012 03:12:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 28DC621F8622 for ; Tue, 20 Mar 2012 03:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=70; q=dns/txt; s=iport; t=1332238350; x=1333447950; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pO3yYzvYROLoEh+6fdW0AO9gGkXMaynNMOM8eU85ZDc=; b=EQplKCGf07etGtYY2dN1ceW+UeLTPgnhv4y5alYzBujT41LBYNxhKqDZ An2aV2zeWsWKhlMh3gkvgIhLDjUbTz1Tw6f2G+eSCqmJgpcy39hw/t1d7 aqDPjpDLe6KVJXczjhf9LAfHwfXl/m8TgAw2lHTuBwjEPUFjZe02fIU9O A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANtWaE+Q/khN/2dsb2JhbABBtkyBB4IKAQEEEgECI0ABEAshFg8JAwIBAgFFBg0BBwEBHodomRqDPBCbXJB+BJVfjj+BAmaCZw X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208";a="132797157" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2012 10:12:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KACSp1004278; Tue, 20 Mar 2012 10:12:29 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q2KACRGA005671; Tue, 20 Mar 2012 10:12:27 GMT Message-ID: <4F68580B.7030609@cisco.com> Date: Tue, 20 Mar 2012 10:12:27 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tim Bruijnzeels References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> <422BE3BA-E08C-4CFA-B54B-05BB30B93C53@ripe.net> In-Reply-To: <422BE3BA-E08C-4CFA-B54B-05BB30B93C53@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:12:31 -0000 I will make a request on your behalf for the Monday slot. Stewart From Sandra.Murphy@sparta.com Tue Mar 20 04:05:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FD421F8691 for ; Tue, 20 Mar 2012 04:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrrgGif3ZZFk for ; Tue, 20 Mar 2012 04:05:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DBDFA21F8679 for ; Tue, 20 Mar 2012 04:04:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2KB4tZ8031497; Tue, 20 Mar 2012 06:04:55 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2KB4tNG013815; Tue, 20 Mar 2012 06:04:55 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 07:04:54 -0400 From: "Murphy, Sandra" To: Eric Osterweil , Stephen Kent Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAA3lj8wAA1+0AAABJ5CAAABkGWAAQsCElY= Date: Tue, 20 Mar 2012 11:04:52 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8A02@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:05:01 -0000 I see in the exchange a suggestion that rewording of the message is needed: >> The addition of sigs to provide integrity and authentication for AS_path= info does not=20 >>add new semantics to BGP. The sigs are used to secure the existing semant= ics. I think=20 >>that's what Sandy meant to convey in her message, but maybe the wording n= eeds to be=20 >>improved. >Yup, I do think the wording needs some work, thnx for the ack. I saw a suggestion from Eric to add a caveat about the acceptance of the in= terim working group consensus. I saw no other provided text, or suggestions of which exact wording is uncl= ear. Please send suggested rewording. --Sandy, speaking as wg co-chair --sent 7:04amEDT, 11:04UTC ________________________________________ From: Eric Osterweil [eosterweil@verisign.com] Sent: Wednesday, March 14, 2012 5:35 PM To: Stephen Kent Cc: George, Wes; Murphy, Sandra; sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR On Mar 14, 2012, at 9:50 PM, Stephen Kent wrote: > At 7:38 PM +0100 3/14/12, Eric Osterweil wrote: >> I'd also like to add that (if I'm not mistaken) much of the BGPSEC work = is _already_ proposing to "add information to BGP updates." For example, I'= m pretty sure there aren't any signatures in BGP right now, right? > > The addition of sigs to provide integrity and authentication for AS_path = info does not add new semantics to BGP. The sigs are used to secure the exi= sting semantics. I think that's what Sandy meant to convey in her message, = but maybe the wording needs to be improved. Yup, I do think the wording needs some work, thnx for the ack. > >> I don't think this text is completely on the level, because my recollec= tion of many of the sidr drafts is that they _ARE_ proposing to add data, s= emantics, and processes to the current operation of BGP. > > New data, yes, new semantics, no. We were heading in that direction with > the "beaconing" mechanism, but that seems to have gone away. So, what happens (for example) when a sig on an update can't be verified? = Is an update not processed and applied as it otherwise would be? I guess i= t seems to me that the semantics of an update have changed if a new portion= of that update (the sig) can cause interpretation of the meaning of that u= pdate to change (i.e. drop updates with unverifiable sigs, update RIB if th= e sigs are verifiable). > >> By my reading of the text below, it sounds like we would only add these= things if we were going to add route leak protection, and that sentiment s= eems wrong to me. > > Add which "things?" When you break the paragraph up, the pronouns are not as easy to associate = w/ their common nouns. ;) "Things," was referring to "data, semantics, and= processes." > >> Moreover, the text below conflates the need for leak protection with so= me as-yet-unspecified approach that must use inline protocol changes. > > That is a fair observation, i.e., if there is agreement that route leaks > can be defined in a rigorous, unambiguous fashion, then it is appropriate > to explore various ways of detecting them. I think we agree that defining leaks and discussing any mechanisms to remed= iate them are separate. > >> I don't know that this has been openly agreed to by all (which is fine = at this stage), but in reaching out to grow w/ this as a starting point I t= hink we present both a problem and an unratified straw-man. I think the te= xt needs to be clarified. > > I think the message asks IDR to look into this, not GROW. Yup... I had a brain fart. It's been a long week already... :-P > >> >> Also, I'd like to request in the 5th para (or the 6th sentence?): >> s/The consensus in the room was/The consensus in the room (though i= t is not clear what portion of the wg agrees) was/ > > seems like a reasonable edit. Kewl, thanks again for the ack! Eric= From eosterweil@verisign.com Tue Mar 20 06:13:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2C21F86F3 for ; Tue, 20 Mar 2012 06:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1naNOD4yBYK3 for ; Tue, 20 Mar 2012 06:13:21 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4986221F867B for ; Tue, 20 Mar 2012 06:13:20 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKT2iCb13y/LiJIxsNC7DUPsqNSn1d5ERn@postini.com; Tue, 20 Mar 2012 06:13:21 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2KDDIAO003403; Tue, 20 Mar 2012 09:13:18 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.123]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 09:13:18 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> Date: Tue, 20 Mar 2012 09:13:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5224E362-A277-4C03-B943-6A9CCF796D01@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C88B2@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Mar 2012 13:13:18.0429 (UTC) FILETIME=[377DA0D0:01CD069B] Cc: "sidr@ietf.org" Subject: Re: [sidr] replies needed quickly RE: possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 13:13:22 -0000 Friday is conflicted for me, but Monday is good. Eric On Mar 19, 2012, at 5:58 PM, Murphy, Sandra wrote: > One important point. >=20 > The routing AD needs to know the decision by COB UTC time on Tuesday = (tomorrow). >=20 > So replies are needed quickly. >=20 > --Sandy >=20 > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, Sandra [Sandra.Murphy@sparta.com] > Sent: Monday, March 19, 2012 5:37 PM > To: sidr@ietf.org > Subject: [sidr] possible additional meeting times >=20 > The routing ADs have suggested that sidr could use the cancelled EAI = and/or > the cancelled CODEC slot to make up for the cancelled virtual meeting. >=20 > EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. > CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. >=20 > Please speak up as to whether either of these two spots would work. >=20 > --Sandy > _______________________________________________ > 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 From ietfdbh@comcast.net Tue Mar 20 07:07:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB521F8674 for ; Tue, 20 Mar 2012 07:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5yRIPgTCE91 for ; Tue, 20 Mar 2012 07:07:14 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCE021F8664 for ; Tue, 20 Mar 2012 07:07:14 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id nq1W1i0020bG4ec5Eq7EDA; Tue, 20 Mar 2012 14:07:14 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta03.westchester.pa.mail.comcast.net with comcast id nq741i00w3Ecudz3Pq7A9R; Tue, 20 Mar 2012 14:07:14 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 20 Mar 2012 10:07:01 -0400 From: David Harrington To: Samuel Weiler , Stewart Bryant Message-ID: Thread-Topic: [sidr] SIDR Interim 24/March is CANCELLED In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "iesg@ietf.org" , sidr wg list Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:07:15 -0000 Hi, FYI. The IESG decided the SIDR Interim should be cancelled because it didn't meet the deadlines. The rules about Interim meetings exist to ensure an open and fair process. Other Wgs who planned an interim but didn't meet the deadlines have also been forced to cancel. BEHAVE WG is one example I am familiar with that had to cancel in the near past. SIDR is expected to play by the same rules as other Wgs. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/20/12 3:04 AM, "Samuel Weiler" wrote: >On Mon, 19 Mar 2012, Stewart Bryant wrote: > >> The announcement of the SIDR virtual interim failed to reach >> iesg-secretary@ietf.org within the required two weeks notice. > >I'm puzzled as to why you're raising this now given that you argued on >the IETF list last Friday that it was a minor failing: >http://www.ietf.org/mail-archive/web/ietf/current/msg72510.html > >> Additionally the agenda was published on Sunday 17th March and thus >> failed to meet the requirement that "The agenda must be published at >> least one week before the call or session" . > >The 17th was Saturday, not Sunday. One could bicker about timezones, >but it would be useless splitting of hairs. > >> The requirement to provide appropriate notice >> of the meeting and its agenda is fundamental >> to the IETF open standards process. >> >> Since the failure to meet these requirement may >> disadvantage some contributors, I regret that >> I find it necessary to cancel the proposed SIDR >> interim meeting scheduled for 24/March. >> >> I thank those that provided feedback on the matter >> and apologize for any inconvenience caused. > >While there may be other substantive reasons to cancel the interim >meeting (some of which have been raised on the WG list), the two >points cited don't seem to justify that action. > >-- Sam From stpeter@stpeter.im Tue Mar 20 08:24:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EC021F8598; Tue, 20 Mar 2012 08:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys4W87xJvPNT; Tue, 20 Mar 2012 08:24:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB821F8599; Tue, 20 Mar 2012 08:24:48 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D379340058; Tue, 20 Mar 2012 09:37:28 -0600 (MDT) Message-ID: <4F68A13F.8000606@stpeter.im> Date: Tue, 20 Mar 2012 09:24:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: sidr wg list , Samuel Weiler , "iesg@ietf.org" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:24:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 8:07 AM, David Harrington wrote: > Hi, > > FYI. The IESG decided the SIDR Interim should be cancelled because > it didn't meet the deadlines. > > The rules about Interim meetings exist to ensure an open and fair > process. Other Wgs who planned an interim but didn't meet the > deadlines have also been forced to cancel. BEHAVE WG is one example > I am familiar with that had to cancel in the near past. Yes, this annoying. But realize that you're not the only ones to have experienced this annoyance. David mentioned BEHAVE WG. I had the same thing happen with the IRI WG last year. The lesson I learned is that I need to plan ahead farther. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ooT8ACgkQNL8k5A2w/vzmZACgwWrmVvs8FSBMJtRtyuwEBC7E UhcAmweBDW7CbUZL5wiR5VVC7nsisCPe =s0Am -----END PGP SIGNATURE----- From bertietf@bwijnen.net Tue Mar 20 08:28:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3566C21F85A4; Tue, 20 Mar 2012 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evtErvmRfVhv; Tue, 20 Mar 2012 08:28:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2621F85AA; Tue, 20 Mar 2012 08:28:18 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SA0yu-00064Z-51; Tue, 20 Mar 2012 16:28:18 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SA0yt-0005T3-St; Tue, 20 Mar 2012 16:28:16 +0100 Message-ID: <4F68A20F.5000506@bwijnen.net> Date: Tue, 20 Mar 2012 16:28:15 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jeffrey Haas , sidr wg list , idr@IETF.ORG References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> In-Reply-To: <4F5FB239.7090009@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41cafc88c9eb0867ebd1beb2fb90d88e4 Subject: [sidr] BGP4 MIB module X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:28:23 -0000 So I had been in discussion with Jeff in order to see if we could get the BGP4-mibv2 module in good shape. Below is out discussion. Those who are interested in this MIB module at all may want to take a look to make sure they agree with the changes being proposed. The most modules we're discussion are: - drafts/draft-ietf-idr-bgp4-mibv2-13.txt - drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt In fact I had below discussion on bgp4-mibv2-12.txt, which resulted in revision 13. On 3/13/12 9:46 PM, Bert Wijnen (IETF) wrote: > On 3/11/12 7:36 PM, Jeffrey Haas wrote: >> Bert, >> >> On Jan 17, 2012, at 9:28 AM, Bert Wijnen (IETF) wrote: >> >>> First, should we have this discussion on the SIDR list? >>> Maybe we can get folk motivated to move this forward >>> that way? >> >> I'm massively behind on SIDR, but will be looking at it today. >> >>> I had to get a new SMICng key first. >> >> Thanks for doing that. >> >>> >>> With the new MIB modules I get: >>> >>> C:\bw\smicng\work>smicng bgp4v2.inc >>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for >>> MAX-ACCESS >>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for >>> MAX-ACCESS >>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent >>> indexing schem >>> e - index items from current table must come after index items from other tables >>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>> consistent indexing >>> scheme - cannot specify an index item from additional "base row" >>> bgp4V2NlriEntry, since ca >>> n have only one "base row" which is bgp4V2PeerEntry >>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in a >>> MANDATORY or cond >>> itional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not in a >>> MANDATORY or con >>> ditional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a MANDATORY >>> or conditi >>> onal group for module "BGP4V2-MIB" >>> >>> *** 5 errors and 2 warnings in parsing >>> >>> C:\bw\smicng\work> >>> >>> W.r.t. >>> E: f(bgp4v2.mi2), (176,5) Item "bgp4V2PeerLocalAddrType" has invalid value for >>> MAX-ACCESS >>> E: f(bgp4v2.mi2), (185,5) Item "bgp4V2PeerLocalAddr" has invalid value for >>> MAX-ACCESS >>> >>> You have >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr >>> } >>> >>> So why are the LOCAL addrtype and addr not-accessible? >>> Or should they be part of the index? >> >> At one point the local address items were part of the index for the table. After some discussion with implementors, they preferred >> that it be left as it is in the existing BGP-4 MIB case. While this is unfortunate, it makes sense. >> >> In BGP, it is typically the case that you'll have a single peering session to a given destination peer address. However, there are >> some corner case peering scenarios where two local addresses on a given router may peer with the same destination address from the >> same instance. This is a *very* uncommon case and it lead to some minor tweaks in the BGP language when RFC 4271 was published. >> >> The problem with putting the local address into the key is that it removes the determinism from the index. If the local address is >> not configured, as may be the case for ebgp peering, you may not know what it would be. In the case of some ibgp, it's also >> possible the local address may change based on what TCP decided it needed. Instead of catering to these uncertain cases, it was >> cleaner to remove the local address from the index. >> >> I have changed these back to read-only. >> > > good. > >>> >>> W.r.t. >>> W: f(bgp4v2.mi2), (1015,13) Row "bgp4V2NlriEntry" does not have a consistent >>> indexing schem >>> e - index items from current table must come after index items from other tables >>> >>> You have: >>> >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2NlriAfi, >>> bgp4V2NlriSafi, >>> bgp4V2NlriPrefixType, >>> bgp4V2NlriPrefix, >>> bgp4V2NlriPrefixLen, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr, >>> bgp4V2NlriIndex >>> } >>> ::= { bgp4V2NlriTable 1 } >>> >>> So pls explain to me that indexing so I can form an opinion if that is OK or >>> not. Besides the warning from SMICng, I also wonder why >>> NlriIndex is the last index column, while it is the first column in the >>> table. >> >> The above up to nlri-index is a natural order walk for BGP. It's also largely what is used in the existing 4273 MIB: >> >> bgp4PathAttrEntry OBJECT-TYPE >> SYNTAX Bgp4PathAttrEntry >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Information about a path to a network." >> INDEX { bgp4PathAttrIpAddrPrefix, >> bgp4PathAttrIpAddrPrefixLen, >> bgp4PathAttrPeer } >> ::= { bgp4PathAttrTable 1 } >> >> Thus, walk all of a given instance. There's no guarantee that 10/8 in one instance is the same as another, especially since the >> instance may map to a VPN VRF. >> Walk a given prefix and peer, as it is in the older table. The prefixes are walked on a per afi/safi basis since the families are >> also incomparable. You then want to see the prefix from all peers. >> >> The nlriindex covers two cases: Multiple routes in RFC 3107 (which I don't believe anyone implements) and BGP add-path. You want >> to see all routes from a given peer and the nlri index lets you see more than one >> >> Hopefully the ordering makes sense in the index. >> >> I now see what you mean about the fact that the object for nlriindex precedes things like the afi and safi. It's mostly just been >> this way for a while. If you feel strongly that it should be re-ordered, we could probably do that since we haven't hit RFC, but >> it will have impact on anyone that may have an in-flight implementation of this. Thus far our fixes have had only minor impact. >> The above is still a warning I get in the revision 13. Would be good to have some comments from (other) implementers or those who plan to implement >> >>> >>> W.r.t. >>> W: f(bgp4v2.mi2), (1516,13) Row "bgp4V2AdjRibsOutEntry" does not have a >>> consistent indexing >>> scheme - cannot specify an index item from additional "base row" >>> bgp4V2NlriEntry, since ca >>> n have only one "base row" which is bgp4V2PeerEntry >>> >>> You have: >>> INDEX { >>> bgp4V2PeerInstance, >>> bgp4V2NlriAfi, >>> bgp4V2NlriSafi, >>> bgp4V2NlriPrefixType, >>> bgp4V2NlriPrefix, >>> bgp4V2NlriPrefixLen, >>> bgp4V2PeerRemoteAddrType, >>> bgp4V2PeerRemoteAddr, >>> bgp4V2AdjRibsOutIndex >>> } >>> ::= { bgp4V2AdjRibsOutTable 1 } >>> >>> Pls explain indexing scheme, so I can form an opinion. >> >> The scheme is identical to the prior explanation. The primary difference is since this is sending routes rather than receiving >> them, we may advertise different routes on egress, hence an OutIndex instead of the prior NlriIndex. >> Same question here >> >>> >>> W.r.t. >>> E: f(bgp4v2.mi2), (1627,16) OBJECT-TYPE "bgp4V2PeerLocalAddr" is not in a >>> MANDATORY or cond >>> itional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1635,16) OBJECT-TYPE "bgp4V2PeerRemoteAddr" is not in a >>> MANDATORY or con >>> ditional group for module "BGP4V2-MIB" >>> E: f(bgp4v2.mi2), (1643,16) OBJECT-TYPE "bgp4V2NlriPrefix" is not in a MANDATORY >>> or conditi >>> onal group for module "BGP4V2-MIB" >>> >>> I thought you were going to do them as comments in a DESCRIPTION clause? >> >> I'm sorry, I've lost track of what we may have discussed with regard to a description update. >> > I saw in your other email that you found it. > WIll check if/when you send new mib module. > OK, seems fixed in rev 13. > And again, our discussion probably should be copied to wg list. > If you agree, I can just copy our conversation to it. > > Bert >> -- Jeff >> >> > From christopher.morrow@gmail.com Tue Mar 20 08:31:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8344E21F84FC; Tue, 20 Mar 2012 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT0LGx2tY0lG; Tue, 20 Mar 2012 08:31:20 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D661D21F84FB; Tue, 20 Mar 2012 08:31:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so186343ghb.31 for ; Tue, 20 Mar 2012 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s2dn0QXn4l/gVPDoxccIHPI+LJr2J3QmPtibTgHw0T0=; b=Bqe+d4DqOjGxKdL6Boan+Z4nVOnTUHuM6QUJudHMa2OBhv6fvi9QcdOMQcYM2oc1GG /uQhmbotcYwxSnKg2t70NEdhetI94Ivrh8rTcQ4Wuznbx9b6jhuR2R1E3lXJLrF68F2J xODmMmjBEM4ZurdBE0q0wj5sgAvUUfRMc7bjM7FKB3HGmHl66Byiu3ZgXOwAYqc0Qq51 oBzithw5IAShV+2DYN6Ru5UGMdwQtdDDLAzHy1WZ0x9VTpbsop10tlKdxN8qrgcAIOQ+ LYI/v4Zu35PlvomKWxr0XdI4Lo1JirHmk+jDUdorEE5rHP0M5QBexOOWzlkH0xb4W0tg IAhg== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr228802oea.61.1332257479230; Tue, 20 Mar 2012 08:31:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Tue, 20 Mar 2012 08:31:19 -0700 (PDT) In-Reply-To: <4F68A13F.8000606@stpeter.im> References: <4F68A13F.8000606@stpeter.im> Date: Tue, 20 Mar 2012 11:31:19 -0400 X-Google-Sender-Auth: EJLOgF7yAYwCNtmIq2BeD6mIxTQ Message-ID: From: Christopher Morrow To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Samuel Weiler , David Harrington , "iesg@ietf.org" , sidr wg list Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:31:20 -0000 On Tue, Mar 20, 2012 at 11:24 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/20/12 8:07 AM, David Harrington wrote: >> Hi, >> >> FYI. The IESG decided the SIDR Interim should be cancelled because >> it didn't meet the deadlines. >> >> The rules about Interim meetings exist to ensure an open and fair >> process. Other Wgs who planned an interim but didn't meet the >> deadlines have also been forced to cancel. BEHAVE WG is one example >> I am familiar with that had to cancel in the near past. > > Yes, this annoying. But realize that you're not the only ones to have > experienced this annoyance. David mentioned BEHAVE WG. I had the same > thing happen with the IRI WG last year. The lesson I learned is that I > need to plan ahead farther. The planning for this wasn't required until very close to the deadlines... certainly next time we can 'plan ahead' because we know what's required. From henk.uijterwaal@gmail.com Tue Mar 20 09:41:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F014621F85D9 for ; Tue, 20 Mar 2012 09:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+qib-DnEA2L for ; Tue, 20 Mar 2012 09:41:03 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 715CA21F85D6 for ; Tue, 20 Mar 2012 09:41:03 -0700 (PDT) Received: by bkuw5 with SMTP id w5so231705bku.31 for ; Tue, 20 Mar 2012 09:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IxT76o1//pqWTNiZgeMwJbXPjz0SaGYrB96gIJ8vY4o=; b=YGQVcZCsCciqv7vOx2BLO3MggOziV9aS6a7wSWsYemkN9HhnNWstQfr/ovLkfW5O86 kFIuVVTc5HzwaL7Poc+B19nKi+1Kc2rvHQbPXLbEe21Y7BDVNWIOLx/s7TmDHakiPUM2 jFsRfZ4szIGAOo4ZarFR5CRqA/o3WFLbdHabZjNQKcrQaDBI1kHzKoblh9MVN4s/R4vu BuB2uMAkxPnLz5SCmvklASagE1ufj05j/DbCIxdRZMACYKn6hjXsP/AS2y9UL990R+Rt d4Fmi7WYB0rrbu933rWAJQ3Y1oo403+vktIxD8ARiQybB3tZ83wdW7NeeZUbC5agvEAe ijzw== Received: by 10.204.128.201 with SMTP id l9mr187506bks.90.1332261662286; Tue, 20 Mar 2012 09:41:02 -0700 (PDT) Received: from geir.local ([2001:980:1203:1:e6ce:8fff:fe11:e7a8]) by mx.google.com with ESMTPS id o7sm4323137bkw.16.2012.03.20.09.41.00 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 09:41:01 -0700 (PDT) Message-ID: <4F68B31A.90204@gmail.com> Date: Tue, 20 Mar 2012 17:40:58 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <4F68A13F.8000606@stpeter.im> In-Reply-To: <4F68A13F.8000606@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: henk@uijterwaal.nl List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:41:05 -0000 On 20/03/2012 16:24, Peter Saint-Andre wrote: > On 3/20/12 8:07 AM, David Harrington wrote: >> Hi, > >> FYI. The IESG decided the SIDR Interim should be cancelled because >> it didn't meet the deadlines. > >> The rules about Interim meetings exist to ensure an open and fair >> process. Other Wgs who planned an interim but didn't meet the >> deadlines have also been forced to cancel. BEHAVE WG is one example >> I am familiar with that had to cancel in the near past. > > Yes, this annoying. But realize that you're not the only ones to have > experienced this annoyance. David mentioned BEHAVE WG. I had the same > thing happen with the IRI WG last year. The lesson I learned is that I > need to plan ahead farther. I don't have a particular opinion if the meeting should be cancelled. However, I noticed that on Friday, the responsible AD said that it was OK to have the meeting despite the small procedural error in organizing it: the meeting was announced on the WG list, but not on the iesg-list. On Monday, the meeting is cancelled. That doesn't look very nice. In the future, I suggest that the IESG makes a decision, then sticks to it, even if an individual AD has approved something he really shouldn't. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From eosterweil@verisign.com Tue Mar 20 10:27:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CE621F86E2 for ; Tue, 20 Mar 2012 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h78aR7W61FeC for ; Tue, 20 Mar 2012 10:27:00 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0721F8684 for ; Tue, 20 Mar 2012 10:26:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKT2i94FNxqCVN0AVp2lEfypMGPv+VIyqF@postini.com; Tue, 20 Mar 2012 10:26:59 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2KHQpo9011919; Tue, 20 Mar 2012 13:26:51 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.123]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 13:26:42 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 20 Mar 2012 13:26:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Mar 2012 17:26:43.0609 (UTC) FILETIME=[9E7BF890:01CD06BE] Cc: Sandra Murphy , "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:27:01 -0000 On Mar 15, 2012, at 6:07 PM, Stephen Kent wrote: > At 10:35 PM +0100 3/14/12, Eric Osterweil wrote: >> ... >>=20 >> So, what happens (for example) when a sig on an update can't be = verified? Is an update not processed and applied as it otherwise would = be? I guess it seems to me that the semantics of an update have changed = if a new portion of that update (the sig) can cause interpretation of = the meaning of that update to change (i.e. drop updates with = unverifiable sigs, update RIB if the sigs are verifiable). >=20 > I see your point, but disagree. Let me try to explain. >=20 > Whenever we add secruity mechanisms to a protocol we create new ways = to cause the protocol to fail to forward data, fail to establish a = connection, etc. The model I have long (>30 years) employed is that if = the secruity checks succeed, the protocol should operate as before = (i.e., w/o the added secruity mechanisms), because the environment is = seen as benign. If the checks fail, the protocol should behave = differently, e.g., something should fail, because the environment is now = perceived as hostile and the protocol (w/o benefit of the secruity = mechanisms) was not engineered to work properly in a hostile = environment. >=20 > Consider for example the fact that many protocols incorporate an = integrity check. If the check fails, that causes a packet to be dropped. = Typically the integrity check mechanism is not secure against attacks; = is just a mechanism designed to detect benign errors. We frequently = introduce crypto-based integrity mechanisms when we want to counter = attacks. Those mechanisms will cause the protocol to behave differently = in attack scenarios, e.g., an attack that might have yielded a valid = checksum will yield an invalid HMAC, and that will cause a packet to be = dropped. This is generally viewed not as a change to the protocol = semantics, but rather an appropriate and natural effect of operating the = protocol in a secure manner. >=20 > I'd like to think that the BGPSEC mechanisms are being developed in a = way that tries to adhere to this paradigm. This is being pedantic in a case where I do not think it is helpful. = You're saying, ``yeah, we changed semantics OUTSIDE of the BGP protocol, = so that once _our_ semantics have decided it is ok to proceed, we can = let BGP do its thing...'' but the you basically go on to say ``oh yeah, = and we put our semantics _in_ BGP (thus changing it), and the results of = our process can greatly impact the global routability of BGP... but = those aren't changing BGP semantics...'' This falls right into the = basic definition of semantics... Also, the caveat that this is >30 year old thinking does not seem = convincing of its correctness (maybe that's just me). >=20 >=20 >> ... >> > >> > Add which "things?" >> When you break the paragraph up, the pronouns are not as easy to = associate w/ their common nouns. ;) "Things," was referring to "data, = semantics, and processes." >=20 > I read the text before the paragraph was sliced and diced, and I felt = that "things" was ambiguous. Now that the ambiguity is removed, I just = disagree with your reading of the text :-). Well, I'm glad we got that cleared up... ;) >=20 >> . >>=20 >> I think we agree that defining leaks and discussing any mechanisms to = remediate them are separate. >=20 > separate, but very interdependent. If the definition is squishy, = countermeasures are likely to be messy, at best. Strongly disagree: If a system is repeatedly subverted along a specific attack vector, the = fact that you can see evidence of subversion, but you can't model it = with a closed form equation or a formal proof does _not_ mean you should = withhold the development of protections! That's like saying: I haven't = got a formal proof for what a local escalation of privileges is, on my = Linux box... I hope Linus comes up w/ a formal definition soon so that I = stop getting pwnd! Ignoring route leaks as security threats is ludicrous. If someone = _does_ formally define them, then great! Until then, the system is = vulnerable and being exploited, and the bgpsec protections will _not_ = protect it... If you want evidence that a solution addresses observed = problems, then take them on specifically! That is the heart of the = foo-sidr-simple-leak-attack-bgpsec-no-help draft: an example of = something that we need to fix. tbqh, the thinking that we need to formally define all threats and = completely/comprehensively quantify them before we acknowledge and = address them is an extremely antiquated way to address the rapidly = evolving threatscape, imho... Eric From eosterweil@verisign.com Tue Mar 20 10:27:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23221F8709 for ; Tue, 20 Mar 2012 10:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.408 X-Spam-Level: X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ti+qn6uoL+O for ; Tue, 20 Mar 2012 10:27:19 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id DA71721F8684 for ; Tue, 20 Mar 2012 10:27:18 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT2i99OkRqBlywLkbIHE2NySYRuKNgTo+@postini.com; Tue, 20 Mar 2012 10:27:18 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2KHRFLM008499; Tue, 20 Mar 2012 13:27:15 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.123]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 13:27:11 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 20 Mar 2012 13:26:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88855834-FE79-4914-95A0-0C265C1C14FD@verisign.com> References: <20120310071140.551.5252.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Mar 2012 17:27:13.0047 (UTC) FILETIME=[B007DA70:01CD06BE] Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:27:20 -0000 Hey Randy, Sorry for the delay. I know we're passed the deadline (totally my bad, = sorry), but here are my comments: On Mar 10, 2012, at 6:07 PM, Randy Bush wrote: >> I just noticed that none of the comments I made in 11/11: >> http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html >> seem to be addressed in this revision. >=20 > great review. and again my apologies for having missed it. i now = have > an internal ticket system so i hope to lose less. >=20 > i have hacked as per following, and will push -03 to repository. this > will leave two days for further discussion and another version before > the dreadline. >=20 >> - 3.5 is not a testable requirement. One cannot be expected to = enumerate the space of all things that are _not_ requirements, so why = put any in? >> - 3.6 ibid >=20 > because these two serve as warnings, to which people might even = object. >=20 > though 3.6, can not fix data-plane, seems obvious to me, to others it > might not be. I totally understand the sentiment behind these items, but in a pedantic = sense, they aren't requirements. Could there be another section for = something like ``considerations?'' If I build a toaster, I fulfill the = above ``reqs,'' right?=20 >=20 >> - 3.7 is too vague. Need to specify where an adversary needs to have = access to link-layer. I have access to the link layer at home, but that = doesn't help me insert traffic between any BGP peers. Can I suggest = modifying the existing text as follows: >> ``... an enemy who has access to the inter-router link layer...'' = the term ``inter-router link'' is borrowed from the cited RFC. >=20 > thanks >=20 >> - 3.8 The word ``MAY'' is a very rough fit for the general notion of = ``requirements.'' I would suggest it is reworded: >> ``A BGPsec design MUST be able to understand and make use of a = security infrastructure (e.g., a PKI) to distribute authenticated data = used as input to >> routing decisions when such a resource is available and = operators wish to configure it for use. Such data includes information = about >> holdings of address space and ASNs, and assertions about = binding of address space to ASNs.'' >=20 > hmm, you are suggesting >=20 > OLD: > 3.8 A BGPsec design MAY make use of a security infrastructure > (e.g., a PKI) to distribute authenticated data used as input = to > routing decisions. Such data include information about > holdings of address space and ASNs, and assertions about > binding of address space to ASNs. >=20 > NEW: > 3.8 A BGPsec design MUST be able to understand and make use of a > security infrastructure (e.g., a PKI) to distribute > authenticated data used as input to routing decisions when = such > a resource is available and operators wish to configure it for > use. Such data includes information about holdings of address > space and ASNs, and assertions about binding of address space > to ASNs. >=20 > i think you are just moving the point of equivocation. our wording = was > meant to leave open the idea that there might be other means than a = PKI. > yours seems to leave open the operator's ability to enable or not. = for > me, the operator's freedom to decide was assumed. >=20 > otoh, the OLD wording could indeed be improved. how about >=20 > 3.8 It is assumed that a BGPsec design will require information > about holdings of address space and ASNs, and assertions about > binding of address space to ASNs. A BGPsec design MAY make = use > of a security infrastructure (e.g., a PKI) to distribute such > authenticated data. >=20 > i think that catches our intent. i am less sure it catches yours. While I may be being pedantic again (it's the software engineer in me, = sorry), I think a requirement should prescribe something that is = necessary for a system in order for its design to be judged as being = correct. The optional nature of ``MAY'' seems counter to this. If we = start from the question, ``why does a BGPsec design need 3.8'' we should = be able to construct the necessary requirement. Maybe something like: 3.8 A BGPsec design must be able to ``verify'' the correctness = of the holdings of address space, the holdings of ASNs, and the binding = between address space and ASNs. Then, the notion of how verification can be done can be externalized to = this document in the afore mentioned ``considerations'' section. Maybe = something like: ``Verification'' can be defined in many ways, including [cite = rpki]... THis is very hand wavy, and I know it's pedantic, but requirements = analysis is the foundation of a system's design, so I've always been = kind of hung up on it. :) >=20 >> - 3.9 is also not worded as a requirement. Does the solution require = that a 4k packet even be discussed? It seems to me that this is not the = right document to discuss this. >=20 > fair point. i'll leave a marker in the next version so as not to = change > numbering so folk can follow the discussion. >=20 >> - 3.10 also does not seem to be a requirement. It is ``requiring'' = an optional exclusion? I suggest it get yanked. >=20 > making explicit that the design need not cover an existing feature fo > BGP, AS-SET, seems important Is that fundamental to securing BGP, or more of a system design issue? = If the latter, I would suggest it get addressed there. I had thought = that ensuring the proper semantics of origin validation and path = validation didn't inherently care about AS-SETs? I do understand that = many want to address this, I just felt it ought to be elsewhere to = maintain the focus on requirements analysis. A design doc can always = make the same statements that carry just as much weight... >=20 >> - 3.11 This also does not seem to be a requirement. Discussing a = design's status in a requirements document is backwards. I suggest this = get yanked. >=20 > making explicit that a design need not maintain the update packing > feature of current bgp would seem important. But requirements come before a design, so it's like putting the cart = before the horse. Requirements, to really properly do their job, need = to be design-agnostic. >=20 >> - 3.19 Seems like it would be hard to test as a requirement. The = problem may be the word ``MAY.'' How could this be made into a testable = requirement? >=20 > i am not sure testability is the issue. if one can look inside the > router, that the database is kept current would seem to be testable. > if the router is a black box, not. >=20 > if you are suggesting that the MAY should be a MUST, i agree and will > make that change. I have to say, it makes much more sense (to me) w/ that change. :) >=20 >> - 3.20 This requirement, again, references a baked design. This = should be restated in a general way. Suggest, >> ``Any inter-AS use of cryptographic hashes or signatures, should = (must?) provide mechanisms for algorithm agility that take the form = of...'' >=20 > how about >=20 > 3.20 Any inter-AS use of cryptographic hashes or signatures, MUST > provide mechanisms for algorithm agility. I like this much better, but can we just think about adding something = that explains (very quickly) what the point is? Maybe something like: s/algorithm agility./algorithm agility, so that specific hashes = or sigs can be changed without degrading the global system's security = protections./ Or something? >=20 >> - 4.5 The term ``real-time'' seems to carry too many = implicit/overloaded meanings. Could we try to disambiguate with = different text. Maybe we can just drop that term ``real-time'' and = leave the rest? >=20 > sure >=20 >> - 4.7 This requirement seems to preach a little bit of a design = instead of being agnostic. Could it be rephrased to be something like: >> ``The output of a router applying BGPsec to a received signed UPDATE = MUST be either unequivocal and conform to a fully specified state in the = design.'' >=20 > sure. >=20 > deep thanks for the thoughtful review, and apologies for having lost = it. My pleasure, and no worries (we all get busy). :) Eric= From weiler@watson.org Tue Mar 20 11:04:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565021F8552; Tue, 20 Mar 2012 11:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQtJJfpr865V; Tue, 20 Mar 2012 11:04:52 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id C42ED21F854E; Tue, 20 Mar 2012 11:04:51 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2KI4lPu072885; Tue, 20 Mar 2012 14:04:47 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2KI4lL7072881; Tue, 20 Mar 2012 14:04:47 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 20 Mar 2012 14:04:47 -0400 (EDT) From: Samuel Weiler To: David Harrington In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 20 Mar 2012 14:04:47 -0400 (EDT) Cc: sidr wg list , "iesg@ietf.org" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:04:53 -0000 On Tue, 20 Mar 2012, David Harrington wrote: > FYI. The IESG decided the SIDR Interim should be cancelled because it > didn't meet the deadlines. Thank you for the clarification that this was an IESG decision, not just Stewart's. I still find the explanation wanting and would like to see a clarification. As I pointed out earlier, the "missed" agenda deadline is so arguable as to be laughable -- indeed, the SIDR list archive shows the agenda as a Saturday, 17 March message but with a time stamp in the wee hours of Sunday morning UTC. From that, I guess that it was still Saturday in her local timezone when the chair sent the agenda. And the other point cited, being the missend of the original announcement, was quite reasonably explained by Stewart on Friday. Are there perhaps other reasons for your decision that haven't been stated? To be clear: I'm not disagreeing with the final decision. Indeed, there may well be good reasons to cancel this interim meeting. But the explanations offered to date don't hold water. -- Sam From kent@bbn.com Tue Mar 20 11:16:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA321F85D9 for ; Tue, 20 Mar 2012 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.011 X-Spam-Level: X-Spam-Status: No, score=-104.011 tagged_above=-999 required=5 tests=[AWL=-2.412, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL4A5MJqWqgn for ; Tue, 20 Mar 2012 11:16:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C7B4621F85D8 for ; Tue, 20 Mar 2012 11:16:21 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49157) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA3bJ-000J22-BR; Tue, 20 Mar 2012 14:16:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> , Date: Tue, 20 Mar 2012 14:16:13 -0400 To: "Sriram, Kotikalapudi" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:16:22 -0000 At 11:35 PM -0400 3/19/12, Sriram, Kotikalapudi wrote: > >The model I have long (>30 years) employed is that if the secruity >checks succeed, >>the protocol should operate as before (i.e., w/o the added secruity >>mechanisms), >>because the environment is seen as benign. >---snip--- >>I'd like to think that the BGPSEC mechanisms are being developed in >>a way that tries to adhere to this paradigm. > >Steve, > >In light of the your above observations, how do you reflect on the >pCount field in BGPSEC? >It is not part of the current BGP-4. >In BGPSEC, pCount = 0 is used to denote a transparent IXP AS, and >the transparent IXP AS number is included in the BGPSEC update >(whereas BGP-4 practice was not to include it in the update). >And the sum of pCounts for all ASs must now be used to determine the >AS path length. > >Also, in the latest bgpsec-protocol document, we have eliminated the >AS_PATH attribute. >There are only the NLRI and Signature-Segment fields. >The ASNs and the pCounts need to be pulled from the various Signature-Segments >in order to construct the AS path. > >Would you or would you not characterize all this as a change in how >the protocol operates >(when the security checks have succeeded)? > >Sriram Sriram, That's a fair, but slightly complicated question. The current BGPSEC protocol design replaces the AS_PATH info with its own data structure. I don't see this syntactic difference as necessarily changing the semantics or features of the protocol. But, one needs to examine the data elements in the BGPSEC structure to see whether they constitute such changes. pCount is a data element used to do two things. It provides a shorthand way for an AS to indicate that its ASN should be counted multiple times when computing path length. This replicates the capability that BGP already offers, through repeated insertion of one's own ASN, so it does not change the features/semantics of BGP. The ability to set pCount to "0" for one's own ASN does diverge from the repeated ASN capability that BGP already embodied. The intended use of this convention is to accommodate transparent route servers at IXPs. The goal is to enable BGPSEC to operate in a fashion that does not penalize ISPs operating at IXPs with such route servers. The mechanism preserves a feature of how BGP is used today. I argue that this is not a new feature, just a way to preserve an existing operational capability that has been deemed important and that is not viewed as a security problem per se. However, allowing a pCount value of "0" creates a potential problem relative to the BGP path security features that BGPSEC strives to secure, if it is used in other contexts. That's an unfortunate side-effect of this mechanism, and the WG will need to decide whether the possible security problems are acceptable as a cost of accommodating transparent route servers. Part of the analysis will need to take into account suggested countermeasures for dealing with the potential vulnerabilities associated with pCount=0. Steve From stpeter@stpeter.im Tue Mar 20 13:38:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907A021F864E; Tue, 20 Mar 2012 13:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wyiaDpBQmGu; Tue, 20 Mar 2012 13:38:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C734C21F8637; Tue, 20 Mar 2012 13:38:23 -0700 (PDT) Received: from dhcp-64-101-72-185.cisco.com (unknown [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E165540058; Tue, 20 Mar 2012 14:51:04 -0600 (MDT) Message-ID: <4F68EABC.8090001@stpeter.im> Date: Tue, 20 Mar 2012 14:38:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Samuel Weiler References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: David Harrington , "iesg@ietf.org" , sidr wg list Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 20:38:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/20/12 12:04 PM, Samuel Weiler wrote: > On Tue, 20 Mar 2012, David Harrington wrote: > >> FYI. The IESG decided the SIDR Interim should be cancelled >> because it didn't meet the deadlines. > > Thank you for the clarification that this was an IESG decision, not > just Stewart's. > > I still find the explanation wanting and would like to see a > clarification. As I pointed out earlier, the "missed" agenda > deadline is so arguable as to be laughable -- indeed, the SIDR list > archive shows the agenda as a Saturday, 17 March message but with a > time stamp in the wee hours of Sunday morning UTC. From that, I > guess that it was still Saturday in her local timezone when the > chair sent the agenda. And the other point cited, being the > missend of the original announcement, was quite reasonably > explained by Stewart on Friday. > > Are there perhaps other reasons for your decision that haven't been > stated? > > To be clear: I'm not disagreeing with the final decision. Indeed, > there may well be good reasons to cancel this interim meeting. But > the explanations offered to date don't hold water. Hi Sam, As an outgoing IESG member with no dogs in this fight, let me point you to the interim meeting rules: http://www.ietf.org/iesg/statement/interim-meetings.html In particular: "Advance notification" and "process" require prior approval of the face-to-face meeting by the relevant Area Director and publication of an announcement on the ietf-announce list. "Advance notification" and "process" require prior approval by the Working Group Chair for the conference call (either audio or video) or jabber session and publication of an announcement on the ietf-announce list. Face-to-face meetings must be announced at least four weeks prior to the meeting. Conference calls and jabber sessions must be announced at least two weeks prior to the event. The announcement for the SIDR virtual interim meeting appeared on the ietf-announce list on March 15th (please note that posting to the WG list is not sufficient according to the text just quoted): http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10034.html Given that the meeting was to occur on March 24th, the two-week advance notification requirement for virtual meetings was simply not met. As noted, I experienced a similar glitch with an IRI WG meeting last year. This kind of thing is unfortunate, but if we're going to ask some working groups to abide by the rules, then all of them should have to. Respectfully, Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9o6rwACgkQNL8k5A2w/vydZACdHGk9Nj6SPsUXc/Yxo4mmKGA/ jesAoLTXnvgXJpJWLBO5vHDziWG1goAo =xgCk -----END PGP SIGNATURE----- From kent@bbn.com Tue Mar 20 14:38:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69A21F865A for ; Tue, 20 Mar 2012 14:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkwfxnmKM8a4 for ; Tue, 20 Mar 2012 14:38:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A50E621F85F9 for ; Tue, 20 Mar 2012 14:38:19 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49162) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SA6kn-000Oux-Nm; Tue, 20 Mar 2012 17:38:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> Date: Tue, 20 Mar 2012 16:50:59 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879843000==_ma============" Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:38:20 -0000 --============_-879843000==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Eric, >... > >This is being pedantic in a case where I do not think it is helpful. Well, I guess it's nice to know that you believe that being pedantic can sometimes be helpful :-). > You're saying, ``yeah, we changed semantics OUTSIDE of the BGP >protocol, so that once _our_ semantics have decided it is ok to >proceed, we can let BGP do its thing...'' but the you basically go >on to say ``oh yeah, and we put our semantics _in_ BGP (thus >changing it), and the results of our process can greatly impact the >global routability of BGP... but those aren't changing BGP >semantics...'' This falls right into the basic definition of >semantics... So, just for the record, I didn't say what you said above. (And I think you left off "... the end of civilization as we know it.") I may have a big mouth, but it's very inappropriate to stuff other people's words into it. Let me try another, more concise phrasing. When one adds secruity to a protocol, the goal is to enable it to operate in a hostile environment with the same semantics that it offered in a non-hostile environment. Of course a secure version of a protocol will exhibit some differences in its operation from an insecure version, especially when one compares the two version in attacks scenarios. If that were not the case, we would not bother adding security to a protocol. The relevant question is whether the fundamental nature of the protocol is altered by the addition of security. >Also, the caveat that this is >30 year old thinking does not seem >convincing of its correctness (maybe that's just me). Well I am older than 30, so at least one interpretation of you critical comment above is accurate :-). And, yes, maybe it is just you. Steve --============_-879843000==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] route leaks message to IDR
    Eric,
    ...

    This is being pedantic in a case where I do not think it is helpful.

    Well, I guess it's nice to know that you believe that being pedantic can sometimes be helpful :-).

      You're saying, ``yeah, we changed semantics OUTSIDE of the BGP protocol, so that once _our_ semantics have decided it is ok to proceed, we can let BGP do its thing...'' but the you basically go on to say ``oh yeah, and we put our semantics _in_ BGP (thus changing it), and the results of our process can greatly impact the global routability of BGP... but those aren't changing BGP semantics...''  This falls right into the basic definition of semantics...

    So, just for the record, I didn't say what you said above. (And I think you left off "... the end of civilization as we know it.") I may have a big mouth, but it's very inappropriate to stuff other people's words into it.

    Let me try another, more concise phrasing. When one adds secruity to a protocol, the goal is to enable it to operate in a hostile environment with the same  semantics that it offered in a non-hostile environment. Of course a secure version of a protocol will exhibit some differences in its operation from an insecure version, especially when one compares the two version in attacks scenarios. If that were not the case, we would not bother adding security to a protocol. The relevant question is whether the fundamental nature of the protocol is altered by the addition of security.

    Also, the caveat that this is >30 year old thinking does not seem convincing of its correctness (maybe that's just me).

    Well I am older than 30, so at least one interpretation of you critical comment above is accurate :-).

    And, yes, maybe it is just you.

    Steve
    --============_-879843000==_ma============-- From robert@raszuk.net Tue Mar 20 14:54:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06F21F8549 for ; Tue, 20 Mar 2012 14:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QBVGVEmX0SU for ; Tue, 20 Mar 2012 14:54:04 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2870E21F8548 for ; Tue, 20 Mar 2012 14:54:04 -0700 (PDT) Received: (qmail 15289 invoked by uid 399); 20 Mar 2012 21:54:03 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.247.137) by mail1310.opentransfer.com with ESMTPM; 20 Mar 2012 21:54:03 -0000 X-Originating-IP: 83.31.247.137 Message-ID: <4F68FC7D.7050700@raszuk.net> Date: Tue, 20 Mar 2012 22:54:05 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Stephen Kent References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Murphy, Sandra" , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:54:05 -0000 Hi Stephen, > pCount is a data element used to do two things. It provides a shorthand > way for an AS to indicate that its ASN should be counted multiple times > when computing path length. This replicates the capability that BGP > already offers, through repeated insertion of one's own ASN, so it does > not change the features/semantics of BGP. I have one clarifying question on the topic of pCount > 0. You are correct that the example you stated will address the typical as-prepend case. However I am not clear how it will deal with "replace as-path" functionality of BGP policies where operator can replace today any arbitrary sequence of ASes in the AS_PATH with his own AS number. There are some legitimate uses for this policy enhancement. Ref: http://goo.gl/xVToJ Example for policy applied by AS 100: Incoming AS_PATH: 10, 20, 30, 35, 60 Policy: replace as-path '30 35' Outgoing AS_PATH: 100, 10, 20, 100, 100, 60 Question: What would be the basic analogy of BGPSEC_Path_Signatures attribute? Would we just see one new signature segment for AS 100 with the pCount of 3 ? Can signature segments be just removed and replaced by prepend analogy ? Many thx, R. From dougm@nist.gov Tue Mar 20 15:03:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B284921F860F for ; Tue, 20 Mar 2012 15:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M83KMsoFYSvH for ; Tue, 20 Mar 2012 15:03:32 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8F521F858F for ; Tue, 20 Mar 2012 15:03:31 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:03:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 20 Mar 2012 18:03:24 -0400 From: "Montgomery, Douglas" To: "robert@raszuk.net" , Stephen Kent Date: Tue, 20 Mar 2012 18:03:22 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0G5MGZzechEnY0Qr6u1N6Nzs8Vpw== Message-ID: In-Reply-To: <4F68FC7D.7050700@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 22:03:32 -0000 On 3/20/12 5:54 PM, "Robert Raszuk" wrote: >Hi Stephen, > >> pCount is a data element used to do two things. It provides a shorthand >> way for an AS to indicate that its ASN should be counted multiple times >> when computing path length. This replicates the capability that BGP >> already offers, through repeated insertion of one's own ASN, so it does >> not change the features/semantics of BGP. > >I have one clarifying question on the topic of pCount > 0. > >You are correct that the example you stated will address the typical >as-prepend case. > >However I am not clear how it will deal with "replace as-path" >functionality of BGP policies where operator can replace today any >arbitrary sequence of ASes in the AS_PATH with his own AS number. There >are some legitimate uses for this policy enhancement. > >Ref: http://goo.gl/xVToJ > > >Example for policy applied by AS 100: > >Incoming AS_PATH: 10, 20, 30, 35, 60 > >Policy: replace as-path '30 35' > >Outgoing AS_PATH: 100, 10, 20, 100, 100, 60 > > >Question: What would be the basic analogy of BGPSEC_Path_Signatures >attribute? Would we just see one new signature segment for AS 100 with >the pCount of 3 ? Can signature segments be just removed and replaced by >prepend analogy ? The forward/backward chaining of PATH_SIGs would prevent AS100 from doing this in a way that would validate ... Unless 100 had the private keys for 20 and 60 to patch up the chain. Dougm From christopher.morrow@gmail.com Tue Mar 20 17:45:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CBB21F84DC for ; Tue, 20 Mar 2012 17:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yocDNlXi82Zf for ; Tue, 20 Mar 2012 17:45:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE1D321F84D8 for ; Tue, 20 Mar 2012 17:45:05 -0700 (PDT) Received: by yenm5 with SMTP id m5so669168yen.31 for ; Tue, 20 Mar 2012 17:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2pv79GcpDjbme32dTKRzey+HAzQUo0XmKfNy1GYA4ss=; b=bUnP92f4WeWNGVnEcVPJ4tjQ1cymxfJkZ11hkEQgy0TtYdaIg8d+UK+qbbLN8mEvFq 5Kf41PhvgzYm8aJAG282eQhp/PIqZfHDCQZZBeo3/6XzPpPw0Sd/Jgjgvsrb1YAnRh4m ti3HTCSR/cLYtIHqDprL6a2VY1sNaWcqcJoQGDqkAEGAQ2DM1ABf7lGhtCcvbQjStGwR g97U2GNGmZXVGuAZ/QiP3EMBlY+Xwcw/hLcKjWyUtUe9Fr+jKk5aWlzOlQA5yWk9IZ/c H9UuHj1RsKv+IytW/mZ/dd9EK/QO4fovI/R1+AujvkP0syGzGQFC95xCo7j3owRkI69W Cfjg== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr2278527oei.71.1332290705392; Tue, 20 Mar 2012 17:45:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Tue, 20 Mar 2012 17:45:05 -0700 (PDT) In-Reply-To: <4F67B137.7050509@raszuk.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8885@Hermes.columbia.ads.sparta.com> <4F67B137.7050509@raszuk.net> Date: Tue, 20 Mar 2012 20:45:05 -0400 X-Google-Sender-Auth: LPdmBvJFdmNtLTgH39J3ZBwSJxg Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] possible additional meeting times X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 00:45:06 -0000 On Mon, Mar 19, 2012 at 6:20 PM, Robert Raszuk wrote: > Hi, > > The virtual meeting agenda was supposed to take 6h (+2h lunch break). > > May I ask how below proposed time slots will make up for the cancelled > virtual meeting if one is 2h and the other one is just 1h ? gzip compression. > Many thx, > R. > > >> The routing ADs have suggested that sidr could use the cancelled =A0EAI >> and/or >> the cancelled CODEC slot to make up for the cancelled virtual meeting. >> >> EAI was to meet 1300-1500 Afternoon Session I on Monday March 26. >> CODEC was to meet 1120-1220 Afternoon Session I Friday March 30. >> >> Please speak up as to whether either of these two spots would work. >> >> --Sandy >> _______________________________________________ >> 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 From russw@riw.us Tue Mar 20 18:59:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1621F21F842D for ; Tue, 20 Mar 2012 18:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2M3rxRoS9mMN for ; Tue, 20 Mar 2012 18:59:44 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FD21F8422 for ; Tue, 20 Mar 2012 18:59:44 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:53017 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAApw-0003nt-4p for sidr@ietf.org; Tue, 20 Mar 2012 21:59:41 -0400 Message-ID: <4F69360A.7010505@riw.us> Date: Tue, 20 Mar 2012 21:59:38 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> , <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com>, <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:59:45 -0000 > BGPSEC is not a new *routing* feature. It is protections for existing > routing features. BGPSEC eliminates certain *bad* routing behavior, > but it should not create *new* routing features. > > The ability to restrict where a receiver can propagate an update is > not presently BGP behavior. Brand new routing behavior. That's the > difference. So, just to ask... Suppose you have this: A---B---C---D | | +---E---+ A sends an advertisement to B, B sends it to C, but B does not send it to E. Your argument is that BGPSEC prevents D from using the path through E by including in the update a series of signatures. Correct? So: 1. The existence of the link from B to E is a fact within the topology shown. 2. Choosing not to use that link is an expression of policy, and a policy that cannot be expressed within BGP itself (on the wire protocol wise) today. Today, in other words, there is no way for B to communicate to D what it's policy is in regards to receiving transit traffic through E from D. 3. So the ability to remove the B to E link from the possible paths available to reach A, enforcable by D, is actually a new feature in BGP. The signatures suggested will actually provide D with information about B's policy towards E --something which is not currently carried in BGP. Hence BGPSEC is a new feature in BGP, and should be treated as such. Russ From eosterweil@verisign.com Tue Mar 20 19:48:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC89121E803C for ; Tue, 20 Mar 2012 19:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq-8AYN4lI3H for ; Tue, 20 Mar 2012 19:48:44 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id B82E721E801A for ; Tue, 20 Mar 2012 19:48:43 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKT2lBiH726WLrmPcjomPYlSV7Z+HzosRh@postini.com; Tue, 20 Mar 2012 19:48:43 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2L2mbth023091; Tue, 20 Mar 2012 22:48:40 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.123]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 22:48:36 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 20 Mar 2012 22:48:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 02:48:36.0985 (UTC) FILETIME=[1D38E690:01CD070D] Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 02:48:45 -0000 On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote: > Eric, >> ... >>=20 >> This is being pedantic in a case where I do not think it is helpful. >=20 > Well, I guess it's nice to know that you believe that being pedantic = can sometimes be helpful :-). For one: pedantic compilers are often helpful when it comes to static = analysis. By extension, _sometimes_ one can make the same argument = (about static analysis) to justify being pedantic for technical = discussions... I'm kinda surprised that you didn't know that... ;) >=20 >> You're saying, ``yeah, we changed semantics OUTSIDE of the BGP = protocol, so that once _our_ semantics have decided it is ok to proceed, = we can let BGP do its thing...'' but the you basically go on to say ``oh = yeah, and we put our semantics _in_ BGP (thus changing it), and the = results of our process can greatly impact the global routability of = BGP... but those aren't changing BGP semantics...'' This falls right = into the basic definition of semantics... >=20 > So, just for the record, I didn't say what you said above. (And I = think you left off "... the end of civilization as we know it.") I may = have a big mouth, but it's very inappropriate to stuff other people's = words into it. Indeed, I was attempting to paraphrase. To clarify, this was how I = interpreted your words, but our audit trail should clearly indicate that = you did _not_ say these things and that I was merely paraphrasing the = message I interpreted from you. Please accept my apologies for any = misunderstanding about this. >=20 > Let me try another, more concise phrasing. When one adds secruity to a = protocol, the goal is to enable it to operate in a hostile environment = with the same semantics that it offered in a non-hostile environment. = Of course a secure version of a protocol will exhibit some differences = in its operation from an insecure version, especially when one compares = the two version in attacks scenarios. Exactly! This is exactly what a semantic difference is! :) > If that were not the case, we would not bother adding security to a = protocol. Very debatable. I wouldn't necessarily impugn the addition of security = semantics to a protocol (sometimes additional expressiveness is needed). > The relevant question is whether the fundamental nature of the = protocol is altered by the addition of security. That may be a question you care about... It might even be one that the = rest of us care about, but that is different than claiming you have not = added semantics (which is where this started). This comment is changing = the subject. >=20 >> Also, the caveat that this is >30 year old thinking does not seem = convincing of its correctness (maybe that's just me). >=20 > Well I am older than 30, so at least one interpretation of you = critical comment above is accurate :-). Speaking of malformed sentences: s/you/your/ ;) >=20 > And, yes, maybe it is just you. Or maybe a line of thought (``thinking'' as you put it) that has gone = unchanged in over 30 years is overdue for having its assumptions = challenged. Security (in particular) is a field in which the landscape = changes, and stale vision can lead to myopia... Many things in the = Internet security theater have obviously changed in 30 years, so the age = of lessons does not necessarily correlate with their relevance. :) Eric=20= From christopher.morrow@gmail.com Tue Mar 20 20:22:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D921E801A for ; Tue, 20 Mar 2012 20:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8vXc3Xcr0Un for ; Tue, 20 Mar 2012 20:22:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5721F8504 for ; Tue, 20 Mar 2012 20:22:32 -0700 (PDT) Received: by yenm5 with SMTP id m5so721225yen.31 for ; Tue, 20 Mar 2012 20:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jDwFHODsYfK45u/HSbec7fN7uij3OMvyQu9hsDEy1Ns=; b=fhOMbGw0mL8JD7++VJBzAr7m//SAUCvjwzNO6OEfezUd1MJbNP61xkgpe4YuaEwKN1 BEicHue9TQ3IkZ3A2jJIHq6ZRqLqlVZMikRLjr22zIVeyCeewVqS+pQiSEdJH75inaGn gcDfwMOyC0ccQb0ejpgjsqCIdvNyaKZk6BKAfWLah59I0b8EzeadhzEpJL21erWRhQV+ 1yKnQIkX0Gdf3H+NfnNaAvfO60oOk9etWudPG1r071Amw573BwDBIYL/4Jbch7hpRD5o 0ckvsSS+weG3Xb0BcA01aDngjWVQZDQBXCjcK1gFgGgPPpIV7b95MIJt1coPfEDEMMTG Em0g== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr2595220oei.71.1332300152076; Tue, 20 Mar 2012 20:22:32 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Tue, 20 Mar 2012 20:22:32 -0700 (PDT) In-Reply-To: <4F69360A.7010505@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> Date: Tue, 20 Mar 2012 23:22:32 -0400 X-Google-Sender-Auth: NeOyc-RJx46HTunRl2tQ83dpimg Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 03:22:33 -0000 On Tue, Mar 20, 2012 at 9:59 PM, Russ White wrote: > > >> BGPSEC is not a new *routing* feature. =A0It is protections for existing >> routing features. =A0BGPSEC eliminates certain *bad* routing behavior, >> but it should not create *new* routing features. >> >> The ability to restrict where a receiver can propagate an update is >> not presently BGP behavior. =A0Brand new routing behavior. =A0That's the >> difference. > > So, just to ask... Suppose you have this: > > A---B---C---D > =A0 =A0| =A0 =A0=A0 | > =A0 =A0+-E-+ (fixed, I think, the ascii-art, which didn't survive at least for me) paths: a-b-c-d a-b-e-c-d both exist in the pict above. > A sends an advertisement to B, B sends it to C, but B does not send it > to E. Your argument is that BGPSEC prevents D from using the path > through E by including in the update a series of signatures. I think the arguement is that D never sees the path that includes E... because B decided not to let that happen (by not sending E the path which it could also decide not to send to C and thus on to D) > > Correct? So: > > 1. The existence of the link from B to E is a fact within the topology > shown. yes > 2. Choosing not to use that link is an expression of policy, and a > policy that cannot be expressed within BGP itself (on the wire protocol > wise) today. Today, in other words, there is no way for B to communicate > to D what it's policy is in regards to receiving transit traffic through > E from D. yes > 3. So the ability to remove the B to E link from the possible paths > available to reach A, enforcable by D, is actually a new feature in BGP. i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'. > The signatures suggested will actually provide D with information about > B's policy towards E --something which is not currently carried in BGP. > Hence BGPSEC is a new feature in BGP, and should be treated as such. no, I don't think so. The signature data from B -> c -> d doesn't say anything about E, you could infer (if you knew the topology) that B has some policy in place to prevent routes traversing E to be made available... Well, really you'd know that between B and E there existed (on some side of the fence, though perhaps at E->C even!) some policy which decided to not send routes of this ilk along. Even more complicated, C could simply not choose to send the E path to D... another policy enforcement point:( or even more.... C could choose to not accept the route from E because, there was some business logic in place (expressed in policy) that said E was a 'customer' of E but was not elligible to transit routes from B and A across this link between C and E! -chris (I think I drove the train off the rails...) From russw@riw.us Wed Mar 21 04:18:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75321F85D9 for ; Wed, 21 Mar 2012 04:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDd+0tCyK+1W for ; Wed, 21 Mar 2012 04:18:29 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 199B221F8596 for ; Wed, 21 Mar 2012 04:18:29 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:50092 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAJYf-0000wc-4p; Wed, 21 Mar 2012 07:18:25 -0400 Message-ID: <4F69B8FA.6080205@riw.us> Date: Wed, 21 Mar 2012 07:18:18 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:18:30 -0000 >> 3. So the ability to remove the B to E link from the possible paths >> available to reach A, enforcable by D, is actually a new feature in BGP. > > i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'. Not advertising something already exists --telling a remote AS that the advertisement shouldn't exist because of policy is something you can't do in BGP today, and hence is a new feature. Of course, I don't quite believe that these signatures won't be used to enforce NO_EXPORT along the way, either --it's much to simple to implement, was included in the original proposal, is still being discussed in private, etc. IMHO, we always fall back to the same point --wanting to enforce policy without telling anyone what that policy is. BGP is designed to tell people how to get from point A to point B, not whether or not this particular path is only available to people who qualify under carpool rules. Break the problem into two pieces: 1. What paths exist. 2. What policies exist. And I think it becomes tractable, with the real ability to trade off between hiding policy, etc. As it is, we're trying to trade off fundamental security against hiding policy --which is always going to leave us spinning around in circles. There may be ways to tell people what is in violation of your policy without telling them what that policy is, but so far we've not found that solution, nor have we even spent time thinking through and defining that sort of problem. Russ From christopher.morrow@gmail.com Wed Mar 21 04:37:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2A21F864A for ; Wed, 21 Mar 2012 04:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1w9DD8UJEFj for ; Wed, 21 Mar 2012 04:37:46 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCE9A21F8606 for ; Wed, 21 Mar 2012 04:37:46 -0700 (PDT) Received: by ggmi1 with SMTP id i1so890403ggm.31 for ; Wed, 21 Mar 2012 04:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FYa0L9UTBtJFmphPEl463vW39DWQd4B7jxLycTI3N/c=; b=LRoWX/BiM+Z6I4xx1og1xoGwL8fupB7SQyA6WnklUh3e7e9Ga5MjbF5C62n5Oc+6o+ tR38Z23PdDC83kM6AriXzv/Oj2jnPlJDJBDJLa9I+4TdF49HnFIm8//V/gJlTc9kVa0A NYhIRsx1GWsbK0F67yf0yNkdYXs8nYnT8/WTn19PQc+HaZzk+cro0p0JKz/vPMRSEmyL Vq8OJAhJcAeWn6J+cW6bmPY3IekgmZnV9D08ZTc9EUZy5/eSffo2jLuHV1Duj9sJceD1 8htFK9OsOzxID/HK/6cooJCtsCxmmKlMT6aAfCF3ADvnzFKNYRsK30T6+T1MxMmJwMvg f/0A== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr4055584obb.71.1332329866394; Wed, 21 Mar 2012 04:37:46 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 04:37:46 -0700 (PDT) In-Reply-To: <4F69B8FA.6080205@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> Date: Wed, 21 Mar 2012 07:37:46 -0400 X-Google-Sender-Auth: ufSlUBIX-f9afhjEP3ri_I9Jitg Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:37:47 -0000 On Wed, Mar 21, 2012 at 7:18 AM, Russ White wrote: > > >>> 3. So the ability to remove the B to E link from the possible paths >>> available to reach A, enforcable by D, is actually a new feature in BGP. >> >> i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'. > > Not advertising something already exists --telling a remote AS that the > advertisement shouldn't exist because of policy is something you can't > do in BGP today, and hence is a new feature. i don't think the case you outline is one of actually telling the remote-as that the path doesn't exist because of policy. the /fact of policy/ can be inferred, and I outlined 3 (or more) places you could infer at D that there was some policy decision happening. I don't think it's at all clear that you can determine where that policy removed the path though. > Of course, I don't quite believe that these signatures won't be used to > enforce NO_EXPORT along the way, either --it's much to simple to > implement, was included in the original proposal, is still being > discussed in private, etc. I suppose: "So what if this is used for no-export" or "so what if this is used to ignore no-export" ? The signatures are there so you can say: "The NLRI I see travelled along the ASPATH shown in the announcement." The policy in place isn't relevant to that... or I don't see that it's relevant. -chris From russw@riw.us Wed Mar 21 04:46:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A0E21F85D9 for ; Wed, 21 Mar 2012 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejQCjaP+8cMF for ; Wed, 21 Mar 2012 04:46:35 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0045221F85FF for ; Wed, 21 Mar 2012 04:46:34 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:50560 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAJzp-000407-Nh; Wed, 21 Mar 2012 07:46:30 -0400 Message-ID: <4F69BF92.2070904@riw.us> Date: Wed, 21 Mar 2012 07:46:26 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:46:35 -0000 > i don't think the case you outline is one of actually telling the > remote-as that the path doesn't exist because of policy. the /fact of > policy/ can be inferred, and I outlined 3 (or more) places you could > infer at D that there was some policy decision happening. I don't > think it's at all clear that you can determine where that policy > removed the path though. If the advertisement is passed on by the intermediate AS (in this case, E), then you're telling the remote AS that path shouldn't exist --this is carrying policy within the protocol. > I suppose: "So what if this is used for no-export" or "so what if this > is used to ignore no-export" ? The signatures are there so you can > say: "The NLRI I see travelled along the ASPATH shown in the > announcement." > > The policy in place isn't relevant to that... or I don't see that it's > relevant. I do --because we're sneaking policy into BGP under the cover of path security. Again, it would be much simpler to break the problem into two pieces, publicly work out which policies need to be enforced, work out what hiding needs to be done, and then work out a solution to those problems. Hiding one complex problem within another is never a good idea over the long term. For instance, because of the WG's insistence on solving a policy problem in a way that can be hidden, while insisting on not calling that problem a policy problem, we've ended up with a solution that is not deployable and doesn't solve a basic AS Path problem. This is, in my experience, exactly what happens when you don't start with a well thought out set of definitions and categories. Russ From christopher.morrow@gmail.com Wed Mar 21 04:51:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB00821F8679 for ; Wed, 21 Mar 2012 04:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-qHSHl-I20e for ; Wed, 21 Mar 2012 04:51:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28B3121F8674 for ; Wed, 21 Mar 2012 04:51:45 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so765926obb.31 for ; Wed, 21 Mar 2012 04:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ScXm+X8GufOvJLyTHkpW1Xdggeidt94iGLVU2d5BMgs=; b=iCZw3VENTIxN1Fq5Gx6T7CcOo+KtlBaMqiWeM9cKui7Rv7RpiXKf9oBfzVFBXpqqC0 7BWUxmLe+tnfx8MDx/uMnjPE7b1sz8e+LNAEG2ndJJYNJB3t1Ji2cWD5lbi3xUaFfrDf 6fk781bax5+0AnRwBwRYpbNpF3o4+3DMKfD3UmcoXtKmNVlm76fgenBeBQpDzPapSoPS 4Ja3ot1JiI00PoHkOJGwGZG+pca++BaNATDIrsyCf5IO6h7LNh7yO3VYr5D+HElWcc/P YW3y3wh9FkvdxIiSbQ4jXxa8bICZ239XA9uwdJK+IhGMq3tiYpcf8bkX/4FuinRx2xuY 9Ljg== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr4116409obb.71.1332330698027; Wed, 21 Mar 2012 04:51:38 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 04:51:37 -0700 (PDT) In-Reply-To: <4F69BF92.2070904@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> Date: Wed, 21 Mar 2012 07:51:37 -0400 X-Google-Sender-Auth: _8NRBJ_I-F1gh043YihlxHEgSvY Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:51:46 -0000 On Wed, Mar 21, 2012 at 7:46 AM, Russ White wrote: > >> i don't think the case you outline is one of actually telling the >> remote-as that the path doesn't exist because of policy. the /fact of >> policy/ can be inferred, and I outlined 3 (or more) places you could >> infer at D that there was some policy decision happening. I don't >> think it's at all clear that you can determine where that policy >> removed the path though. > > If the advertisement is passed on by the intermediate AS (in this case, > E), then you're telling the remote AS that path shouldn't exist --this > is carrying policy within the protocol. your example: So, just to ask... Suppose you have this: A---B---C---D | | +---E---+ "A sends an advertisement to B, B sends it to C, but B does not send it to E. Your argument is that BGPSEC prevents D from using the path through E by including in the update a series of signatures." You state that the path isn't known to E, so he can't possibly send along something he doesn't know. Did I mis-read your example? "A sends to B, B sends to C but NOT E ... D sees only 1 path: C->B->A" I don't see this putting policy in BGP, I don't think anyone has stated that you should send along alternate path info with: "Hey, but don't use this" bits set. Did someone say that? -chris From russw@riw.us Wed Mar 21 05:06:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41A21F84D8 for ; Wed, 21 Mar 2012 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0JlkNXEhymu for ; Wed, 21 Mar 2012 05:06:18 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id D87CA21F8694 for ; Wed, 21 Mar 2012 05:06:14 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:50630 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAKIt-0001NP-3j for sidr@ietf.org; Wed, 21 Mar 2012 08:06:11 -0400 Message-ID: <4F69C432.4080206@riw.us> Date: Wed, 21 Mar 2012 08:06:10 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> In-Reply-To: <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:06:19 -0000 > Let me try another, more concise phrasing. When one adds secruity to a protocol, the goal is to enable it to operate in a hostile environment with the same semantics that it offered in a non-hostile environment. Of course a secure version of a protocol will exhibit some differences in its operation from an insecure version, especially when one compares the two version in attacks scenarios. So, this theory of semantics is interesting --and worth thinking about a little. What is the "semantic of a protocol?" In saying this, we could mean several things. 1. We are trying to secure the semantics of the protocol in terms of what the protocol actually tells us. 2. We are trying to secure the semantics of the protocol in terms of the way in which it tells us something. So compare this to a telephone conversation. In the first sense, I'm told over the telephone that it is raining today. To check, I put my hand out the window to see if the person on the other end of the phone is right. I've used an out of band mechanism to check the validity of the information itself. Or I could encrypt the data path. I've now used an in-band system to verify the information was received correctly (as transmitted). Which semantic is it we're supposed to be securing here? The validity of the database, or the correct transmission of the information end-to-end? If it's the correct transmission of the information, then why have we left some information out? Because it's "too hard?" How hard it is isn't a question on the table --if you're going to validate the transmission of the data, then you need to validate the transmission of all the data. "Too hard" isn't a valid excuse. But other times we seem to be talking about the validity of the database -the so-called "man in the middle attack." What I see happen is the range of semantics we're talking about slips back and forth quite a bit. Most attacks are, I think, simply movements in the semantic range --so you've protected the door, I'll now attack the human with the key. Either: 1. We're trying to secure the bits on the wire end-to-end (even though they don't exist end-to-end). Okay, so leave out the "man in the middle attack" as a requirement, because this has nothing to do with securing the bits on the wire. 2. We're trying to secure the validity of the database. Okay, so leave out the problem of ensuring the data itself isn't changed on the wire, and find a way to validate the database --policy and all. We're playing to the middle here, and the middle is rather muddled. Russ From russw@riw.us Wed Mar 21 05:10:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B246721F86A1 for ; Wed, 21 Mar 2012 05:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoT39nKv0mMJ for ; Wed, 21 Mar 2012 05:10:54 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 36D5B21F86A5 for ; Wed, 21 Mar 2012 05:10:54 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:50668 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAKNO-0004nX-Et; Wed, 21 Mar 2012 08:10:50 -0400 Message-ID: <4F69C549.1050808@riw.us> Date: Wed, 21 Mar 2012 08:10:49 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:10:54 -0000 > A---B---C---D > | | > +---E---+ > > "A sends an advertisement to B, B sends it to C, but B does not send it > to E. Your argument is that BGPSEC prevents D from using the path > through E by including in the update a series of signatures." > I don't see this putting policy in BGP, I don't think anyone has > stated that you should send along alternate path info with: "Hey, but > don't use this" bits set. What is the signature's existence in the advertisement from C, but it's non-existence in the advertisement from E, supposed to mean to D? Not to use the path through E. By adding the signature to the path through C, you've told D not to use other paths, even if they really exist. Without the signature, D would have to pick the phone up and ask. With the signature, they don't need the phone call. If you don't need the phone call to know what B's policy is, you've added the policy to the protocol. The point is you've gone beyond the existence of the path here to the rightful use of the path --and that is policy. Russ From randy@psg.com Wed Mar 21 05:59:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7204821F8523 for ; Wed, 21 Mar 2012 05:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIq7ZYLAUyDr for ; Wed, 21 Mar 2012 05:59:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0221F84D9 for ; Wed, 21 Mar 2012 05:59:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAL8Y-000NJV-3b; Wed, 21 Mar 2012 12:59:34 +0000 Date: Wed, 21 Mar 2012 13:59:32 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4F69360A.7010505@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:59:35 -0000 > So, just to ask... Suppose you have this: > > A---B---C---D > | | > +---E---+ > > 1. The existence of the link from B to E is a fact within the topology > shown. nope, it is not. A is a peer of B and E is a peer of B, so there is no path between B and E for A's prefixes. sorry charlie. randy From russw@riw.us Wed Mar 21 06:10:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48C621F8650 for ; Wed, 21 Mar 2012 06:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGXrfoEFcVDV for ; Wed, 21 Mar 2012 06:10:37 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA821F85CF for ; Wed, 21 Mar 2012 06:10:37 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:51166 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SALJA-0005HU-WF; Wed, 21 Mar 2012 09:10:33 -0400 Message-ID: <4F69D348.4000601@riw.us> Date: Wed, 21 Mar 2012 09:10:32 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Randy Bush References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:10:37 -0000 >> So, just to ask... Suppose you have this: >> >> A---B---C---D >> | | >> +---E---+ >> >> 1. The existence of the link from B to E is a fact within the topology >> shown. > > nope, it is not. A is a peer of B and E is a peer of B, so there is no > path between B and E for A's prefixes. sorry charlie. I can't even begin to make sense out of this --can you explain? If A/B, B/E, and E/D are valid peering pairs, then the path exist. If B chooses not to advertise some route from A to E, that's a local policy decision. If you modify the protocol so D can tell B didn't intend to send a specific set of destinations to E, then you've injected policy into the protocol. There's no way to escape the conclusion that BGPSEC injects policy into BGP itself. Russ From christopher.morrow@gmail.com Wed Mar 21 06:12:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A9921F8674 for ; Wed, 21 Mar 2012 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3JOO8FGaowc for ; Wed, 21 Mar 2012 06:12:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0221F8673 for ; Wed, 21 Mar 2012 06:12:29 -0700 (PDT) Received: by yhkk25 with SMTP id k25so966842yhk.31 for ; Wed, 21 Mar 2012 06:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jqRZUyd14dNz5e1zb5D6Sf63CUVn3lqNwDofb7RTsKU=; b=Uh0XJE1O8RMJObgQ6JlfeqqHBl63mtacisA6QWoQQYx3xQkkYZR0RwDhHZQyCAL8ZI hcqslOH0/ElNGCIianTwFuwWX95z5luNjn15gJkxdXatyViDYWguIEhARPKoWdOAcUBA 8Tdis9a33Z01h/KCwmBgj+HlwAwx/3bA7NuZmHErGJzVh6euR8HxYmxmDcgY6O/T7viq HXtiNtbIuSNe3vzKdA00ZHCnPH9qYsvo2AqXX/gGCFR9ocAEl71/4iBRKfrF+yLFK14Z wLIOhjW/FFxDhuub0Z6McCoNbW6p7MYbx9hV/7ZnxvYycHkBWgMHkL7OuI05NBXzSB55 ou/g== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr4323501oea.61.1332335548871; Wed, 21 Mar 2012 06:12:28 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 06:12:28 -0700 (PDT) In-Reply-To: <4F69C549.1050808@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> Date: Wed, 21 Mar 2012 09:12:28 -0400 X-Google-Sender-Auth: LCH1HzP1tgjWIpWlncSaRK51Ozc Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:12:30 -0000 On Wed, Mar 21, 2012 at 8:10 AM, Russ White wrote: > >> A---B---C---D >> =A0 =A0| =A0 =A0 =A0 | >> =A0 =A0+---E---+ >> >> "A sends an advertisement to B, B sends it to C, but B does not send it >> to E. Your argument is that BGPSEC prevents D from using the path >> through E by including in the update a series of signatures." > >> I don't see this putting policy in BGP, I don't think anyone has >> stated that you should send along alternate path info with: "Hey, but >> don't use this" bits set. > > What is the signature's existence in the advertisement from C, but it's > non-existence in the advertisement from E, supposed to mean to D? Not to > use the path through E. but in your example, B never sends the route to E. There is no route, there is no signature... unless you mistyped and meant that it didn't sign toward E but still sent a route toward E? > By adding the signature to the path through C, you've told D not to use > other paths, even if they really exist. Without the signature, D would hrm, well... I think you really (backing up and assuming you MEANT 'did not SIGN to E, but sent to E' originally) tell E "Hi, you don't do security-foo, so you get a plain route", the follow on receipt at C from E is also not signed (once unsigned, can not resign) C can say: "Hrm, I prefer Signed over unsigned, except for Customer over Peer" or some version of that... In any case C has to select the E path as 'better' in some way for it to send the route along to D. At D, again: "Signed over Unsigned" or whatever their policy is rules the day. > have to pick the phone up and ask. With the signature, they don't need > the phone call. If you don't need the phone call to know what B's policy > is, you've added the policy to the protocol. again, your example was B never sends anything to E, " B does not send it to E" (your words, where 'it' refered to the 'advertisement'). So... you can infer all the policy you want at several points in the picture (as I outlined in my initial response) but... the other bits about signature are not applicable. > The point is you've gone beyond the existence of the path here to the > rightful use of the path --and that is policy. don't think so. -chris > > Russ From russw@riw.us Wed Mar 21 06:44:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CB21F8550 for ; Wed, 21 Mar 2012 06:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOB5Q7fAoka6 for ; Wed, 21 Mar 2012 06:44:02 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id A48DC21F8522 for ; Wed, 21 Mar 2012 06:44:02 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:51343 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SALpW-0002SL-HL; Wed, 21 Mar 2012 09:43:58 -0400 Message-ID: <4F69DB1D.1000905@riw.us> Date: Wed, 21 Mar 2012 09:43:57 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:44:03 -0000 >> The point is you've gone beyond the existence of the path here to the >> rightful use of the path --and that is policy. > don't think so. Yes, you have. Because you've insisted on making the solution work per prefix, you've moved the problem out of the realm of path validation and into the realm of per prefix policy. Paths don't exist per prefix. Paths either exist or don't. Only policies can tell you whether or not a particular path is available for a particular prefix. Since you're signing per prefix/per path, you're actually adding a policy semantic into the protocol that simply didn't exist before BGPSEC. If you backed up to validating the path at the path level, then this problem would go away --but then you're justification for signatures in the packets based on the so call "man in the middle attack," would go away, as well, and the field would be open for a number of different solutions. At that point, you'd actually have to break policy apart as a separate problem, and address it by analyzing the policy problems to be addressed. The problem is you started with a solution, then designed requirements to fit that solution. That the requirements slip this way and that to rule out alternate solutions while keeping your solution as the only viable alternative is a clear symptom of what actually happened. Russ From christopher.morrow@gmail.com Wed Mar 21 06:53:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511DA21F86A5 for ; Wed, 21 Mar 2012 06:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY2UczqbPSUh for ; Wed, 21 Mar 2012 06:53:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA81021F865B for ; Wed, 21 Mar 2012 06:53:13 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so839726obb.31 for ; Wed, 21 Mar 2012 06:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cAF77Iex9DVaTbMmh9NHbzEwEvH+ETWnjU6AzetGqP8=; b=VWbVzp3pyJ8qBQRZYq0qBBgvQLYKuFZBQvFV0bBt3PTkUmGNF8gxzdo+SWEwaOCkVo r4WB1trICgwZV/w3cVzU5PUsI7HpUOtJV3pZllS5+FWgduUPr7hkUYBhBdRcvP1vaICg yF0IgVyi6vmsEduxBOKJeYmRXum74glZl9/kkUPG+URyNucCnrRKyV2kh9MSWybHZ39z AMCutyG/3q1JUVIccTi9noQ7YXkvYRBCjy5M2R9vmvM9YiD3fTpMUO0ZTYXMwoSpWjtC TdBTyLkG78DXVIQygRKjAWmx984vdNBtEvxRMwFAj5p/3b3UkVRM4EYdBc9o/BpaUHnm Iqkg== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr4794713obv.41.1332337993275; Wed, 21 Mar 2012 06:53:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 06:53:13 -0700 (PDT) In-Reply-To: <4F69DB1D.1000905@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> Date: Wed, 21 Mar 2012 09:53:13 -0400 X-Google-Sender-Auth: kxafa6BA3ej-GgOUQxYB0QxQJKk Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:53:14 -0000 On Wed, Mar 21, 2012 at 9:43 AM, Russ White wrote: > >>> The point is you've gone beyond the existence of the path here to the >>> rightful use of the path --and that is policy. > >> don't think so. > > Yes, you have. > > Because you've insisted on making the solution work per prefix, you've > moved the problem out of the realm of path validation and into the realm > of per prefix policy. Paths don't exist per prefix. Paths either exist > or don't. Only policies can tell you whether or not a particular path is > available for a particular prefix. > clearly there's something I'm missing... if we remove the ideas of SIDR form the table, how does your picture change? how does the outcome change? it SEEMS (to me) that the situation is exactly the same... there's no idea of policy in protocol, there is only bgp, and the local decision by B to NOT send a route to E. -chris From russw@riw.us Wed Mar 21 07:08:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6C621F846C for ; Wed, 21 Mar 2012 07:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL2vKSgImhLW for ; Wed, 21 Mar 2012 07:08:42 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id A756221F861C for ; Wed, 21 Mar 2012 07:08:41 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:51462 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAMDN-0001Hp-N3; Wed, 21 Mar 2012 10:08:37 -0400 Message-ID: <4F69E0E4.5040509@riw.us> Date: Wed, 21 Mar 2012 10:08:36 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:08:42 -0000 >>>> The point is you've gone beyond the existence of the path here to the >>>> rightful use of the path --and that is policy. >> >>> don't think so. >> >> Yes, you have. >> >> Because you've insisted on making the solution work per prefix, you've >> moved the problem out of the realm of path validation and into the realm >> of per prefix policy. Paths don't exist per prefix. Paths either exist >> or don't. Only policies can tell you whether or not a particular path is >> available for a particular prefix. > > clearly there's something I'm missing... if we remove the ideas of > SIDR form the table, how does your picture change? how does the > outcome change? it SEEMS (to me) that the situation is exactly the > same... there's no idea of policy in protocol, there is only bgp, and > the local decision by B to NOT send a route to E. But D has no way of knowing this in band without SIDR. With SIDR, it's a matter of looking at the signatures --by the design specs of SIDR itself. When you provide information about who should be advertising to whom across multiple hops, rather than who is connected to whom, then you've moved from existence proofs to policy implementation. Russ From christopher.morrow@gmail.com Wed Mar 21 07:15:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3A021F86F9 for ; Wed, 21 Mar 2012 07:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id docwzYSja77P for ; Wed, 21 Mar 2012 07:15:04 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23F1721F86E4 for ; Wed, 21 Mar 2012 07:15:04 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1060402ggm.31 for ; Wed, 21 Mar 2012 07:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SRH6MCV9ozenMmrGgh4VjRqHQX7Q7NeVlvb4sv9hv84=; b=hSvo7I82aroqaGBwvE8ZwOO621Dn2uMokWyZXBAMRM6GCtFBzNBytTKG3z5jdWWOUZ 2b8XeYegq50VTjyN+AxeoG5BcL+G2OsKEzawbusLMAWae/QwfwfGo7HJmJsdfTC+TAW+ 1E/xetMXHRBp2sAt3IHXSaqmvpN5AI1viT1LT78NzWXc1mYPLGxLwQn3ASopXhlIkEPL nBHoQDd2MrgA2RZuao4SrncAKi0KD8iUCO/zKR7O3JwiV6f8g2jE4AT2q6UgfOG0QCUe y76U/cxAbPxLrObg9DYpXdYaW6RRpEg+TDCqCxQZYubd8agwDvoQ5Gf2d0qCMVbZQs40 KCPw== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr4787391obb.71.1332339303542; Wed, 21 Mar 2012 07:15:03 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 07:15:03 -0700 (PDT) In-Reply-To: <4F69E0E4.5040509@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> Date: Wed, 21 Mar 2012 10:15:03 -0400 X-Google-Sender-Auth: MQzvuNjgUJJoryWKf25mE7YW1Uo Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:15:05 -0000 On Wed, Mar 21, 2012 at 10:08 AM, Russ White wrote: > >>>>> The point is you've gone beyond the existence of the path here to the >>>>> rightful use of the path --and that is policy. >>> >>>> don't think so. >>> >>> Yes, you have. >>> >>> Because you've insisted on making the solution work per prefix, you've >>> moved the problem out of the realm of path validation and into the realm >>> of per prefix policy. Paths don't exist per prefix. Paths either exist >>> or don't. Only policies can tell you whether or not a particular path is >>> available for a particular prefix. >> >> clearly there's something I'm missing... if we remove the ideas of >> SIDR form the table, how does your picture change? how does the >> outcome change? it SEEMS (to me) that the situation is exactly the >> same... there's no idea of policy in protocol, there is only bgp, and >> the local decision by B to NOT send a route to E. > > But D has no way of knowing this in band without SIDR. With SIDR, it's a > matter of looking at the signatures --by the design specs of SIDR no, you never sent anything of this route to E so E never had anything to pass along to C and then to D ... knowledge of this path is not there, in both the SIDR and non-SIDR cases. All D knows in both SIDR and non-SIDR cases is: "Look at that, a path through C to B to A, joy!" In the SIDR case, assuming full secure path along from A -> B -> C -> D, D sees: "Hey lookie! a 'signed' path from C to B to A!" The conversation about E never happens, because .... D has no information about E. > itself. When you provide information about who should be advertising to > whom across multiple hops, rather than who is connected to whom, then where is this information? about 'advertising' ? there's no concept in SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'. > you've moved from existence proofs to policy implementation. no, again this isn't the case. Now I think i'm not the confused one... -chris From russw@riw.us Wed Mar 21 07:52:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A265121F871A for ; Wed, 21 Mar 2012 07:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dHeHDIN5R5P for ; Wed, 21 Mar 2012 07:52:31 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3067E21F8711 for ; Wed, 21 Mar 2012 07:52:31 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:55384 helo=[192.168.100.51]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SAMtm-0006FQ-5d; Wed, 21 Mar 2012 10:52:26 -0400 Message-ID: <4F69EB29.5000507@riw.us> Date: Wed, 21 Mar 2012 10:52:25 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:52:32 -0000 > no, you never sent anything of this route to E so E never had anything > to pass along to C and then to D ... knowledge of this path is not > there, in both the SIDR and non-SIDR cases. All D knows in both SIDR > and non-SIDR cases is: "Look at that, a path through C to B to A, > joy!" If E makes up a route and sends it to D, how does D know which route to choose? Without SIDR --pick up the phone, look at contracts, etc. With SIDR --look at the signature. Clearly you've included information that didn't exist before, and that information is in the form of a policy. > where is this information? about 'advertising' ? there's no concept in > SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'. Because you've attempted to define it out of existence --but that doesn't make it any less real in actual implementations or deployments. You're playing games with hermeneutics here --"That signature isn't about policy, even I've insisted that it be per prefix, and I mean for you to use it to tell you whether or not someone intended to send a route to someone else (and not whether or not such a path exists). But because I'm only trying to prove the positive, and not the negative, I'm not talking about policy." Not being a postmodernist, I still think words actually mean something --they actually correlate to some reality--, and they should mean the same thing from the beginning of the conversation to the end of it. > Now I think i'm not the confused one... We're starting from different presuppositions. You're assuming per prefix policy isn't really policy (because you're not signing something saying not to advertise x), and doesn't need to be dealt with as policy. I'm stating that failure to advertise is a policy decision, and hence when you go about _proving_ someone didn't intend to advertise something, then you're still making a statement of policy. If you're going to deal with policy at all, then deal with policy in total, as policy, in the open, rather than sneaking it in through the back door. Russ From dougm@nist.gov Wed Mar 21 08:00:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EFC21F8736 for ; Wed, 21 Mar 2012 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMEcIID3derG for ; Wed, 21 Mar 2012 08:00:14 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 53E7321F8732 for ; Wed, 21 Mar 2012 08:00:14 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 10:59:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 21 Mar 2012 10:59:48 -0400 From: "Montgomery, Douglas" To: Russ White , Randy Bush Date: Wed, 21 Mar 2012 10:59:46 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0Hcr1+n7huoSg2Si+FBBoy8au3GA== Message-ID: In-Reply-To: <4F69D348.4000601@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:00:16 -0000 I think we are chasing our tails around the use of path as an abstraction of the set of peering relationships and PATH as a specific sequence of announcements of a given prefix (I.e., the AS_PATH attribute). Not that the debate isn't amusing, but sorting out those terms out might allow it to move forward. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 9:10 AM, "Russ White" wrote: > >>> So, just to ask... Suppose you have this: >>> >>> A---B---C---D >>> | | >>> +---E---+ >>> >>> 1. The existence of the link from B to E is a fact within the topology >>> shown. >>=20 >> nope, it is not. A is a peer of B and E is a peer of B, so there is no >> path between B and E for A's prefixes. sorry charlie. > >I can't even begin to make sense out of this --can you explain? If A/B, >B/E, and E/D are valid peering pairs, then the path exist. If B chooses >not to advertise some route from A to E, that's a local policy decision. > >If you modify the protocol so D can tell B didn't intend to send a >specific set of destinations to E, then you've injected policy into the >protocol. There's no way to escape the conclusion that BGPSEC injects >policy into BGP itself. > >Russ >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Wed Mar 21 08:14:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3F621F84F5 for ; Wed, 21 Mar 2012 08:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ+5zuQIYTKY for ; Wed, 21 Mar 2012 08:14:02 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id C5BD821F84EC for ; Wed, 21 Mar 2012 08:14:02 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:55744 helo=[192.168.100.51]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SANEa-00032J-IG; Wed, 21 Mar 2012 11:13:56 -0400 Message-ID: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 11:13:55 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:14:03 -0000 > I think we are chasing our tails around the use of path as an abstraction > of the set of peering relationships and PATH as a specific sequence of > announcements of a given prefix (I.e., the AS_PATH attribute). > > Not that the debate isn't amusing, but sorting out those terms out might > allow it to move forward. Precisely! Which "protocol semantic" are we trying to get right? Are we trying to secure the bits of the protocol on the wire? If so, then why not all the bits? Is there an argument other than, "the rest of the bits are too hard to secure?" If so, then why do we much care about "man in the middle attacks" at the database level? Or are we trying to secure the database --the path itself as an abstract object? If so, how do we deal with policy that should hang off the path? The second way allows us to break the problem into multiple pieces, examine each, and make independent tradeoffs. The first --so far, I don't see where it's led us anyplace useful --partly because we keep munging different pieces of the two ways of looking at the problem together into one "thing" --"we're just securing the semantics of the protocol on the wire, but we really want to secure this and that piece of database integrity by doing so." Russ From shane@castlepoint.net Wed Mar 21 08:32:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC85921E8028 for ; Wed, 21 Mar 2012 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVPIb2-H5a0U for ; Wed, 21 Mar 2012 08:32:05 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0F021E800E for ; Wed, 21 Mar 2012 08:32:05 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 86661268063; Wed, 21 Mar 2012 09:32:04 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 21 Mar 2012 09:32:04 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56843; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 21 Mar 2012 09:32:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:32:05 -0000 Chris, On Mar 21, 2012, at 8:15 AM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 10:08 AM, Russ White wrote: >>=20 >>>>>> The point is you've gone beyond the existence of the path here to = the >>>>>> rightful use of the path --and that is policy. >>>>=20 >>>>> don't think so. >>>>=20 >>>> Yes, you have. >>>>=20 >>>> Because you've insisted on making the solution work per prefix, = you've >>>> moved the problem out of the realm of path validation and into the = realm >>>> of per prefix policy. Paths don't exist per prefix. Paths either = exist >>>> or don't. Only policies can tell you whether or not a particular = path is >>>> available for a particular prefix. >>>=20 >>> clearly there's something I'm missing... if we remove the ideas of >>> SIDR form the table, how does your picture change? how does the >>> outcome change? it SEEMS (to me) that the situation is exactly the >>> same... there's no idea of policy in protocol, there is only bgp, = and >>> the local decision by B to NOT send a route to E. >>=20 >> But D has no way of knowing this in band without SIDR. With SIDR, = it's a >> matter of looking at the signatures --by the design specs of SIDR >=20 > no, you never sent anything of this route to E so E never had anything > to pass along to C and then to D ... knowledge of this path is not > there, in both the SIDR and non-SIDR cases. All D knows in both SIDR > and non-SIDR cases is: "Look at that, a path through C to B to A, > joy!" >=20 > In the SIDR case, assuming full secure path along from A -> B -> C -> = D, D sees: > "Hey lookie! a 'signed' path from C to B to A!" >=20 > The conversation about E never happens, because .... D has no > information about E. But, this is the fundamental problem. Or, more succinctly, the problem = that's not being recognizing here is one of "scoping" (and, not scoping) = of routing announcements. To take a step back, with respect to Route Origin Authentication, the = principle there is that only the Origin ASN(s) bound to a specific IP = prefix is allowed to _inject_ that IP prefix into BGP. In effect, a ROA = is a (out-of-band) policy that defines the scope of a particular IP = prefix as having a root of one, or more, specific Origin ASN's. The = Origin ASN(s) for that IP prefix are effectively the root of a tree that = _COULD_ extend outward through several dozen downstream ASN's. Today, = it's the _policy_ implemented within the individual downstream ASN's = that further _refine_ the scope of that announcement, by expanding or = trimming the branches of the tree of downstream ASN's. Furthermore, as = pointed out in the route-leaks draft, the default (out-of-the-box) = behavior of vanilla BGP is for it to propagate all learned routing = routing information to all parties, i.e.: BGP's default scope =3D = global. Thus, if we're talking about changing BGP to /automatically/ = restrict the 'announcement scope' of a particular prefix, (or set of = paths), then we seem to be talking about a fundamental change to BGP. -shane= From dougm@nist.gov Wed Mar 21 08:37:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBD21E8040 for ; Wed, 21 Mar 2012 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-UkT84sNE3d for ; Wed, 21 Mar 2012 08:37:13 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6519921E800E for ; Wed, 21 Mar 2012 08:37:12 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 11:37:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 21 Mar 2012 11:37:09 -0400 From: "Montgomery, Douglas" To: Russ White Date: Wed, 21 Mar 2012 11:37:06 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0Hd/SPovR3KbrETVWylFTnIVLe6g== Message-ID: In-Reply-To: <4F69F033.7040207@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:37:13 -0000 By "we" I assume you are asking the bigger question about what the broad requirements / objectives should be. The current BGPSEC design, chooses to only focus on the protocol on the wire, and starts with the attributes that had both an identified threat and a existence proof of a reasonable mechanism to address that threat. Discussing if there are other attributes that meet that rubric is an incremental discussion relative to the current proposal. Stepping back to the bigger question if we should be securing something other than what is on the wire (or can be put on the wire with new IDR tweaks) is a much broader discussion of our basic goals. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 11:13 AM, "Russ White" wrote: > >> I think we are chasing our tails around the use of path as an >>abstraction >> of the set of peering relationships and PATH as a specific sequence of >> announcements of a given prefix (I.e., the AS_PATH attribute). >>=20 >> Not that the debate isn't amusing, but sorting out those terms out might >> allow it to move forward. > >Precisely! Which "protocol semantic" are we trying to get right? > >Are we trying to secure the bits of the protocol on the wire? If so, >then why not all the bits? Is there an argument other than, "the rest of >the bits are too hard to secure?" If so, then why do we much care about >"man in the middle attacks" at the database level? > >Or are we trying to secure the database --the path itself as an abstract >object? If so, how do we deal with policy that should hang off the path? > >The second way allows us to break the problem into multiple pieces, >examine each, and make independent tradeoffs. The first --so far, I >don't see where it's led us anyplace useful --partly because we keep >munging different pieces of the two ways of looking at the problem >together into one "thing" --"we're just securing the semantics of the >protocol on the wire, but we really want to secure this and that piece >of database integrity by doing so." > >Russ From christopher.morrow@gmail.com Wed Mar 21 08:44:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573CA21F85FC for ; Wed, 21 Mar 2012 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-zxxpQcsvhm for ; Wed, 21 Mar 2012 08:44:20 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8411E21F8478 for ; Wed, 21 Mar 2012 08:44:20 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1164643ghb.31 for ; Wed, 21 Mar 2012 08:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qr55ZHFb5psVbbtkqy7/r7Jc+70KnPIK5aFeagduDPI=; b=OFKu6pNGTUFzHZMXPJ1fWCYIwXz5T1mHV/2VVgeZCrkpY8Deu04lUpaCwLwbdyxHWB Hw6rzKffAcT6TWN+NMACCRNEpF2tKZrR9WRct0qDjdi7yOqsv2VboNO7EYXG1aqKFqgD 8yxGU/4z49/hUDKOa8uZxDjkPzxf0INMSNSgPJR83mSzyCtqVTHy/462jAwspZHFd2Hq XNiXgqo3aniTsoMav5/NZbCQ/TsUM49mkk7+LhZyyYVkmS+ZhWlSlP4gRpKQoFgCwoVa pNjg8yO5ouP9UDNf11HsCVSVV8t92DDqMQjcQXNPgKJV9P23NkBC8eSpcB4bFckzRc7N dEyg== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr5141248obb.61.1332344659715; Wed, 21 Mar 2012 08:44:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 08:44:19 -0700 (PDT) In-Reply-To: <4F69EB29.5000507@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> <4F69EB29.5000507@riw.us> Date: Wed, 21 Mar 2012 11:44:19 -0400 X-Google-Sender-Auth: 4kLZy1wipO_KytG4UInMQ2TfpQg Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:44:21 -0000 On Wed, Mar 21, 2012 at 10:52 AM, Russ White wrote: > >> no, you never sent anything of this route to E so E never had anything >> to pass along to C and then to D ... knowledge of this path is not >> there, in both the SIDR and non-SIDR cases. All D knows in both SIDR >> and non-SIDR cases is: "Look at that, a path through C to B to A, >> joy!" > > If E makes up a route and sends it to D, how does D know which route to > choose? you are changing your scenario now, fine. In the non-SIDR case... 'as path length wins' (presuming same prefix size). (also presuming that C does not filter E's routes...) In the SIDR case, if E forges the origin AND E -> C (or E->B) is a 'secured' path then origin validation may fail. prefix-filtering could still kick-in, path validation may also fail. Of course, if any of the parts B/C/D accept 'invalid' or 'unknown' (or not-signed) then the SIDR version also gets messy to follow/predict. In either case, the extra information passed along for SIDR-version is just metric-like data to be used at the next hop, or ignored. > > Without SIDR --pick up the phone, look at contracts, etc. > With SIDR --look at the signature. sure. > Clearly you've included information that didn't exist before, and that > information is in the form of a policy. nope, it's bits that you can choose to use or not. >> where is this information? about 'advertising' ? there's no concept in >> SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'. > > Because you've attempted to define it out of existence --but that > doesn't make it any less real in actual implementations or deployments. no, there is no concept (in the sidr world) of publishing 'who you should advertise to' or 'what you should advertise to whom'. > You're playing games with hermeneutics here --"That signature isn't > about policy, even I've insisted that it be per prefix, and I mean for > you to use it to tell you whether or not someone intended to send a > route to someone else (and not whether or not such a path exists). But I really don't think I've said anything about 'intended'. I certainly did not say anything about 'intended to send to someone else'. > because I'm only trying to prove the positive, and not the negative, I'm > not talking about policy." > > Not being a postmodernist, I still think words actually mean something > --they actually correlate to some reality--, and they should mean the > same thing from the beginning of the conversation to the end of it. yes >> Now I think i'm not the confused one... > > We're starting from different presuppositions. You're assuming per > prefix policy isn't really policy (because you're not signing something > saying not to advertise x), and doesn't need to be dealt with as policy. > > I'm stating that failure to advertise is a policy decision, and hence > when you go about _proving_ someone didn't intend to advertise > something, then you're still making a statement of policy. If you're > going to deal with policy at all, then deal with policy in total, as > policy, in the open, rather than sneaking it in through the back door. I'm really not trying to sneak anything. we seem to be at an impasse. -chris From christopher.morrow@gmail.com Wed Mar 21 08:47:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6FA21F869F for ; Wed, 21 Mar 2012 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIrVQI-kE5Ro for ; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6321F85FC for ; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1156245yhk.31 for ; Wed, 21 Mar 2012 08:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YD5dPO0ucOYzWfEm/8feXh5ZAfsdOMJR9buWz/aTmng=; b=TqKOLUBX9xsoGLC1kSW/5I3U4W9c7gxvvIi09+zXFUmjP6cHZxTgRHLqmuoDW7jkwM G7+PjpOFkOwO8Rl920ug5opIA2iL4FVMiGmYWCac+7ohWcznSfYGC/+6xY8ct9nigghH OH+bMk1XaTpg680v51yoWDlVncMmFX16ykMyfvSfIj2hk78UeotIBkPs5KJMJhEyD/tx ZplUKBjURK5mrlJH1J36q+yiBjZoesGPy6nDdSN5bAOrdhDYxidBSNeWH7LQhNaBbo93 dE1Lla+WKSAXCHUwM25cjgnBfBx4e8oBcqWEREK69biONIbR4ARge+Hpmw75vg7xeKdr v42g== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr5183936obb.71.1332344828608; Wed, 21 Mar 2012 08:47:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 08:47:08 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> Date: Wed, 21 Mar 2012 11:47:08 -0400 X-Google-Sender-Auth: E6nIrC3LJO8Xga21_g83b-Or-7k Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:47:10 -0000 On Wed, Mar 21, 2012 at 11:32 AM, Shane Amante wrot= e: > Chris, > > On Mar 21, 2012, at 8:15 AM, Christopher Morrow wrote: >> On Wed, Mar 21, 2012 at 10:08 AM, Russ White wrote: >>> >>>>>>> The point is you've gone beyond the existence of the path here to t= he >>>>>>> rightful use of the path --and that is policy. >>>>> >>>>>> don't think so. >>>>> >>>>> Yes, you have. >>>>> >>>>> Because you've insisted on making the solution work per prefix, you'v= e >>>>> moved the problem out of the realm of path validation and into the re= alm >>>>> of per prefix policy. Paths don't exist per prefix. Paths either exis= t >>>>> or don't. Only policies can tell you whether or not a particular path= is >>>>> available for a particular prefix. >>>> >>>> clearly there's something I'm missing... if we remove the ideas of >>>> SIDR form the table, how does your picture change? how does the >>>> outcome change? it SEEMS (to me) that the situation is exactly the >>>> same... there's no idea of policy in protocol, there is only bgp, and >>>> the local decision by B to NOT send a route to E. >>> >>> But D has no way of knowing this in band without SIDR. With SIDR, it's = a >>> matter of looking at the signatures --by the design specs of SIDR >> >> no, you never sent anything of this route to E so E never had anything >> to pass along to C and then to D ... knowledge of this path is not >> there, in both the SIDR and non-SIDR cases. All D knows in both SIDR >> and non-SIDR cases is: "Look at that, a path through C to B to A, >> joy!" >> >> In the SIDR case, assuming full secure path along from A -> B -> C -> D,= D sees: >> "Hey lookie! a 'signed' path from C to B to A!" >> >> The conversation about E never happens, because .... D has no >> information about E. > > But, this is the fundamental problem. =A0Or, more succinctly, the problem= that's not being recognizing here is one of "scoping" (and, not scoping) o= f routing announcements. > > To take a step back, with respect to Route Origin Authentication, the pri= nciple there is that only the Origin ASN(s) bound to a specific IP prefix i= s allowed to _inject_ that IP prefix into BGP. =A0In effect, a ROA is a (ou= t-of-band) policy that defines the scope of a particular IP prefix as havin= g a root of one, or more, specific Origin ASN's. =A0The Origin ASN(s) for t= hat IP prefix are effectively the root of a tree that _COULD_ extend outwar= d through several dozen downstream ASN's. =A0Today, it's the _policy_ imple= mented within the individual downstream ASN's that further _refine_ the sco= pe of that announcement, by expanding or trimming the branches of the tree = of downstream ASN's. =A0Furthermore, as pointed out in the route-leaks draf= t, the default (out-of-the-box) behavior of vanilla BGP is for it to propag= ate all learned routing routing information to all parties, i.e.: BGP's def= ault scope =3D global. =A0Thus, if we're talking about changing BGP to /aut= omatically/ restrict the 'announcement scope' of a particular prefix, (or s= et of paths), then we seem to be talking about a fundamental change to BGP. but we're not... you can still decide to ignore the origin information and signature information. you COULD decide to check origins and simply remark internally (with a community say) about the status of that origin authentication. You could decide, internally, to simply mark with a community the routes which fail (in several forms) path validation. -chris > -shane From brian.peter.dickson@gmail.com Wed Mar 21 08:50:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6895921F871C for ; Wed, 21 Mar 2012 08:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksWje+u9Yj5G for ; Wed, 21 Mar 2012 08:50:56 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 208A221F871B for ; Wed, 21 Mar 2012 08:50:55 -0700 (PDT) Received: by werb10 with SMTP id b10so1275966wer.31 for ; Wed, 21 Mar 2012 08:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SdMOR75BzWBBNxtY6GAME8mNHV/2Jau0N+uOsmqjxl4=; b=on/WPoyiK86cpnmJ2Hj3jvHAdnzS1jSVJKQnXbsVumeZWbSdgZvSuj8Tp6AcvTmLzA vV5kjT8Hunntjqx4cE21Nd14YkcGDB6BKhoV11QVanOQzLTWlZ4wKI7gD1vEnMj3YkMb TMSsyH8NjfoxFedtDhrMptPvJxXsP9xucwojVsApJrFZdgPWJMc6actVHTyv6c6+Dsjy ceCyG6QMKucFoGtTPGKi1yeUyTnpelM1+9QFJNfLGrE8hudG9mbCV/di7g95oahYqlhg Ee63LlVKuIU8tGZ18PW0c2BeA28OUJ+R3mLDeJ5LWim6fku/x8aJzdXP8S0ZbCU/k/3B BjGg== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr11610880wib.3.1332345055353; Wed, 21 Mar 2012 08:50:55 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 21 Mar 2012 08:50:55 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 11:50:55 -0400 Message-ID: From: Brian Dickson To: "Montgomery, Douglas" Content-Type: multipart/alternative; boundary=f46d0444ee2dbe1da204bbc2c126 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:51:00 -0000 --f46d0444ee2dbe1da204bbc2c126 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas wrote= : > By "we" I assume you are asking the bigger question about what the broad > requirements / objectives should be. > > The current BGPSEC design, chooses to only focus on the protocol on the > wire, and starts with the attributes that had both an identified threat > and a existence proof of a reasonable mechanism to address that threat. > > If that statement were true, I think there would be much more support and progress for the bgpsec-protocol component of the SIDR WG. However, the current interpretation (by whom, is not clear) seems to be, that only certain attributes (AS-path and nothing else?) are included in what is protected. Any attempt to discuss inclusion of other attributes, and reasonable mechanisms for including those in the protection regime, has been shouted down by a small group which includes a self-selected group of implementers. I agree that the design _should_ start with examining threat models against attributes which are used in path selection, and on identifying reasonable mechanism(s) to address those threats. Doing so would require, at a minimum, stopping forward progress on -protocol docs, until the -reqs- and -threat- are adequately addressed. BTW - I am in favor of this, and suggest that this proposal be submitted to the WG to establish general consensus (or not). Chairs? Respectfully, Brian Dickson > Discussing if there are other attributes that meet that rubric is an > incremental discussion relative to the current proposal. > > Stepping back to the bigger question if we should be securing something > other than what is on the wire (or can be put on the wire with new IDR > tweaks) is a much broader discussion of our basic goals. > > dougm > -- > Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIS= T > > > > > > > On 3/21/12 11:13 AM, "Russ White" wrote: > > > > >> I think we are chasing our tails around the use of path as an > >>abstraction > >> of the set of peering relationships and PATH as a specific sequence of > >> announcements of a given prefix (I.e., the AS_PATH attribute). > >> > >> Not that the debate isn't amusing, but sorting out those terms out mig= ht > >> allow it to move forward. > > > >Precisely! Which "protocol semantic" are we trying to get right? > > > >Are we trying to secure the bits of the protocol on the wire? If so, > >then why not all the bits? Is there an argument other than, "the rest of > >the bits are too hard to secure?" If so, then why do we much care about > >"man in the middle attacks" at the database level? > > > >Or are we trying to secure the database --the path itself as an abstract > >object? If so, how do we deal with policy that should hang off the path? > > > >The second way allows us to break the problem into multiple pieces, > >examine each, and make independent tradeoffs. The first --so far, I > >don't see where it's led us anyplace useful --partly because we keep > >munging different pieces of the two ways of looking at the problem > >together into one "thing" --"we're just securing the semantics of the > >protocol on the wire, but we really want to secure this and that piece > >of database integrity by doing so." > > > >Russ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --f46d0444ee2dbe1da204bbc2c126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Mar 21, 2012 at 11:37 AM, Montgo= mery, Douglas <dougm= @nist.gov> wrote:
    By "we" I assume you are asking the bigger question about what th= e broad
    requirements / objectives should be.

    The current BGPSEC design, chooses to only focus on the protocol on the
    wire, and starts with the attributes that had both an identified threat
    and a existence proof of a reasonable mechanism to address that threat.


    If that statement were true, I think there would = be much more support and progress
    for the bgpsec-protocol component of t= he SIDR WG.

    However, the current interpretation (by whom, is not cle= ar) seems to be,
    that only certain attributes (AS-path and nothing else?) are included in wh= at is protected.

    Any attempt to discuss inclusion of other attribute= s, and reasonable mechanisms
    for including those in the protection regim= e, has been shouted down by a small group
    which includes a self-selected group of implementers.

    I agree that t= he design _should_ start with examining threat models against attributeswhich are used in path selection, and on identifying reasonable mechanism(= s) to address
    those threats.

    Doing so would require, at a minimum, stopping forwar= d progress on -protocol docs,
    until the -reqs- and -threat- are adequate= ly addressed.

    BTW - I am in favor of this, and suggest that this pro= posal be submitted to the WG
    to establish general consensus (or not).

    Chairs?

    Respectfully= ,
    Brian Dickson

    =A0
    Discussing if there are other attributes that meet that rubric is an
    incremental discussion relative to the current proposal.

    Stepping back to the bigger question if we should be securing something
    other than what is on the wire (or can be put on the wire with new IDR
    tweaks) is a much broader discussion of our basic goals.

    dougm
    --
    Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / N= IST






    On 3/21/12 11:13 AM, "Ru= ss White" <russw@riw.us> wro= te:

    >
    >> I think we are chasing our tails around the use of path as an
    >>abstraction
    >> of the set of peering relationships and PATH as a specific sequenc= e of
    >> announcements of a given prefix (I.e., the AS_PATH attribute).
    >>
    >> Not that the debate isn't amusing, but sorting out those terms= out might
    >> allow it to move forward.
    >
    >Precisely! Which "protocol semantic" are we trying to get rig= ht?
    >
    >Are we trying to secure the bits of the protocol on the wire? If so, >then why not all the bits? Is there an argument other than, "the r= est of
    >the bits are too hard to secure?" If so, then why do we much care = about
    >"man in the middle attacks" at the database level?
    >
    >Or are we trying to secure the database --the path itself as an abstrac= t
    >object? If so, how do we deal with policy that should hang off the path= ?
    >
    >The second way allows us to break the problem into multiple pieces,
    >examine each, and make independent tradeoffs. The first --so far, I
    >don't see where it's led us anyplace useful --partly because we= keep
    >munging different pieces of the two ways of looking at the problem
    >together into one "thing" --"we're just securing the= semantics of the
    >protocol on the wire, but we really want to secure this and that piece<= br> >of database integrity by doing so."
    >
    >Russ

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

    --f46d0444ee2dbe1da204bbc2c126-- From randy@psg.com Wed Mar 21 08:53:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE97321F871B for ; Wed, 21 Mar 2012 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXM10NXz0SfD for ; Wed, 21 Mar 2012 08:53:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 56C7621F86F0 for ; Wed, 21 Mar 2012 08:53:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SANqj-000Nfr-Ml; Wed, 21 Mar 2012 15:53:21 +0000 Date: Wed, 21 Mar 2012 16:53:20 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4F69D348.4000601@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <4F69D348.4000601@riw.us> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:53:23 -0000 > I can't even begin to make sense out of this --can you explain? nope. i don't play russ white ping pong From christopher.morrow@gmail.com Wed Mar 21 09:10:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BC21F8523 for ; Wed, 21 Mar 2012 09:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoGC7RGr80Mn for ; Wed, 21 Mar 2012 09:10:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9EB21F8522 for ; Wed, 21 Mar 2012 09:10:21 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so922624obb.31 for ; Wed, 21 Mar 2012 09:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CkSvfhOt+C6PtIiDau9YSZkDzVWB/Hp5WAnuKCzwyNc=; b=hHLKdAwROsSys7mTSIpp8Q9SrWxwUeDdhEZXBTQ0SrXHqRJ4u73ST38TRoKFa9kBhk BbbiphUNd/SraKwgInWnOKQH0hlRxR/SScmzJPGlkP20M8/igOoD40PATpwvtPD8/DL0 US5jSSmDuZkVBQjn2Cq4pItpo/78c0Wus++VPwc5a5Jb1wGmLZzBIn69qlaU2Ge2weq9 699VOKpi6isju+jRlLp8k8TCLatEX9LJTevOhMTQi+TZ4bVGoAYmTgdCxoZeNdLNjmko d5CS2DuOznIK5X6BQqb1++VNXE1ndAHIOvJXm9feoAGMSpECKUYaWgfpTHmL4yERiaup pb6w== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr5280977obb.71.1332346220849; Wed, 21 Mar 2012 09:10:20 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 09:10:20 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 12:10:20 -0400 X-Google-Sender-Auth: Rd4r3ceT9L0575TUvdyBqp5qlYA Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:10:22 -0000 On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson wrote: > > > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas > wrote: >> >> By "we" I assume you are asking the bigger question about what the broad >> requirements / objectives should be. >> >> The current BGPSEC design, chooses to only focus on the protocol on the >> wire, and starts with the attributes that had both an identified threat >> and a existence proof of a reasonable mechanism to address that threat. >> > > If that statement were true, I think there would be much more support and > progress > for the bgpsec-protocol component of the SIDR WG. > > However, the current interpretation (by whom, is not clear) seems to be, > that only certain attributes (AS-path and nothing else?) are included in > what is protected. > > Any attempt to discuss inclusion of other attributes, and reasonable > mechanisms > for including those in the protection regime, has been shouted down by a > small group > which includes a self-selected group of implementers. > you seem to want to read: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 > I agree that the design _should_ start with examining threat models again= st > attributes > which are used in path selection, and on identifying reasonable mechanism= (s) > to address > those threats. > > Doing so would require, at a minimum, stopping forward progress on -proto= col > docs, > until the -reqs- and -threat- are adequately addressed. > > BTW - I am in favor of this, and suggest that this proposal be submitted = to > the WG > to establish general consensus (or not). > > Chairs? > > Respectfully, > Brian Dickson > > >> >> Discussing if there are other attributes that meet that rubric is an >> incremental discussion relative to the current proposal. >> >> Stepping back to the bigger question if we should be securing something >> other than what is on the wire (or can be put on the wire with new IDR >> tweaks) is a much broader discussion of our basic goals. >> >> dougm >> -- >> Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NI= ST >> >> >> >> >> >> >> On 3/21/12 11:13 AM, "Russ White" wrote: >> >> > >> >> I think we are chasing our tails around the use of path as an >> >>abstraction >> >> of the set of peering relationships and PATH as a specific sequence o= f >> >> announcements of a given prefix (I.e., the AS_PATH attribute). >> >> >> >> Not that the debate isn't amusing, but sorting out those terms out >> >> might >> >> allow it to move forward. >> > >> >Precisely! Which "protocol semantic" are we trying to get right? >> > >> >Are we trying to secure the bits of the protocol on the wire? If so, >> >then why not all the bits? Is there an argument other than, "the rest o= f >> >the bits are too hard to secure?" If so, then why do we much care about >> >"man in the middle attacks" at the database level? >> > >> >Or are we trying to secure the database --the path itself as an abstrac= t >> >object? If so, how do we deal with policy that should hang off the path= ? >> > >> >The second way allows us to break the problem into multiple pieces, >> >examine each, and make independent tradeoffs. The first --so far, I >> >don't see where it's led us anyplace useful --partly because we keep >> >munging different pieces of the two ways of looking at the problem >> >together into one "thing" --"we're just securing the semantics of the >> >protocol on the wire, but we really want to secure this and that piece >> >of database integrity by doing so." >> > >> >Russ >> >> _______________________________________________ >> 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 > From brian.peter.dickson@gmail.com Wed Mar 21 09:36:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4821E801A for ; Wed, 21 Mar 2012 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwpXal1WbCvh for ; Wed, 21 Mar 2012 09:36:12 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77121F8646 for ; Wed, 21 Mar 2012 09:36:11 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5427162wib.13 for ; Wed, 21 Mar 2012 09:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HhOc4szE5xynt/MQYXTuJ/2U04Iy1ow/I/Askigg2BA=; b=AU6f18U99v+59iV0OGd3mj5BGOuH7SV8CLjLe369C2nKZWtoAXOx3xrzgwmI8YRQz1 QuRw+1n56IFT9E9fEwkaLIANvUdIWEJCwIUAYbeSqyJdGBqjyj8qw/xK3bYw1uQhy2/Y dhL6qfaLRVj55x1Xa3FpRHK/glKnAxUmJd6MfkSq7Gl6jnKDz7QIzeW2ZxF1Wv7d7cfT U2/d8nsvgTgrPc4tTpot2vD/WzsspS88eZtFj8kKXgqgO+CsOIhKBik+Uw0KuzAZeJIo FkQrmo2hP/rYLxd0c9chiebPprZq1bT9P0njvlZz12KAt8XK1antU4zrT0mr88XllvPC lt3g== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr12010433wib.3.1332347771254; Wed, 21 Mar 2012 09:36:11 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 21 Mar 2012 09:36:11 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 12:36:11 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d0444ee2d9f797404bbc36310 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:36:13 -0000 --f46d0444ee2d9f797404bbc36310 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson > wrote: > > > > > > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas > > wrote: > >> > >> By "we" I assume you are asking the bigger question about what the bro= ad > >> requirements / objectives should be. > >> > >> The current BGPSEC design, chooses to only focus on the protocol on th= e > >> wire, and starts with the attributes that had both an identified threa= t > >> and a existence proof of a reasonable mechanism to address that threat= . > >> > > > > If that statement were true, I think there would be much more support a= nd > > progress > > for the bgpsec-protocol component of the SIDR WG. > > > > However, the current interpretation (by whom, is not clear) seems to be= , > > that only certain attributes (AS-path and nothing else?) are included i= n > > what is protected. > > > > Any attempt to discuss inclusion of other attributes, and reasonable > > mechanisms > > for including those in the protection regime, has been shouted down by = a > > small group > > which includes a self-selected group of implementers. > > > > you seem to want to read: > http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 > > Yes, I have read that, and the relevant bits are pretty much as follows: "It was decided..." (in a number of places). The section on "what is signed" lists a few attributes, and focuses on the "how" rather than the "what" or "why". The only place where what is not signed is discussed is in 2.4.1, where it basically says, "are local, or lack clear security needs." This is a conclusion, not supported by any analysis, and refuted (repeatedly) by a number of folks in the WG. This is the crux of the issue. The logic applied by a few folks is circular, in that the design choices and protocol design have been made without input from the WG, and in fact are ignoring significant threat model issues. The threat model discussion is excluding real threat issues, on the basis of saying that the WG charter is limited to protecting only the AS path. However, the charter does not say "AS path", and the (real) threat models definitely extend beyond AS-path forgery. And, I believe, there may have been some assertions that there is no way to protect attributes which might change in flight (legitimately), and using that as a reason not to include other attributes in the -design- doc or -threat- doc. So, I will make a counter-assertion. I will claim it is possible to protect attributes which change, and that discussion on which attributes should be signed, should be open for discussion. Brian > > I agree that the design _should_ start with examining threat models > against > > attributes > > which are used in path selection, and on identifying reasonable > mechanism(s) > > to address > > those threats. > > > > Doing so would require, at a minimum, stopping forward progress on > -protocol > > docs, > > until the -reqs- and -threat- are adequately addressed. > > > > BTW - I am in favor of this, and suggest that this proposal be submitte= d > to > > the WG > > to establish general consensus (or not). > > > > Chairs? > > > > Respectfully, > > Brian Dickson > > > > > >> > >> Discussing if there are other attributes that meet that rubric is an > >> incremental discussion relative to the current proposal. > >> > >> Stepping back to the bigger question if we should be securing somethin= g > >> other than what is on the wire (or can be put on the wire with new IDR > >> tweaks) is a much broader discussion of our basic goals. > >> > >> dougm > >> -- > >> Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / = NIST > >> > >> > >> > >> > >> > >> > >> On 3/21/12 11:13 AM, "Russ White" wrote: > >> > >> > > >> >> I think we are chasing our tails around the use of path as an > >> >>abstraction > >> >> of the set of peering relationships and PATH as a specific sequence > of > >> >> announcements of a given prefix (I.e., the AS_PATH attribute). > >> >> > >> >> Not that the debate isn't amusing, but sorting out those terms out > >> >> might > >> >> allow it to move forward. > >> > > >> >Precisely! Which "protocol semantic" are we trying to get right? > >> > > >> >Are we trying to secure the bits of the protocol on the wire? If so, > >> >then why not all the bits? Is there an argument other than, "the rest > of > >> >the bits are too hard to secure?" If so, then why do we much care abo= ut > >> >"man in the middle attacks" at the database level? > >> > > >> >Or are we trying to secure the database --the path itself as an > abstract > >> >object? If so, how do we deal with policy that should hang off the > path? > >> > > >> >The second way allows us to break the problem into multiple pieces, > >> >examine each, and make independent tradeoffs. The first --so far, I > >> >don't see where it's led us anyplace useful --partly because we keep > >> >munging different pieces of the two ways of looking at the problem > >> >together into one "thing" --"we're just securing the semantics of the > >> >protocol on the wire, but we really want to secure this and that piec= e > >> >of database integrity by doing so." > >> > > >> >Russ > >> > >> _______________________________________________ > >> 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 > > > --f46d0444ee2d9f797404bbc36310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Mar 21, 2012 at 12:10 PM, Christ= opher Morrow <morrowc.lists@gmail.com> wrote:
    On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson
    <brian.peter.dickson@gm= ail.com> wrote:
    >
    >
    > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas <dougm@nist.gov>
    > wrote:
    >>
    >> By "we" I assume you are asking the bigger question abou= t what the broad
    >> requirements / objectives should be.
    >>
    >> The current BGPSEC design, chooses to only focus on the protocol o= n the
    >> wire, and starts with the attributes that had both an identified t= hreat
    >> and a existence proof of a reasonable mechanism to address that th= reat.
    >>
    >
    > If that statement were true, I think there would be much more support = and
    > progress
    > for the bgpsec-protocol component of the SIDR WG.
    >
    > However, the current interpretation (by whom, is not clear) seems to b= e,
    > that only certain attributes (AS-path and nothing else?) are included = in
    > what is protected.
    >
    > Any attempt to discuss inclusion of other attributes, and reasonable > mechanisms
    > for including those in the protection regime, has been shouted down by= a
    > small group
    > which includes a self-selected group of implementers.
    >

    you seem to want to read:
    http://tools.ietf.org/html/draft-sriram-bgpsec-design-c= hoices-01

    <= br>Yes, I have read that, and the relevant bits are pretty much as follows:=

    "It was decided..." (in a number of places).

    The s= ection on "what is signed" lists a few attributes, and focuses on= the "how"
    rather than the "what" or "why".

    The only place = where what is not signed is discussed is in 2.4.1, where it basically
    sa= ys, "are local, or lack clear security needs."

    This is a c= onclusion, not supported by any analysis, and refuted (repeatedly) by a num= ber
    of folks in the WG.

    This is the crux of the issue. The logic applied= by a few folks is circular, in that the design
    choices and protocol des= ign have been made without input from the WG, and in fact
    are ignoring s= ignificant threat model issues.

    The threat model discussion is excluding real threat issues, on the bas= is of saying
    that the WG charter is limited to protecting only the AS pa= th.

    However, the charter does not say "AS path", and the (= real) threat models definitely
    extend beyond AS-path forgery.

    And, I believe, there may have been s= ome assertions that there is no way to protect
    attributes which might ch= ange in flight (legitimately), and using that as a reason not to
    include= other attributes in the -design- doc or -threat- doc.

    So, I will make a counter-assertion.

    I will claim it is possible= to protect attributes which change, and that discussion on which
    attrib= utes should be signed, should be open for discussion.

    Brian

    =A0
    > I agree that the design _should_ start with examining threat models ag= ainst
    > attributes
    > which are used in path selection, and on identifying reasonable mechan= ism(s)
    > to address
    > those threats.
    >
    > Doing so would require, at a minimum, stopping forward progress on -pr= otocol
    > docs,
    > until the -reqs- and -threat- are adequately addressed.
    >
    > BTW - I am in favor of this, and suggest that this proposal be submitt= ed to
    > the WG
    > to establish general consensus (or not).
    >
    > Chairs?
    >
    > Respectfully,
    > Brian Dickson
    >
    >
    >>
    >> Discussing if there are other attributes that meet that rubric is = an
    >> incremental discussion relative to the current proposal.
    >>
    >> Stepping back to the bigger question if we should be securing some= thing
    >> other than what is on the wire (or can be put on the wire with new= IDR
    >> tweaks) is a much broader discussion of our basic goals.
    >>
    >> dougm
    >> --
    >> Doug Montgomery =AD Mgr. Internet & Scalable Systems Research = / ITL / NIST
    >>
    >>
    >>
    >>
    >>
    >>
    >> On 3/21/12 11:13 AM, "Russ White" <russw@riw.us> wrote:
    >>
    >> >
    >> >> I think we are chasing our tails around the use of path a= s an
    >> >>abstraction
    >> >> of the set of peering relationships and PATH as a specifi= c sequence of
    >> >> announcements of a given prefix (I.e., the AS_PATH attrib= ute).
    >> >>
    >> >> Not that the debate isn't amusing, but sorting out th= ose terms out
    >> >> might
    >> >> allow it to move forward.
    >> >
    >> >Precisely! Which "protocol semantic" are we trying t= o get right?
    >> >
    >> >Are we trying to secure the bits of the protocol on the wire? = If so,
    >> >then why not all the bits? Is there an argument other than, &q= uot;the rest of
    >> >the bits are too hard to secure?" If so, then why do we m= uch care about
    >> >"man in the middle attacks" at the database level? >> >
    >> >Or are we trying to secure the database --the path itself as a= n abstract
    >> >object? If so, how do we deal with policy that should hang off= the path?
    >> >
    >> >The second way allows us to break the problem into multiple pi= eces,
    >> >examine each, and make independent tradeoffs. The first --so f= ar, I
    >> >don't see where it's led us anyplace useful --partly b= ecause we keep
    >> >munging different pieces of the two ways of looking at the pro= blem
    >> >together into one "thing" --"we're just sec= uring the semantics of the
    >> >protocol on the wire, but we really want to secure this and th= at piece
    >> >of database integrity by doing so."
    >> >
    >> >Russ
    >>
    >> _______________________________________________
    >> 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
    >

    --f46d0444ee2d9f797404bbc36310-- From christopher.morrow@gmail.com Wed Mar 21 09:45:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5D21E8063 for ; Wed, 21 Mar 2012 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5UUxwMUAtaT for ; Wed, 21 Mar 2012 09:45:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95F21E804D for ; Wed, 21 Mar 2012 09:45:01 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1236793ghb.31 for ; Wed, 21 Mar 2012 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+y1E5o4U3iy8l92tayogMoKpjvrzw8MTCO1G7rahLFE=; b=sYy5qoInKIimxUZyZn7L8pA2bpCFGmS6P3wGIbUe10gAZL4t7IW0KXi1NZdH0z+JxI ZVY3nTTi2U3apbZO511218fBgltAZmeE9CYfQXmFCmuhQpPqxbjVCJgLn4c6TN/iBrRy EudaI9wpLAKNCmDeCkjQsmnTrnn+QPPRSzZzdwXrOSciOtT4VM4a3yaYWpMdSXCZ3KoB k28o//VugJci86dDUx5qgLcsdipvPc7M1f2w26wVfIafXLQerDK1thpmgfttDMJnn4ug sY6FshDLw7vZ0claNNLa10/e0KD4Gn4kW3e1FKtbWBLwDJ/0fjYB1WIuJpYk26NCQBxu iPyw== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr5531698obv.41.1332348301173; Wed, 21 Mar 2012 09:45:01 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 09:45:01 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 12:45:01 -0400 X-Google-Sender-Auth: 1e5xSZ_fu-ugg1NCEpUGb3lTIQ8 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:45:03 -0000 On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson wrote: > > > On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow > wrote: >> >> On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson >> wrote: >> > >> > >> > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas >> > wrote: >> >> >> >> By "we" I assume you are asking the bigger question about what the >> >> broad >> >> requirements / objectives should be. >> >> >> >> The current BGPSEC design, chooses to only focus on the protocol on the >> >> wire, and starts with the attributes that had both an identified threat >> >> and a existence proof of a reasonable mechanism to address that threat. >> >> >> > >> > If that statement were true, I think there would be much more support >> > and >> > progress >> > for the bgpsec-protocol component of the SIDR WG. >> > >> > However, the current interpretation (by whom, is not clear) seems to be, >> > that only certain attributes (AS-path and nothing else?) are included in >> > what is protected. >> > >> > Any attempt to discuss inclusion of other attributes, and reasonable >> > mechanisms >> > for including those in the protection regime, has been shouted down by a >> > small group >> > which includes a self-selected group of implementers. >> > >> >> you seem to want to read: >> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 >> > > Yes, I have read that, and the relevant bits are pretty much as follows: > > "It was decided..." (in a number of places). > > The section on "what is signed" lists a few attributes, and focuses on the > "how" > rather than the "what" or "why". > yup, part of that could be more explanatory. > The only place where what is not signed is discussed is in 2.4.1, where it > basically > says, "are local, or lack clear security needs." > I think sriram means really that each of these items are actually modified/modifiable at each router hop (each bgp peer), and if they get signed how does that make any sense at all if on one hop you sign: community 701:666 but at the next 701:666 7018:12 and at the next ''. ?? localpref, similarly is meaningless outside the local ASN, metric as well can get fudged with at each hop (peer) so signing that is ... problematic/impossible. > This is a conclusion, not supported by any analysis, and refuted > (repeatedly) by a number > of folks in the WG. sure, got text ? > The threat model discussion is excluding real threat issues, on the basis of > saying > that the WG charter is limited to protecting only the AS path. along with: "Show the math" (or equivalent in the case of the leaks problem) > I will claim it is possible to protect attributes which change, and that > discussion on which > attributes should be signed, should be open for discussion. curious how that'd be done, got examples? -chris From brian.peter.dickson@gmail.com Wed Mar 21 10:07:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFE221F85B7 for ; Wed, 21 Mar 2012 10:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu078YZZ0lm8 for ; Wed, 21 Mar 2012 10:07:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1D2A21F84F7 for ; Wed, 21 Mar 2012 10:07:36 -0700 (PDT) Received: by werb10 with SMTP id b10so1350607wer.31 for ; Wed, 21 Mar 2012 10:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M2zaC0PvKJPI9SErzhEUftfeQhrefnVMDjQCej4xkPY=; b=jWKib3TpSM/LmBln0eo0kDr/o7dD9gvgZWRy4F0CGodRplJDC25S7O94W/ciiVy7Nj cJlqR+Zwtt5y68cQmm3T1KR/Xi3LHY2cfWp9ctX+Yfc35/otZ2ZY3BbEmB4KZSkNggYB EgdiA9rl1S/8HJzViwHWCkVJ8v1KDVyMVg3sjKqdQSNuGHdXgfbz8sQczh7rzJMeIZnU azZWQrq59eUgI4W8a4sVopirp7kT+wpZBNZDtESr+DQi/N0bks2tbfFbKBRmIbwQDmYq FwRiF7q25VSq5o1OADNPfqgzwh3dAezwEtzlwdK+cWvqINZybQ0fjbjIe40Q6+z9jQDc izIA== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr12278615wib.3.1332349655899; Wed, 21 Mar 2012 10:07:35 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 21 Mar 2012 10:07:35 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 13:07:35 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d0444ee2df4dd4004bbc3d39c Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:07:38 -0000 --f46d0444ee2df4dd4004bbc3d39c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 21, 2012 at 12:45 PM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson > > > I will claim it is possible to protect attributes which change, and that > > discussion on which > > attributes should be signed, should be open for discussion. > > curious how that'd be done, got examples? > > -chris > Gladly. While it may not be terribly efficient (but then, information theory says "duh"), here goes: It basically uses the same kind of methods that "rsync" uses for arbitrary binary data, or rcs/cvs/sccs use for source code. It requires a new attribute type to stuff the data. It would be a block of things, each which corresponds to one AS-hop. Each "hop" would have two counts, for the two elements for that hop. The two elements would be as follows. The first is things that were deleted or changed. This can be a block of attribute types and values, all the ones that were deleted or changed, in there entirety. The second is things that were added. Also in their entirety. (These would be attributes that did not exist when the update was received.) Validation would work backwards, by validating the last hop based on current values and signature. Then, working back one hop at a time, remove the things added, add or change the things deleted or changed. Validate with this new set of values. Lather, rinse, repeat. For updates where little or nothing changed, the overhead (in processing and space) is negligible. For updates where a lot changes once, the overhead is slightly more. Only where every hop involves lots of change, does stuff start to become bloated. However, given the average number of AS-hops, and the proportion of those where values change, I think this is manageable. Additionally, lots of prefix/path combos will share attributes, and likely also share attribute "stacks", so in-router storage isn't terribly bloated. Ugly, but manageable, IMHO. Brian --f46d0444ee2df4dd4004bbc3d39c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2012 at 12:45 PM, Christopher Morrow <= morrowc.lists@gmail.com><= /span> wrote:
    On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson

    > I will claim it is possible to protect attributes which change, and th= at
    > discussion on which
    > attributes should be signed, should be open for discussion.

    curious how that'd be done, got examples?

    -chris

    Gladly.

    While it may not be terribly efficien= t (but then, information theory says "duh"), here goes:

    It= basically uses the same kind of methods that "rsync" uses for ar= bitrary binary data, or rcs/cvs/sccs use for source code.

    It requires a new attribute type to stuff the data. It would be a block= of things, each which corresponds to one AS-hop.

    Each "hop&quo= t; would have two counts, for the two elements for that hop.

    The two= elements would be as follows.
    The first is things that were deleted or changed. This can be a block of at= tribute types and values, all the ones that were deleted or changed, in the= re entirety.
    The second is things that were added. Also in their entiret= y. (These would be attributes that did not exist when the update was receiv= ed.)

    Validation would work backwards, by validating the last hop based on cu= rrent values and signature.
    Then, working back one hop at a time, remove= the things added, add or change the things deleted or changed. Validate wi= th this new set of values.
    Lather, rinse, repeat.

    For updates where little or nothing changed, = the overhead (in processing and space) is negligible.
    For updates where = a lot changes once, the overhead is slightly more.
    Only where every hop = involves lots of change, does stuff start to become bloated. However, given= the average number of AS-hops, and the proportion of those where values ch= ange, I think this is manageable.

    Additionally, lots of prefix/path combos will share attributes, and lik= ely also share attribute "stacks", so in-router storage isn't= terribly bloated.

    Ugly, but manageable, IMHO.

    Brian
    --f46d0444ee2df4dd4004bbc3d39c-- From dmandelb@bbn.com Wed Mar 21 10:21:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A8021E8085 for ; Wed, 21 Mar 2012 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJB5KI18f4Dl for ; Wed, 21 Mar 2012 10:21:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2311A21E808A for ; Wed, 21 Mar 2012 10:21:55 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:45817) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAPEC-000HPN-Tu for sidr@ietf.org; Wed, 21 Mar 2012 13:21:40 -0400 Received: from dhcp89-089-068.bbn.com ([128.89.89.68]) by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SAPEO-0005D9-4k for sidr@ietf.org; Wed, 21 Mar 2012 13:21:52 -0400 Message-ID: <1332350513.17374.1.camel@titan> From: David Mandelberg To: sidr@ietf.org Date: Wed, 21 Mar 2012 13:21:53 -0400 In-Reply-To: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> References: <20120312232702.17194.34028.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:21:56 -0000 The prefix-to-AS mappings used by the BGP speaker are expected to be updated over time. When a mapping is added or deleted, the implementation MUST re-validate any affected prefixes. An "affected prefix" is any prefix that was matched by a deleted or updated mapping, or could be matched by an added mapping. Shouldn't the two instances of the word 'matched' above be 'covered' instead since covering mappings also affect validation states? -- David Mandelberg Wed Mar 21 13:20:52 EDT 2012 From Sandra.Murphy@sparta.com Wed Mar 21 10:37:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B1C21F856A for ; Wed, 21 Mar 2012 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UezxD0MrYlj2 for ; Wed, 21 Mar 2012 10:37:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4B21F8569 for ; Wed, 21 Mar 2012 10:37:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2LHbnDL013880 for ; Wed, 21 Mar 2012 12:37:49 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2LHbnAP027403 for ; Wed, 21 Mar 2012 12:37:49 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 13:37:49 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] SIDR Interim 24/March is CANCELLED Thread-Index: Ac0Hhr4RJ7KoxaClTIK9avdQzQvOSw== Date: Wed, 21 Mar 2012 17:37:47 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:37:51 -0000 In the flurry of apologetic emails that preceeded and followed this announc= ement, I did not apolgize to the working group. This was my strictly my bungle, in two different directions. First, I announced the meeting to the sidr mailing list within the time fra= me required by process. The bungle was that I did not copy the iesg-secret= ary as I MEANT to do and I KNEW is required by process. I noticed this mys= elf the next week, but too late to meet the required deadline. I informed = the iesg-secretary. They sent the announcement and complaints of process v= iolation came in immediately. Second, I announced the agenda as is required by process one week ahead of = time, by my local time zone. However, due to the time of day and time zone= differences, it was reckoned the next day in other time zones. --Sandy, the apologetic wg co-chair= From heas@shrubbery.net Wed Mar 21 10:38:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536B21E801A; Wed, 21 Mar 2012 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm3DwxCg1rLm; Wed, 21 Mar 2012 10:38:36 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFE21F8569; Wed, 21 Mar 2012 10:38:24 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id A4BDC88B70; Wed, 21 Mar 2012 17:38:23 +0000 (UTC) Date: Wed, 21 Mar 2012 17:38:23 +0000 From: heasley To: "Bert Wijnen (IETF)" Message-ID: <20120321173823.GB75903@shrubbery.net> References: <0E2C44659B4E4C22A58EDF7E0A834092@BertLaptop> <4F5FB239.7090009@bwijnen.net> <4F68A20F.5000506@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F68A20F.5000506@bwijnen.net> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeffrey Haas , idr@IETF.ORG, sidr wg list Subject: Re: [sidr] BGP4 MIB module X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:38:37 -0000 Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF): > So I had been in discussion with Jeff in order to see > if we could get the BGP4-mibv2 module in good shape. > > Below is out discussion. > > Those who are interested in this MIB module at all > may want to take a look to make sure they agree with > the changes being proposed. > > The most modules we're discussion are: > > - drafts/draft-ietf-idr-bgp4-mibv2-13.txt > - drafts/draft-ietf-idr-bgp4-mibv2-tc-mib-03.txt > > In fact I had below discussion on bgp4-mibv2-12.txt, > which resulted in revision 13. I'm disappointed in the speed at which this draft has progressed. I do understand that mibs are often partially gated for/by trial implementation (or so I've been told), but I have the impression its pace is wholly due to the complexity of the proposed mib. I also feel that there is a fair amount of fluff that we find unnecessary for network management and would be better suited to a separate mib; the RIBs, for example. bgp4-mibv2 ("lite"), bgp4-ribs, etc; or some approach that would allow the necessities of peer state, nlri counts, and the like to progress without the fluff and thus be more timely. As such, I am unsure why its been brought to the sidr list, but I am hoping that no attempt will be made to add SIDR-related stuff to this mib and further delay adoption. From kent@bbn.com Wed Mar 21 10:41:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6443821E8055 for ; Wed, 21 Mar 2012 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upYX0ocdw1re for ; Wed, 21 Mar 2012 10:41:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D0C9121E8026 for ; Wed, 21 Mar 2012 10:41:58 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49160) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAPXe-000Hua-Mp; Wed, 21 Mar 2012 13:41:46 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 13:40:16 -0400 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879770780==_ma============" Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:41:59 -0000 --============_-879770780==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:50 AM -0400 3/21/12, Brian Dickson wrote: >On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas ><dougm@nist.gov> wrote: > >By "we" I assume you are asking the bigger question about what the broad >requirements / objectives should be. > >The current BGPSEC design, chooses to only focus on the protocol on the >wire, and starts with the attributes that had both an identified threat >and a existence proof of a reasonable mechanism to address that threat. > > >If that statement were true, I think there would be much more >support and progress >for the bgpsec-protocol component of the SIDR WG. > >However, the current interpretation (by whom, is not clear) seems to be, >that only certain attributes (AS-path and nothing else?) are >included in what is protected. The WG charter states which BGP vulnerabilities are to be addressed. The choice of which attributes need to be protected is, I believe, consistent with the charter. Steve --============_-879770780==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] route leaks message to IDR
    At 11:50 AM -0400 3/21/12, Brian Dickson wrote:
    On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas <dougm@nist.gov> wrote:
    By "we" I assume you are asking the bigger question about what the broad
    requirements / objectives should be.

    The current BGPSEC design, chooses to only focus on the protocol on the
    wire, and starts with the attributes that had both an identified threat
    and a existence proof of a reasonable mechanism to address that threat.

    If that statement were true, I think there would be much more support and progress
    for the bgpsec-protocol component of the SIDR WG.

    However, the current interpretation (by whom, is not clear) seems to be,
    that only certain attributes (AS-path and nothing else?) are included in what is protected.

    The WG charter states which BGP vulnerabilities are to be addressed. The choice of which attributes need to be protected is, I believe, consistent with the charter.

    Steve
    --============_-879770780==_ma============-- From brian.peter.dickson@gmail.com Wed Mar 21 10:56:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5332921E808C for ; Wed, 21 Mar 2012 10:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjgOTKdp0vp7 for ; Wed, 21 Mar 2012 10:56:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1136021E808B for ; Wed, 21 Mar 2012 10:56:11 -0700 (PDT) Received: by werb10 with SMTP id b10so1393109wer.31 for ; Wed, 21 Mar 2012 10:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=je5S0dLg679oLlGdhgnoezjZeRlMNRLosjxFp+kkMLM=; b=m2ieUYtt5U9zimk4zp9FXmvqK/nHMwvJr0KolX8Idi3KKcxeczm4dtii0NMtg2kFHz eBpoYMVmkm0y71OOJsFrXQTp7y0gn9gSlFHEBr3dS6zTyIb+q0erzxj6KAuRePlfr8mV wUfwgmwNYaI4c21Be9wbyRj+y4CrO+q4BvSD9gJGri9bkZGz6/tNx4rbrqy5Ku8cVr5l X797DER/rnUWArSfgsUJz0eoUIIz41mNAAeyFHVEi6lXObMm6r8LQ/vpZrqYboh+gz6E UdEPNbZI573C2lIqlaAk4hOnDUio5bSqD/tGKEMUJz7EFveQb1UtpjlAnq/R5+E/gli8 Ml8w== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr12688524wib.3.1332352571181; Wed, 21 Mar 2012 10:56:11 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 21 Mar 2012 10:56:10 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 13:56:10 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: multipart/alternative; boundary=f46d0444ee2db88c7804bbc48162 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:56:13 -0000 --f46d0444ee2db88c7804bbc48162 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent wrote: > ** > At 11:50 AM -0400 3/21/12, Brian Dickson wrote: > > On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas > wrote: > > By "we" I assume you are asking the bigger question about what the broad > requirements / objectives should be. > > The current BGPSEC design, chooses to only focus on the protocol on the > wire, and starts with the attributes that had both an identified threat > and a existence proof of a reasonable mechanism to address that threat. > > > If that statement were true, I think there would be much more support and > progress > for the bgpsec-protocol component of the SIDR WG. > > However, the current interpretation (by whom, is not clear) seems to be, > > that only certain attributes (AS-path and nothing else?) are included in > what is protected. > > > The WG charter states which BGP vulnerabilities are to be addressed. The > choice of which attributes need to be protected is, I believe, consistent > with the charter. > > > I disagree (vehemently, I might add.) Here's the charter: *The purpose of the SIDR working group is to reduce vulnerabilities in * * the inter-domain routing system.* The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled *The SIDR working group will take practical deployability into consideration. * Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture *This working group will specify security enhancements for inter-domain * * routing protocols. * I have added emphasis (bold) to illustrate that the charter does not _exhaustively_ state which vulnerabilities are to be addressed. It does mandate two specific required vulnerabilities, but does not exclude anything. In fact, and I believe I am far from alone in this regard, the bold items in the charter give license to address other vulnerabilities. I would also opine, that _not_ addressing other, identifiable and identified vulnerabilities, would be seen by the rest of the IETF and by the "users" of BGP (operators of the >>30k ASNs) as a massive #FAIL. This can be reduced to english semantics: "The two vulnerabilities", is semantically distinct from "The _only_ two vulnerabilities". You (SK) seem to be arguing that the latter is the case. The charter says the former. If someone (e.g. the AD) is exercising some authority over the WG to restrict us to the latter, I believe the appropriate way to resolve this is to re-charter to remove all ambiguity in the matter, one way or the other. That is, unless it is merely a matter of interpreting the words of the charter incorrectly, in which case, let's just get on with updating the threat model and finding solutions. Brian --f46d0444ee2db88c7804bbc48162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Wed, Mar 21, 2012 at 1:40 PM, Stephen= Kent <kent@bbn.com> wrote:
    At 11:50 AM -0400 3/21/12, Brian Dickson wrote:
    On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas <dougm@nist.gov> wrote:
    By "we" I assume you are asking the bigger question about what the broad
    requirements / objectives should be.

    The current BGPSEC design, chooses to only focus on the protocol on the
    wire, and starts with the attributes that had both an identified threat
    and a existence proof of a reasonable mechanism to address that threat.

    If that statement were true, I think there would be much more support and progress
    for the bgpsec-protocol component of the SIDR WG.

    However, the current interpretation (by whom, is not clear) seems to be,
    that only certain attributes (AS-path and nothing else?) are included in what is protected.

    The WG charter states which BGP vulnerabilities are to be addressed. The choice of which attributes need to be protected is, I believe, consistent with the charter.



    I disagree (vehemently, I mi= ght add.)

    Here's the charter:

    The purpose of the SIDR working group is to reduce vulnerabilities = in
    the inter-domain routing system. The two vulnerabilities that will be
    addressed are:

    * Is an Autonomous System (AS) authorized to originate an IP prefix
    * Is the AS-Path represented in the route the same as the path through
    which the NLRI traveled

    The SIDR working group will take practical deployability into co= nsideration.

    Building upon the already completed and implemented framework:

    * Resource Public Key Infrastructure (RPKI)
    * Distribution of RPKI data to routing devices and its use in
    operational networks
    * Document the use of certification objects within the secure
    routing architecture

    This working group will specify security enhancements for inter-= domain
    routing protocols.

    I have added emphasis (bold) to illustrate that the charter= does not _exhaustively_ state which vulnerabilities are to be addressed.
    It does mandate two specific required vulnerabilities, but does not e= xclude anything.

    In fact, and I believe I am far from alone in this regard, the bold ite= ms in the charter give license to address other vulnerabilities.

    I w= ould also opine, that _not_ addressing other, identifiable and identified v= ulnerabilities, would be seen by the rest of the IETF and by the "user= s" of BGP (operators of the >>30k ASNs) as a massive #FAIL.

    This can be reduced to english semantics:
    "The two vulnerabilit= ies", is semantically distinct from "The _only_ two vulnerabiliti= es".

    You (SK) seem to be arguing that the latter is the case. T= he charter says the former.

    If someone (e.g. the AD) is exercising some authority over the WG to re= strict us to the latter, I believe the appropriate way to resolve this is t= o re-charter to remove all ambiguity in the matter, one way or the other.
    That is, unless it is merely a matter of interpreting the words of the = charter incorrectly, in which case, let's just get on with updating the= threat model and finding solutions.

    Brian
    --f46d0444ee2db88c7804bbc48162-- From eosterweil@verisign.com Wed Mar 21 11:09:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18CF21E8085 for ; Wed, 21 Mar 2012 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QonZga1WrEf5 for ; Wed, 21 Mar 2012 11:08:59 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id E242821E8063 for ; Wed, 21 Mar 2012 11:08:52 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKT2oZMRVtT9SpuGzr9ZlhnILd8IpRLDRu@postini.com; Wed, 21 Mar 2012 11:08:52 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2LI8hjM023072; Wed, 21 Mar 2012 14:08:47 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 14:08:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 14:08:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <275CDE7F-D5FA-4C7C-ABBD-00CC73D62832@verisign.com> References: <4F69F033.7040207@riw.us> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 18:08:43.0364 (UTC) FILETIME=[A6C9D240:01CD078D] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:09:00 -0000 On Mar 21, 2012, at 12:45 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson > wrote: >>=20 >>=20 >> On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow >> wrote: >>>=20 >>> On Wed, Mar 21, 2012 at 11:50 AM, Brian Dickson >>> wrote: >>>>=20 >>>>=20 >>>> On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas = >>>> wrote: >>>>>=20 >>>>> By "we" I assume you are asking the bigger question about what the >>>>> broad >>>>> requirements / objectives should be. >>>>>=20 >>>>> The current BGPSEC design, chooses to only focus on the protocol = on the >>>>> wire, and starts with the attributes that had both an identified = threat >>>>> and a existence proof of a reasonable mechanism to address that = threat. >>>>>=20 >>>>=20 >>>> If that statement were true, I think there would be much more = support >>>> and >>>> progress >>>> for the bgpsec-protocol component of the SIDR WG. >>>>=20 >>>> However, the current interpretation (by whom, is not clear) seems = to be, >>>> that only certain attributes (AS-path and nothing else?) are = included in >>>> what is protected. >>>>=20 >>>> Any attempt to discuss inclusion of other attributes, and = reasonable >>>> mechanisms >>>> for including those in the protection regime, has been shouted down = by a >>>> small group >>>> which includes a self-selected group of implementers. >>>>=20 >>>=20 >>> you seem to want to read: >>> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 >>>=20 Actually, with respect, I think the first stop really ought to be coming = to consensus on a requirements document. My experience has been that = doing design work without solid requirements can lead to a great deal of = rework. Eric From kent@bbn.com Wed Mar 21 11:10:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5723721F8483 for ; Wed, 21 Mar 2012 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72I4NjCIlf0P for ; Wed, 21 Mar 2012 11:10:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7921F844A for ; Wed, 21 Mar 2012 11:10:43 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49161) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAPzT-000In9-C1; Wed, 21 Mar 2012 14:10:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> Date: Wed, 21 Mar 2012 14:06:58 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:10:44 -0000 At 10:48 PM -0400 3/20/12, Eric Osterweil wrote: >On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote: >... > >For one: pedantic compilers are often helpful when it comes to >static analysis. By extension, _sometimes_ one can make the same >argument (about static analysis) to justify being pedantic for >technical discussions... I'm kinda surprised that you didn't know >that... ;) I am not familiar with the term in the compiler context, only in the context of people, i.e., are being referred to as teachers, i.e., to be a pedagogue. >... > >Indeed, I was attempting to paraphrase. To clarify, this was how I >interpreted your words, but our audit trail should clearly indicate >that you did _not_ say these things and that I was merely >paraphrasing the message I interpreted from you. Please accept my >apologies for any misunderstanding about this. OK. > > Let me try another, more concise phrasing. When one adds secruity >to a protocol, the goal is to enable it to operate in a hostile >environment with the same semantics that it offered in a >non-hostile environment. Of course a secure version of a protocol >will exhibit some differences in its operation from an insecure >version, especially when one compares the two version in attacks >scenarios. > >Exactly! This is exactly what a semantic difference is! :) I think I see how we disagree. Historically (here comes those annoying 30+ years of experience again) designers of most protocols have not considered how assumed a benign (or at least non-adversarial) environment for protocol operation. In the today's world that is not a good assumption. So, when we add security mechanisms to a protocol to try to allow it to operate successfully in a hostile environment, one ought to expect the behavior to differ in attacks scenarios. I assert that this does not change the semantics, because protocol behavior outside of the benign environment was out of scope for the non-secure protocol design. > >> If that were not the case, we would not bother adding security to >>a protocol. > >Very debatable. I wouldn't necessarily impugn the addition of >security semantics to a protocol (sometimes additional >expressiveness is needed). impugn? I am not assailing the addition of secruity semantics. I am asserting that the semantics associated with the additional of security mechanisms does not constitute a violation of the semantics associated with the original, non-secure version of a protocol. > >> The relevant question is whether the fundamental nature of the >>protocol is altered by the addition of security. > >That may be a question you care about... It might even be one that >the rest of us care about, but that is different than claiming you >have not added semantics (which is where this started). This >comment is changing the subject. OK, where we started, to be brutally honest, was an attempt by you and Brian to find a way for Brian's proposal on route leaks to be considered in scope for SIDR. The SIDR charter is clear about the scope, and route leaks are not part of what we are currently chartered to do. So we really ought not be having this discussion. I'll do my part to help, by not replying to further messages on this topic. > > And, yes, maybe it is just you. > >Or maybe a line of thought (``thinking'' as you put it) that has >gone unchanged in over 30 years is overdue for having its >assumptions challenged. Security (in particular) is a field in >which the landscape changes, and stale vision can lead to myopia... >Many things in the Internet security theater have obviously changed >in 30 years, so the age of lessons does not necessarily correlate >with their relevance. :) Your comment suggests that no wisdom has accrued, at least to me, with 30 years of experience. I beg to differ. When someone proposes an approach that has been proposed and rejected previously, I usually ask myself "why did we reject this before, and what has changed that might make the decision be different this time?" Usually the answer is that the reasons for rejecting an approach are still valid, but the proposer of the "new" approach was unaware of the history. On some occasions the answer is yes, we ought to revisit the decision (which may of may not still be correct). I am fortunate to have had firsthand experiences over the last 3 decades that allow me to have this perspective. Steve From kent@bbn.com Wed Mar 21 12:02:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC9121E80A8 for ; Wed, 21 Mar 2012 12:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P43Sb5Bvnaj for ; Wed, 21 Mar 2012 12:02:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B06B321F8584 for ; Wed, 21 Mar 2012 12:02:13 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49166) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAQnJ-000KKw-Ja; Wed, 21 Mar 2012 15:02:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4F69F033.7040207@riw.us> Date: Wed, 21 Mar 2012 15:01:23 -0400 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879765964==_ma============" Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:02:20 -0000 --============_-879765964==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:56 PM -0400 3/21/12, Brian Dickson wrote: >On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent ><kent@bbn.com> wrote: >... > >I have added emphasis (bold) to illustrate that the charter does not >_exhaustively_ state which vulnerabilities are to be addressed. you have added emphasis to the text trying to show why your topic is not excluded. The generic phrase that applies here is "taking text out of context." >It does mandate two specific required vulnerabilities, but does not >exclude anything. The text says "The two vulnerabilities that will be addressed are: ..." In normal English use, "the" implies that only the listed items are in scope. If one wanted to suggest otherwise, one could say, for example, "Vulnerabilities that will be addressed include:" or "Vulnerabilities that will be addressed include but are not limited to:" >In fact, and I believe I am far from alone in this regard, the bold >items in the charter give license to address other vulnerabilities. we are far apart. >I would also opine, that _not_ addressing other, identifiable and >identified vulnerabilities, would be seen by the rest of the IETF >and by the "users" of BGP (operators of the >>30k ASNs) as a massive >#FAIL. Every WG operates based on inputs from its members, not on inputs from every user of the Internet, every vendors, every network operator, etc. When a WG reaches rough consensus that reflects the views of its members, the work product is published to the IETF list as a whole, offering an opportunity for broader comment. Even that does not ensure that every affected entity has been consulted. yet, we persist ... >This can be reduced to english semantics: >"The two vulnerabilities", is semantically distinct from "The _only_ >two vulnerabilities". > >You (SK) seem to be arguing that the latter is the case. The charter >says the former. We disagree on how one should read the charter. You should ask the WGs chairs. If you don't like the answer they provide, then you can ask the cognizant AD, then the IESG, then the IAB. >If someone (e.g. the AD) is exercising some authority over the WG to >restrict us to the latter, I believe the appropriate way to resolve >this is to re-charter to remove all ambiguity in the matter, one way >or the other. nice try, but no cigar. the right response is that first we finish the work we are chartered to do, THEN we can apply to re-charter. That's how WGs proceed. >That is, unless it is merely a matter of interpreting the words of >the charter incorrectly, in which case, let's just get on with >updating the threat model and finding solutions. The threat model was updated to reflect SIDR list comments on 2/3, 6 weeks ago, and it garnered no responses. A new version was posted on 2/22, mostly to replace cites of I-Ds with cites to RFCs. It also garnered no comments. Steve --============_-879765964==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] route leaks message to IDR
    At 1:56 PM -0400 3/21/12, Brian Dickson wrote:
    On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent <kent@bbn.com> wrote:
    ...

    I have added emphasis (bold) to illustrate that the charter does not _exhaustively_ state which vulnerabilities are to be addressed.

    you have added emphasis to the text trying to show why your topic is not excluded.  The generic phrase that applies here is "taking text out of context."

    It does mandate two specific required vulnerabilities, but does not exclude anything.

    The text says "The two vulnerabilities that will be  addressed are: ..." In normal English use, "the" implies that only the listed items are in scope. If one wanted to suggest otherwise, one could say, for example, "Vulnerabilities that will be  addressed include:" or "Vulnerabilities that will be  addressed include but are not limited to:"

    In fact, and I believe I am far from alone in this regard, the bold items in the charter give license to address other vulnerabilities.

    we are far apart.

    I  would also opine, that _not_ addressing other, identifiable and identified vulnerabilities, would be seen by the rest of the IETF and by the "users" of BGP (operators of the >>30k ASNs) as a massive #FAIL.

    Every WG operates based on inputs from its members, not on inputs from every user of the Internet, every vendors, every network operator, etc. When a WG reaches rough consensus that reflects the views of its members, the work product is published to the IETF list as a whole, offering an opportunity for broader comment. Even that does not ensure that every affected entity has been consulted. yet, we persist ...

    This can be reduced to english semantics:
    "The two vulnerabilities", is semantically distinct from "The _only_ two vulnerabilities".
    You (SK) seem to be arguing that the latter is the case. The charter says the former.

    We disagree on how one should read the charter. You should ask the WGs chairs.  If you don't like the answer they provide, then you can ask the cognizant AD, then the IESG, then the IAB.

    If someone (e.g. the AD) is exercising some authority over the WG to restrict us to the latter, I believe the appropriate way to resolve this is to re-charter to remove all ambiguity in the matter, one way or the other.

    nice try, but no cigar. the right response is that first we finish the work we are chartered to do, THEN we can apply to re-charter. That's how WGs proceed.

    That is, unless it is merely a matter of interpreting the words of the charter incorrectly, in which case, let's just get on with updating the threat model and finding solutions.

    The threat model was updated to reflect SIDR list comments on 2/3, 6 weeks ago, and it garnered no responses. A new version was posted on 2/22, mostly to replace cites of I-Ds with cites to RFCs. It also garnered no comments.

    Steve
    --============_-879765964==_ma============-- From eosterweil@verisign.com Wed Mar 21 12:19:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7145D21F8589 for ; Wed, 21 Mar 2012 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QbI-SG2iTXt for ; Wed, 21 Mar 2012 12:19:45 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3648B21F8587 for ; Wed, 21 Mar 2012 12:19:45 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKT2opznNZhx8TU3ZhcuL9yKsANBwD9p+b@postini.com; Wed, 21 Mar 2012 12:19:45 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2LJJb4c001967; Wed, 21 Mar 2012 15:19:41 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 15:19:37 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 15:19:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 19:19:37.0204 (UTC) FILETIME=[8E464B40:01CD0797] Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:19:46 -0000 While I am enjoying our rendition of Mr. Toad's Wild Ride (i.e. the = meanderings of this thread, = http://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride#Disneyland_version = ), I suspect others on the list may be growing tired of it. I will try = to prune my blow-by-blow to just what seems important: On Mar 21, 2012, at 2:06 PM, Stephen Kent wrote: > At 10:48 PM -0400 3/20/12, Eric Osterweil wrote: >> On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote: >> ... >>=20 >> > Let me try another, more concise phrasing. When one adds secruity = to a protocol, the goal is to enable it to operate in a hostile = environment with the same semantics that it offered in a non-hostile = environment. Of course a secure version of a protocol will exhibit some = differences in its operation from an insecure version, especially when = one compares the two version in attacks scenarios. >>=20 >> Exactly! This is exactly what a semantic difference is! :) >=20 > I think I see how we disagree. Historically (here comes those annoying = 30+ years of experience again) designers of most protocols have not = considered how assumed a benign (or at least non-adversarial) = environment for protocol operation. In the today's world that is not a = good assumption. So, when we add security mechanisms to a protocol to = try to allow it to operate successfully in a hostile environment, one = ought to expect the behavior to differ in attacks scenarios. I assert = that this does not change the semantics, because protocol behavior = outside of the benign environment was out of scope for the non-secure = protocol design. How about we turn this around with a simple question: Suppose two different feasible paths are being evaluated for a single = prefix/origin pair and one was delivered via a signed bgpsec update, and = the other was delivered via an unsigned update. What = annotations/influencers/considerations/etc. does the bgpsec design = suggest when the router is making its path selection between these two? >=20 >>=20 >>> The relevant question is whether the fundamental nature of the = protocol is altered by the addition of security. >>=20 >> That may be a question you care about... It might even be one that = the rest of us care about, but that is different than claiming you have = not added semantics (which is where this started). This comment is = changing the subject. >=20 > OK, where we started, to be brutally honest, was an attempt by you and = Brian to find a way for Brian's proposal on route leaks to be considered = in scope for SIDR. The SIDR charter is clear about the scope, and route = leaks are not part of what we are currently chartered to do. So we = really ought not be having this discussion. I'll do my part to help, by = not replying to further messages on this topic. *sigh* This again? You have to be kidding me... =20 1) I have no involvement w/ Brian's route leak work. =20 2) Honestly, if I _were_ involved in Brian's work, I would be happy to = announce it, and I would have asked to be listed as a coauthor. I = really don't think there would be any value in pretending _not_ to be = involved, as I have always felt that my ideas stand on their own merit. = I don't hide my involvement in ideas. :) Why not keep the discussion on topic for a while? >=20 >> > And, yes, maybe it is just you. >>=20 >> Or maybe a line of thought (``thinking'' as you put it) that has gone = unchanged in over 30 years is overdue for having its assumptions = challenged. Security (in particular) is a field in which the landscape = changes, and stale vision can lead to myopia... Many things in the = Internet security theater have obviously changed in 30 years, so the age = of lessons does not necessarily correlate with their relevance. :) >=20 > Your comment suggests that no wisdom has accrued, at least to me, with = 30 years of experience. I beg to differ. When someone proposes an = approach that has been proposed and rejected previously, I usually ask = myself "why did we reject this before, and what has changed that might = make the decision be different this time?" Usually the answer is that = the reasons for rejecting an approach are still valid, but the proposer = of the "new" approach was unaware of the history. On some occasions the = answer is yes, we ought to revisit the decision (which may of may not = still be correct). I am fortunate to have had firsthand experiences over = the last 3 decades that allow me to have this perspective. ``Wisdom ceases to be wisdom when it becomes too proud to weep, too = grave to laugh, and too selfish to seek other than itself.'' -- Kahlil = Gibran I (for one) certainly respect experience, but I don't think it should = earn a blank check. If the approach is so sound, it should stand on its = own technical merit without needing to be vetted by the pedigree of its = designer, right? ;) Eric= From russw@riw.us Wed Mar 21 12:34:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1237221E80D9 for ; Wed, 21 Mar 2012 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2LYUKpD8odo for ; Wed, 21 Mar 2012 12:34:04 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB421E80A9 for ; Wed, 21 Mar 2012 12:34:04 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:62156 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SARIE-0000p9-0G; Wed, 21 Mar 2012 15:33:58 -0400 Message-ID: <4F6A2D20.9060702@riw.us> Date: Wed, 21 Mar 2012 15:33:52 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:34:05 -0000 > The current BGPSEC design, chooses to only focus on the protocol on the > wire, and starts with the attributes that had both an identified threat > and a existence proof of a reasonable mechanism to address that threat. BGPSEC: 1. Fails to actually protect the bits on the wire in a way that meets BGP's actual on the wire protocol semantics (see the addition of timers to prevent replay attacks). 2. Attempts to add policy to the mix (see the so-called "man in the middle attack") without actually calling it policy. Given these failures, maybe it's time to start with requirements (rather than a solution) first, and see if we come to a better outcome. Russ From eosterweil@verisign.com Wed Mar 21 12:40:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9489E21E80E6 for ; Wed, 21 Mar 2012 12:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L7Syat4hSGm for ; Wed, 21 Mar 2012 12:40:22 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id AF23921E80D7 for ; Wed, 21 Mar 2012 12:40:21 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT2ounAf4EEtUyBnOh3hPnrG8DFjCgjEi@postini.com; Wed, 21 Mar 2012 12:40:21 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2LJeBgg025836; Wed, 21 Mar 2012 15:40:11 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 15:40:11 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <4F6A2D20.9060702@riw.us> Date: Wed, 21 Mar 2012 15:40:11 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9F4C1E8A-3304-44B0-87BB-8AFB9C829DC5@verisign.com> References: <4F6A2D20.9060702@riw.us> To: Russ White X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 19:40:11.0587 (UTC) FILETIME=[6E063130:01CD079A] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:40:22 -0000 On Mar 21, 2012, at 3:33 PM, Russ White wrote: > >> The current BGPSEC design, chooses to only focus on the protocol on the >> wire, and starts with the attributes that had both an identified threat >> and a existence proof of a reasonable mechanism to address that threat. > > BGPSEC: > > 1. Fails to actually protect the bits on the wire in a way that meets > BGP's actual on the wire protocol semantics (see the addition of timers > to prevent replay attacks). > 2. Attempts to add policy to the mix (see the so-called "man in the > middle attack") without actually calling it policy. > > Given these failures, maybe it's time to start with requirements (rather > than a solution) first, and see if we come to a better outcome. +1 Eric From eosterweil@verisign.com Wed Mar 21 12:40:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB6C21E80EA for ; Wed, 21 Mar 2012 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GFqEkXFL7za for ; Wed, 21 Mar 2012 12:40:25 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3233721E80E8 for ; Wed, 21 Mar 2012 12:40:25 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKT2oupUVZalwL6hwVsICPBVvnde8TB0si@postini.com; Wed, 21 Mar 2012 12:40:25 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2LJeLGC025840; Wed, 21 Mar 2012 15:40:21 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 15:40:20 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 15:40:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> References: <4F69F033.7040207@riw.us> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 19:40:20.0696 (UTC) FILETIME=[73741D80:01CD079A] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:40:26 -0000 Sorry to interject, but... On Mar 21, 2012, at 3:01 PM, Stephen Kent wrote: >=20 >> I would also opine, that _not_ addressing other, identifiable and = identified vulnerabilities, would be seen by the rest of the IETF and by = the "users" of BGP (operators of the >>30k ASNs) as a massive #FAIL. >=20 > Every WG operates based on inputs from its members, not on inputs from = every user of the Internet, every vendors, every network operator, etc. = When a WG reaches rough consensus that reflects the views of its = members, the work product is published to the IETF list as a whole, = offering an opportunity for broader comment. Even that does not ensure = that every affected entity has been consulted. yet, we persist ... My input is that the current work that does not address the real route = leak threat, and it is therefore insufficient. Since you said that you = want your work to reflect views that include mine, I'm just making my = views clear... again. Also, I think it would behoove us to strive = towards producing work that will be accepted by operators (as I think I = see Brian saying). I think it's less about consulting everyone in the = world and more about being realistic. For our work to be relevant, it = has be operationally feasible... >=20 >> That is, unless it is merely a matter of interpreting the words of = the charter incorrectly, in which case, let's just get on with updating = the threat model and finding solutions. >=20 > The threat model was updated to reflect SIDR list comments on 2/3, 6 = weeks ago, and it garnered no responses. A new version was posted on = 2/22, mostly to replace cites of I-Ds with cites to RFCs. It also = garnered no comments. Indeed, I'm printing it now... Eric= From russw@riw.us Wed Mar 21 12:51:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9121E80DA for ; Wed, 21 Mar 2012 12:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRxWPGTovh74 for ; Wed, 21 Mar 2012 12:51:25 -0700 (PDT) Received: from ecbiz115.inmotionhosting.com (ecbiz115.inmotionhosting.com [70.39.146.241]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA521E8083 for ; Wed, 21 Mar 2012 12:51:25 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32]:62396 helo=[192.168.100.63]) by ecbiz115.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1SARZ3-0001uA-3c; Wed, 21 Mar 2012 15:51:21 -0400 Message-ID: <4F6A3138.2050703@riw.us> Date: Wed, 21 Mar 2012 15:51:20 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> <4F69EB29.5000507@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz115.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:51:26 -0000 > nope, it's bits that you can choose to use or not. In other words, you've added another set of "wiggle words" to your definition. "It's not policy because it's not signing something saying you shouldn't do x, and because anyone can ignore the signature anyway." Sorry, I don't buy it. You are adding bits that allow (even demand) a receiver to discern the intent of the transmitter about the usability of a specific path. I don't care how many wiggle words you put around it --it's still policy. Now if you're going to dive into policy, then dive into policy. There's nothing wrong with diving into policy, so long as you actually address the issue. That means determining which policies should be protected, and what the tradeoffs are for protecting each one. > I'm really not trying to sneak anything. we seem to be at an impasse. I've seen more than a small number of presentations on BGPSEC. I've read more than a small number of drafts. I've had more than a small number of private conversations about BGPSEC/S-BGP. In _every_ conversation I've ever had, in _every_ presentation I've ever seen, the one singular reason given for signing the BGP update is this: So a remote AS can determine whether or not some previous AS _intended_ to allow reachability through a particular peer for a particular prefix. Perhaps the way to resolve the impasse is to accept that what you are trying to do goes beyond simple "bits on the wire" security, bring the policy problems out into the open, and have a discussion about them. Or to come to the realization that you simply can't secure any routing protocol by simply "signing the bits on the wire," because many of the semantics everyone is so concerned about are actually not in the "bits on the wire" to be signed in the first place. Russ From robert@raszuk.net Wed Mar 21 12:56:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F321E80CF for ; Wed, 21 Mar 2012 12:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53n9nOlP+Rbd for ; Wed, 21 Mar 2012 12:56:22 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4510A21E80C8 for ; Wed, 21 Mar 2012 12:56:22 -0700 (PDT) Received: (qmail 11301 invoked by uid 399); 21 Mar 2012 19:56:21 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.67) by mail1310.opentransfer.com with ESMTPM; 21 Mar 2012 19:56:21 -0000 X-Originating-IP: 83.9.123.67 Message-ID: <4F6A3268.1060800@raszuk.net> Date: Wed, 21 Mar 2012 20:56:24 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "sidr@ietf.org" References: <4F69F033.7040207@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:56:23 -0000 > On 2012-03-21 16:50, Brian Dickson wrote: > ... > Doing so would require, at a minimum, stopping forward progress on > -protocol docs, until the -reqs- and -threat- are adequately addressed. On 2012-03-21 20:33, Russ White wrote: > ... > Given these failures, maybe it's time to start with requirements > (rather than a solution) first, and see if we come to a better > outcome. On 2012-03-21 20:40, Eric Osterweil wrote: > > +1 Having a reasonable requirements document which defines what is that should be protected seem like a very reasonable thing. Clearly for some who "make/made decisions on the protocol" this may be a bit uncomfortable as their design choices now would need to compete with design proposals from others. The requirement should explicitly list elements to provide ability for gradual deployment .. maybe co-existence for some time. Clearly ideas of removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not really helping gradual deployment. Decent requirement document should also specifically prohibit use of any tools which can be controlled by politicians/courts to decide who stays in the internet and who becomes uncomfortable and needs to be cut out. So: +1 Rgs, R. From shane@castlepoint.net Wed Mar 21 13:51:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0E421F85BD for ; Wed, 21 Mar 2012 13:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItZKLu3dPETK for ; Wed, 21 Mar 2012 13:51:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id C6DE221F85B6 for ; Wed, 21 Mar 2012 13:51:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 4C90E268063; Wed, 21 Mar 2012 14:51:27 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 21 Mar 2012 14:51:27 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=59857; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Shane Amante In-Reply-To: <4F6A3268.1060800@raszuk.net> Date: Wed, 21 Mar 2012 14:51:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F69F033.7040207@riw.us> <4F6A3268.1060800@raszuk.net> To: sidr wg list X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:51:28 -0000 On Mar 21, 2012, at 1:56 PM, Robert Raszuk wrote: > > On 2012-03-21 16:50, Brian Dickson wrote: >> ... >> Doing so would require, at a minimum, stopping forward progress on >> -protocol docs, until the -reqs- and -threat- are adequately = addressed. >=20 > On 2012-03-21 20:33, Russ White wrote: > > ... > > Given these failures, maybe it's time to start with requirements > > (rather than a solution) first, and see if we come to a better > > outcome. >=20 > On 2012-03-21 20:40, Eric Osterweil wrote: > > > > +1 >=20 >=20 > Having a reasonable requirements document which defines what is that = should be protected seem like a very reasonable thing. Clearly for some = who "make/made decisions on the protocol" this may be a bit = uncomfortable as their design choices now would need to compete with = design proposals from others. >=20 > The requirement should explicitly list elements to provide ability for = gradual deployment .. maybe co-existence for some time. Clearly ideas of = removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not = really helping gradual deployment. >=20 > Decent requirement document should also specifically prohibit use of = any tools which can be controlled by politicians/courts to decide who = stays in the internet and who becomes uncomfortable and needs to be cut = out. >=20 > So: +1 >=20 > Rgs, > R. +1 more. -shane= From christopher.morrow@gmail.com Wed Mar 21 13:57:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A696C21E80BF for ; Wed, 21 Mar 2012 13:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIpDAYJj11YQ for ; Wed, 21 Mar 2012 13:57:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1621E8051 for ; Wed, 21 Mar 2012 13:57:47 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1478841yhk.31 for ; Wed, 21 Mar 2012 13:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tdXsfVPXOw3Br1SkHoGfv6uhqedEf+eN5aGsuK/D12c=; b=Dji11mDHcbm2nV1hkCLL3JPv7IJgQf+01YYDyLNNZns5dS3WCy26hQws7EZvRsxiG2 eK54zbgEdf7ov6ZptfGZuRQjd0rrL9saVlmfr5iVIo/KKt5+UsEgIIy/dJPUCH5geSA8 n1xueGcnk3n+srtQiYOrGOslqflt3yIkJ8GtZrU6KdxIzPxwPUQuXoe1fMey4GFJlxu0 xVxpOrIG3G1SoFoYT/8HyFfvlW4B0tTfqcIOtvZ/qVeHt0nd5j0cjSaONXr3pgkkN+9y Cwv9J7wwKCBo9oD4mI0NpxS0nbEvuZ/dmazRmdbp7dwqxdAx34JdnMOBhYO1qcjBXP0p Z1zw== MIME-Version: 1.0 Received: by 10.60.9.38 with SMTP id w6mr6198580oea.41.1332363467391; Wed, 21 Mar 2012 13:57:47 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 13:57:47 -0700 (PDT) In-Reply-To: <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> Date: Wed, 21 Mar 2012 16:57:47 -0400 X-Google-Sender-Auth: wjYnQzqWiXYNwyvJJcHdrz2-rw0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:57:48 -0000 On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil w= rote: > How about we turn this around with a simple question: > Suppose two different feasible paths are being evaluated for a single pre= fix/origin pair and one was delivered via a signed bgpsec update, and the o= ther was delivered via an unsigned update. =A0What annotations/influencers/= considerations/etc. does the bgpsec design suggest when the router is makin= g its path selection between these two? > ideall, I think, the process is something like: 1) first path gets evaluated, is it 'good' (next-hop reachable, not discarded by prefix-list/etc) 2) second path gets evaluated, is it 'good' (same as above + origin-validate + path-validation) If both 1 and 2 come out 'ok', assume each path was received from a different peer on the same device: 1) 1 - 2 - 701 - you 2) 1 - 3 - 7018 - you If you decide that your network's policy is 'prefer signed and valid over unsigned' paths, you'd pick #2. It could be that your method of doing this is saying: route-map inbound-bgp permit 10 if route-signed and verified set localpref 100 Which ideally would let localpref on the #1 route stay normal =3D=3D 80 and magically you'd just use the 'right' (from your perspective) path. (signed and verified). of course, in the beginning of this you may choose a more conservative: route-map inbound-bgp permit 10 if route-signed and verified set community you:verified so you could measure the deployment state of your customers + rest-o-interw= ebs. In the end, I think 'bgpsec suggests' that the operator would make some decision... ideally the same decision across the network. does that make sense? (the policy is deliberately short and simple, obviously real policy is longer/stranger, but the end result is the same) -chris From christopher.morrow@gmail.com Wed Mar 21 14:00:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89FA21E8098 for ; Wed, 21 Mar 2012 14:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id monqXExZCY1C for ; Wed, 21 Mar 2012 14:00:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3687F21E8051 for ; Wed, 21 Mar 2012 14:00:40 -0700 (PDT) Received: by yenm5 with SMTP id m5so1493029yen.31 for ; Wed, 21 Mar 2012 14:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=480L7RsD+dsH/8xbUCKxp29OADQCmb9O9cjPSyEfD0s=; b=U9DiHzZBj7AOvCZDsBF/hgV6Cxg1R/jxLoZXCOAM3cq1o1djfEctTe0p1PGpo53mkP t42l3ULXoH8Yv7d2/kHBFOkgzH/Wv85VPTLoceuIV6nXEtdLlQtEr6SCCL/NR3sRH+wT it201KplezUddx7RXQ59FpOsagID822hVA+Og0CwEjspMPnce+Nh3uxk8DVdCwTb3g+h kLn8roqJ4cccPlRrZmJAqxPmU7akVytSkLTt+gsUYm1S5UEEDDtupWofwVq/4g3H6AJD sOGTpAs4FjgoNqDNOePC8FeqVWeplIjqzLMMefn9awNY00Fqc96W0XP8rRjymrOZgsnq igkw== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr6392623obb.61.1332363639629; Wed, 21 Mar 2012 14:00:39 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:00:39 -0700 (PDT) In-Reply-To: <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> Date: Wed, 21 Mar 2012 17:00:39 -0400 X-Google-Sender-Auth: RQtF1Ac9s8HiZxIAGcpm9TEI4JY Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:00:40 -0000 On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil wrote: > My input is that the current work that does not address the real route leak threat, and it is therefore insufficient. and many, many times ... 'how would you do this, really, show me the math' has been asked. the closest so far is Brian's set of 3 id's which are being chattered about in IDR and some in SIDR as well. btw, Is 'the real route leak threat' different in some way than other (what other?) route-leak-threats? and is it the only thing you care about? (I think there are others, is this the only uncovered hole in the pasture? or are you worried about breaking your leg on something else as well?) -chris From eosterweil@verisign.com Wed Mar 21 14:04:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58221E80F8 for ; Wed, 21 Mar 2012 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P7X4TiVXPxZ for ; Wed, 21 Mar 2012 14:04:32 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 708BF21E803C for ; Wed, 21 Mar 2012 14:04:29 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKT2pCWSLG+dssTtg0G/RZD+5sftD9cal7@postini.com; Wed, 21 Mar 2012 14:04:30 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2LL4LaN028100; Wed, 21 Mar 2012 17:04:25 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 17:04:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 17:04:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13DAFF92-94E7-4FFB-A1C3-7F1F93BD2E0F@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 21:04:21.0510 (UTC) FILETIME=[30034A60:01CD07A6] Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:04:32 -0000 On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil = wrote: >=20 >> How about we turn this around with a simple question: >> Suppose two different feasible paths are being evaluated for a single = prefix/origin pair and one was delivered via a signed bgpsec update, and = the other was delivered via an unsigned update. What = annotations/influencers/considerations/etc. does the bgpsec design = suggest when the router is making its path selection between these two? >>=20 >=20 > ideall, I think, the process is something like: > 1) first path gets evaluated, is it 'good' (next-hop reachable, not > discarded by prefix-list/etc) > 2) second path gets evaluated, is it 'good' (same as above + > origin-validate + path-validation) >=20 > If both 1 and 2 come out 'ok', assume each path was received from a > different peer on the same device: > 1) 1 - 2 - 701 - you > 2) 1 - 3 - 7018 - you >=20 > If you decide that your network's policy is 'prefer signed and valid > over unsigned' paths, you'd pick #2. It could be that your method of > doing this is saying: > route-map inbound-bgp permit 10 > if route-signed and verified > set localpref 100 >=20 > Which ideally would let localpref on the #1 route stay normal =3D=3D = 80 > and magically you'd just use the 'right' (from your perspective) path. > (signed and verified). >=20 > of course, in the beginning of this you may choose a more = conservative: > route-map inbound-bgp permit 10 > if route-signed and verified > set community you:verified >=20 > so you could measure the deployment state of your customers + = rest-o-interwebs. >=20 > In the end, I think 'bgpsec suggests' that the operator would make > some decision... ideally the same decision across the network. >=20 > does that make sense? (the policy is deliberately short and simple, > obviously real policy is longer/stranger, but the end result is the > same) Indeed, this makes sense, thanks for the detailed response. However, = this also illustrates an evolution of semantics under non-attack = circumstances. :) Eric From christopher.morrow@gmail.com Wed Mar 21 14:06:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460AC21E803C for ; Wed, 21 Mar 2012 14:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.277 X-Spam-Level: X-Spam-Status: No, score=-103.277 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E55k9tE9hVY9 for ; Wed, 21 Mar 2012 14:06:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6B21E80D6 for ; Wed, 21 Mar 2012 14:06:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1502804ghb.31 for ; Wed, 21 Mar 2012 14:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8fjE1jrkWBlP5YMPCAaD3Q1d3KXXJQ8rpy0LIE4JW8Y=; b=uqpiGEVNl5cMYwnc1JdjHeo5gnV+bRlJH8jNdX2zSQuB+23AzIpzTD+H41R714w4zT jJWGI54NQvAMREqDCpTFkmTNUb9a6sW/n+JrDnWSdSp4C9w8HnduydhufrCqDsS6s+kX kh46JI+e8rCl/7BhHpZhQuZdkBs3XUX+2YI1r3YLLGPe7Xk1vxy++e9YmW7wuhI3b2xw gIgVagf5jEmv5Zn9rdTj0QZ3SHKJT79jt4pNp4calZAf5X+lpKZb9RxQCgfKCGnE+G43 COGSL9u3xQIX5Bxd1VTUyV/dVJ7O5Jnp0teHKVGuiHEES5o6AzI0kB6hqicDwr1wXxsH 8Vpg== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr6332985oei.71.1332363963182; Wed, 21 Mar 2012 14:06:03 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:06:03 -0700 (PDT) In-Reply-To: <13DAFF92-94E7-4FFB-A1C3-7F1F93BD2E0F@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> <13DAFF92-94E7-4FFB-A1C3-7F1F93BD2E0F@verisign.com> Date: Wed, 21 Mar 2012 17:06:03 -0400 X-Google-Sender-Auth: l9g6GqlLZgqIK5Pu_MqCd_jycFg Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:06:04 -0000 On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil w= rote: > > On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote: > >> On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil wrote: >> >>> How about we turn this around with a simple question: >>> Suppose two different feasible paths are being evaluated for a single p= refix/origin pair and one was delivered via a signed bgpsec update, and the= other was delivered via an unsigned update. =A0What annotations/influencer= s/considerations/etc. does the bgpsec design suggest when the router is mak= ing its path selection between these two? >>> >> >> ideall, I think, the process is something like: >> =A01) first path gets evaluated, is it 'good' (next-hop reachable, not >> discarded by prefix-list/etc) >> =A02) second path gets evaluated, is it 'good' (same as above + >> origin-validate + path-validation) >> >> If both 1 and 2 come out 'ok', assume each path was received from a >> different peer on the same device: >> =A01) 1 - 2 - 701 - you >> =A02) 1 - 3 - 7018 - you >> >> If you decide that your network's policy is 'prefer signed and valid >> over unsigned' paths, you'd pick #2. It could be that your method of >> doing this is saying: >> =A0route-map inbound-bgp permit 10 >> =A0 =A0if route-signed and verified >> =A0 =A0set localpref 100 >> >> Which ideally would let localpref on the #1 route stay normal =3D=3D 80 >> and magically you'd just use the 'right' (from your perspective) path. >> (signed and verified). >> >> of course, in the beginning of this you may choose a more conservative: >> =A0 route-map inbound-bgp permit 10 >> =A0 =A0 =A0if route-signed and verified >> =A0 =A0 =A0 =A0set community you:verified >> >> so you could measure the deployment state of your customers + rest-o-int= erwebs. >> >> In the end, I think 'bgpsec suggests' that the operator would make >> some decision... ideally the same decision across the network. >> >> does that make sense? (the policy is deliberately short and simple, >> obviously real policy is longer/stranger, but the end result is the >> same) > > Indeed, this makes sense, thanks for the detailed response. =A0However, t= his also illustrates an evolution of semantics under non-attack circumstanc= es. :) expand please. From christopher.morrow@gmail.com Wed Mar 21 14:07:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89FB21F871C for ; Wed, 21 Mar 2012 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwR2O76qWPr6 for ; Wed, 21 Mar 2012 14:07:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 407F521F8720 for ; Wed, 21 Mar 2012 14:07:45 -0700 (PDT) Received: by yenm5 with SMTP id m5so1498846yen.31 for ; Wed, 21 Mar 2012 14:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SV3Retf6/IaqQ8OhgUtjufg+i9NG0K86agTlpA+CzGU=; b=k5/YeRnwFgB04HnCryTTX5CG9vU25eu6gB9C1ZA93EgknMZHpFYB1avxhb8Sm8z/EA UEnnE7he+2coPq8o1HwHtNyXaLJOyygXdOtfrNKqMtayOIqSnW0eiYyLYeq1W2gYT2aW hR570yZoi9vzXCGiuXU6h15N1qRUEi+8nSUxqGtjhRjR8sFEOeu6KyQowzFxsOTqXED9 R3jESLKfEbdQgQodP1sx+IMjFUrpv7XN6X6W26WWfuw9ab4M3bGFp4c46P5ovZDnIy6m 0IUDXEiRY7A2a4hKCPw7B4OOMdxl408jnEHF3dq+2kFV+GEVzup2hyaKbOVoRyeV2++N Jqbg== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr6587419obv.41.1332364064708; Wed, 21 Mar 2012 14:07:44 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:07:44 -0700 (PDT) In-Reply-To: <4F6A3138.2050703@riw.us> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <4F69360A.7010505@riw.us> <4F69B8FA.6080205@riw.us> <4F69BF92.2070904@riw.us> <4F69C549.1050808@riw.us> <4F69DB1D.1000905@riw.us> <4F69E0E4.5040509@riw.us> <4F69EB29.5000507@riw.us> <4F6A3138.2050703@riw.us> Date: Wed, 21 Mar 2012 17:07:44 -0400 X-Google-Sender-Auth: i7rfTSOizpDWVzSF_DbX_BAleE8 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:07:46 -0000 On Wed, Mar 21, 2012 at 3:51 PM, Russ White wrote: >> nope, it's bits that you can choose to use or not. > > In other words, you've added another set of "wiggle words" to your > definition. "It's not policy because it's not signing something saying > you shouldn't do x, and because anyone can ignore the signature anyway." no, I don't think we can enforce any one use this... no matter how shiney it may seem. I think if we offer more data to the bgp-user, in a fashion they can digest and use, they may make a better decision. we can not, today, publish or require publishing 'you can only advertise to X'. Certainly a single operator can decide 'I will only advertise to X' or 'I will only accept Y advertisements from Z' (this happens today, outside of any concept of 'security' and the protocol). -chris From shane@castlepoint.net Wed Mar 21 14:14:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA8D21F873A for ; Wed, 21 Mar 2012 14:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kCwu9roXh3j for ; Wed, 21 Mar 2012 14:14:01 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id EC82521F8429 for ; Wed, 21 Mar 2012 14:14:00 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BE89B268063; Wed, 21 Mar 2012 15:14:00 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 21 Mar 2012 15:14:00 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60134; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 21 Mar 2012 15:13:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:14:02 -0000 On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil = wrote: >> My input is that the current work that does not address the real = route leak threat, and it is therefore insufficient. >=20 > and many, many times ... 'how would you do this, really, show me the > math' has been asked. Answer: Evaluate policy. -shane > the closest so far is Brian's set of 3 id's > which are being chattered about in IDR and some in SIDR as well. >=20 > btw, Is 'the real route leak threat' different in some way than other > (what other?) route-leak-threats? and is it the only thing you care > about? (I think there are others, is this the only uncovered hole in > the pasture? or are you worried about breaking your leg on something > else as well?) >=20 > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From dougm@nist.gov Wed Mar 21 14:16:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA1321F875E for ; Wed, 21 Mar 2012 14:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjU1EWEGG6yN for ; Wed, 21 Mar 2012 14:16:02 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE6221F873D for ; Wed, 21 Mar 2012 14:16:02 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 17:15:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 21 Mar 2012 17:12:12 -0400 From: "Montgomery, Douglas" To: "robert@raszuk.net" , "sidr@ietf.org" Date: Wed, 21 Mar 2012 17:15:52 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0Hp0hL6kjwUtpfSaecfJzHaPbrFg== Message-ID: In-Reply-To: <4F6A3268.1060800@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:16:03 -0000 On 3/21/12 3:56 PM, "Robert Raszuk" wrote: > > > On 2012-03-21 16:50, Brian Dickson wrote: >> ... >> Doing so would require, at a minimum, stopping forward progress on >> -protocol docs, until the -reqs- and -threat- are adequately addressed. > >On 2012-03-21 20:33, Russ White wrote: > > ... > > Given these failures, maybe it's time to start with requirements > > (rather than a solution) first, and see if we come to a better > > outcome. > >On 2012-03-21 20:40, Eric Osterweil wrote: > > > > +1 > > >Having a reasonable requirements document which defines what is that >should be protected seem like a very reasonable thing. Clearly for some >who "make/made decisions on the protocol" this may be a bit >uncomfortable as their design choices now would need to compete with >design proposals from others. > >The requirement should explicitly list elements to provide ability for >gradual deployment .. maybe co-existence for some time. Clearly ideas of >removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not >really helping gradual deployment. > >Decent requirement document should also specifically prohibit use of any >tools which can be controlled by politicians/courts to decide who stays >in the internet and who becomes uncomfortable and needs to be cut out. OK, so we have existence proofs that DNS based solutions are out .... ;^) I think it wise before making strategic decisions based upon such requirements, one should carefully examine what the real risk scenarios are, what techniques might mitigate them, and then examine if the remaining risks are substantially different than those that already exist in the system. So far, most of the concerns I have heard are no different than any other globally distributed hierarchical system where individual components are subject to local laws. Dougm From eosterweil@verisign.com Wed Mar 21 14:17:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64321F873D for ; Wed, 21 Mar 2012 14:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwUC5bR5-iAS for ; Wed, 21 Mar 2012 14:17:49 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id E19FC21F873A for ; Wed, 21 Mar 2012 14:17:48 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKT2pFeS0oICPJuPppwWf99PwErPzATy97@postini.com; Wed, 21 Mar 2012 14:17:48 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2LLHihJ028606; Wed, 21 Mar 2012 17:17:44 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 17:17:44 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 17:17:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50F685EA-D18A-4C60-A610-9909F268B124@verisign.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 21:17:44.0000 (UTC) FILETIME=[0E558C00:01CD07A8] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:17:50 -0000 Hey Chris, On Mar 21, 2012, at 5:00 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil = wrote: >> My input is that the current work that does not address the real = route leak threat, and it is therefore insufficient. >=20 > and many, many times ... 'how would you do this, really, show me the > math' has been asked. the closest so far is Brian's set of 3 id's > which are being chattered about in IDR and some in SIDR as well. As I mentioned to Steve, ``If a system is repeatedly subverted along a = specific attack vector, the fact that you can see evidence of = subversion, but you can't model it with a closed form equation or a = formal proof does _not_ mean you should withhold the development of = protections! That's like saying: I haven't got a formal proof for what = a local escalation of privileges is, on my Linux box... I hope Linus = comes up w/ a formal definition soon so that I stop getting pwnd!'' I don't know that math (or any other formalism) is generally considered = a requirement for the incorporation of security protections when they = are needed. Indeed, the notion that security protections must be = predicated on some form of formal analysis seems like a = severe/unnecessary hindrance. I don't know that the current BGPSEC = design is evolvable to remediate the threats we currently face, but that = does _not_ mean we should avoid addressing the problem. >=20 > btw, Is 'the real route leak threat' different in some way than other > (what other?) route-leak-threats? and is it the only thing you care > about? (I think there are others, is this the only uncovered hole in > the pasture? or are you worried about breaking your leg on something > else as well?) 1) Sorry, 'real' was only added to emphasize that this is an existing = problem. Nothing more... 2) I am actually listening to what those operators that I talk to are = worried about. I've heard many issue warnings about the threat that = route leaks pose, and some of my own research tends to underscore some = more subtle (but I think very dangerous) threats that I think route = leaks enable quite nicely. Thus, this is my view of what I've heard = many people say and what I have seen. I'm sure there are others, but = that's where an accepted requirements doc would be helpful. Eric= From eosterweil@verisign.com Wed Mar 21 14:17:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237EC21F8769 for ; Wed, 21 Mar 2012 14:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSh589T0ZKHj for ; Wed, 21 Mar 2012 14:17:56 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3F92921F8768 for ; Wed, 21 Mar 2012 14:17:56 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKT2pFgFOVNRr8BbZwh/WNJKy9mCIHqTr8@postini.com; Wed, 21 Mar 2012 14:17:56 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2LLHqhJ005816; Wed, 21 Mar 2012 17:17:52 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 17:17:51 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 17:17:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C321BE3-F8E0-4206-B057-B2D534088420@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> <13DAFF92-94E7-4FFB-A1C3-7F1F93BD2E0F@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 21:17:51.0828 (UTC) FILETIME=[13000140:01CD07A8] Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:17:57 -0000 Hey Chris, On Mar 21, 2012, at 5:06 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil = wrote: >>=20 >> On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote: >>=20 >>> On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil = wrote: >>>=20 >>>> How about we turn this around with a simple question: >>>> Suppose two different feasible paths are being evaluated for a = single prefix/origin pair and one was delivered via a signed bgpsec = update, and the other was delivered via an unsigned update. What = annotations/influencers/considerations/etc. does the bgpsec design = suggest when the router is making its path selection between these two? >>>>=20 >>>=20 >>> ideall, I think, the process is something like: >>> 1) first path gets evaluated, is it 'good' (next-hop reachable, not >>> discarded by prefix-list/etc) >>> 2) second path gets evaluated, is it 'good' (same as above + >>> origin-validate + path-validation) >>>=20 >>> If both 1 and 2 come out 'ok', assume each path was received from a >>> different peer on the same device: >>> 1) 1 - 2 - 701 - you >>> 2) 1 - 3 - 7018 - you >>>=20 >>> If you decide that your network's policy is 'prefer signed and valid >>> over unsigned' paths, you'd pick #2. It could be that your method of >>> doing this is saying: >>> route-map inbound-bgp permit 10 >>> if route-signed and verified >>> set localpref 100 >>>=20 >>> Which ideally would let localpref on the #1 route stay normal =3D=3D = 80 >>> and magically you'd just use the 'right' (from your perspective) = path. >>> (signed and verified). >>>=20 >>> of course, in the beginning of this you may choose a more = conservative: >>> route-map inbound-bgp permit 10 >>> if route-signed and verified >>> set community you:verified >>>=20 >>> so you could measure the deployment state of your customers + = rest-o-interwebs. >>>=20 >>> In the end, I think 'bgpsec suggests' that the operator would make >>> some decision... ideally the same decision across the network. >>>=20 >>> does that make sense? (the policy is deliberately short and simple, >>> obviously real policy is longer/stranger, but the end result is the >>> same) >>=20 >> Indeed, this makes sense, thanks for the detailed response. However, = this also illustrates an evolution of semantics under non-attack = circumstances. :) >=20 > expand please. Sure, there is now a new element in the BGP update (the sig(s)) whose = presence, nature, or absence causes the interpretation of the update to = differ. While I still disagree with the earlier caveat that all bets = are off during an attack, that statement clearly does cover this case = where one update simply isn't signed. That's what I meant, though I = didn't mean to be cavalier when I said it before... Sorry if it came off = as a barb. :) Eric From robert@raszuk.net Wed Mar 21 14:19:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9121F8675 for ; Wed, 21 Mar 2012 14:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQCiXu1Yr+l2 for ; Wed, 21 Mar 2012 14:19:09 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3711521F8668 for ; Wed, 21 Mar 2012 14:19:09 -0700 (PDT) Received: (qmail 1970 invoked by uid 399); 21 Mar 2012 21:19:08 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.67) by mail1310.opentransfer.com with ESMTPM; 21 Mar 2012 21:19:08 -0000 X-Originating-IP: 83.9.123.67 Message-ID: <4F6A45CE.6060607@raszuk.net> Date: Wed, 21 Mar 2012 22:19:10 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:19:10 -0000 Hi Chris, > In the end, I think 'bgpsec suggests' that the operator would make > some decision... ideally the same decision across the network. Such decision is inherently per prefix. So even assuming ideal case and such policy like in your example would be the same across given AS how would you see such policy to be the same across the entire path given update traverses ? Aren't you afraid about swiss cheese effect for end-to-end connectivity if some ASes prefer signed and some other non signed paths ? What happens in your example if singed comes with PATH_SIG listing 4 ASes (pCount=1 of each) and real AS_PATH is length of 3 ? If you set local pref on inbound (just like shipping code allows for origin validation) you will deliberately choose longer path as best since LOC_PREF is checked much earlier in BGP Best path then AS_PATH length (even assuming those would be comparable across two attributes). Thx, R. From christopher.morrow@gmail.com Wed Mar 21 14:21:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42121F8778 for ; Wed, 21 Mar 2012 14:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Le0IKGfck-0 for ; Wed, 21 Mar 2012 14:21:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A307721F8773 for ; Wed, 21 Mar 2012 14:21:03 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1520993ggm.31 for ; Wed, 21 Mar 2012 14:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rQhX2Zy+mCG0e6f9+9lpxDjgdNOc/txJkogxsnQ3GbI=; b=BTaq2M4sogn+/QeELhHEY/t+Y0y7sYLrXG76o8iLN5l6CSKUUg2Bds3h1H0sSGdaQr BGtAOnvNZRqNXSdG9TWRnwM6vSTgyP6ZRATkHkkvl3RnS0wIaHvWA812cSxIhBjc4dcj ZK7fcYcziZ09F97VA4fA9IbWG9zqzR90jA0CqQPYk2ZmXd3Om1bVfLq+Vn9oiqKLs4+T Og9ZHA5eTWuo5OOgnzGvRBMkDs5xW0jI7Cbh6qXX+KBuF+tkm+8CNv2BLqf4YuxDLwkU s+5SKqAizUjN9bAkKHrQNHLoo3zzfBEu5LYPXkQRmSYO0GdoreVxqoM7fWECTPPBz+PI GTXw== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr6522246obb.71.1332364863149; Wed, 21 Mar 2012 14:21:03 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:21:02 -0700 (PDT) In-Reply-To: <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> Date: Wed, 21 Mar 2012 17:21:02 -0400 X-Google-Sender-Auth: xtn9IDmiZsBAWFpLKg6OtPVGQ94 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:21:04 -0000 On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante wrote: > > On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil wrote: >>> My input is that the current work that does not address the real route leak threat, and it is therefore insufficient. >> >> and many, many times ... 'how would you do this, really, show me the >> math' has been asked. > > Answer: Evaluate policy. 'apply prefix lists' you mean? >> the closest so far is Brian's set of 3 id's >> which are being chattered about in IDR and some in SIDR as well. >> >> btw, Is 'the real route leak threat' different in some way than other >> (what other?) route-leak-threats? and is it the only thing you care >> about? (I think there are others, is this the only uncovered hole in >> the pasture? or are you worried about breaking your leg on something >> else as well?) >> >> -chris >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From shane@castlepoint.net Wed Mar 21 14:26:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44321E80DC for ; Wed, 21 Mar 2012 14:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1az7Aor1+Kf for ; Wed, 21 Mar 2012 14:26:59 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 374A821E80D6 for ; Wed, 21 Mar 2012 14:26:59 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C410C268063; Wed, 21 Mar 2012 15:26:58 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 21 Mar 2012 15:26:58 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60244; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: Date: Wed, 21 Mar 2012 15:26:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:26:59 -0000 On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante = wrote: >>=20 >> On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >>> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil = wrote: >>>> My input is that the current work that does not address the real = route leak threat, and it is therefore insufficient. >>>=20 >>> and many, many times ... 'how would you do this, really, show me the >>> math' has been asked. >>=20 >> Answer: Evaluate policy. >=20 > 'apply prefix lists' you mean? No. Evaluate _policy_. Policy is about whether an ASN /intended/ to = announce a path to another ASN _or_ not. More succinctly: one needs = input to verify output, (since you said "show me the math"). -shane= From christopher.morrow@gmail.com Wed Mar 21 14:37:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB58121E8140 for ; Wed, 21 Mar 2012 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5whQzbY5gvHZ for ; Wed, 21 Mar 2012 14:37:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95B8C21E8139 for ; Wed, 21 Mar 2012 14:37:43 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1506033yhk.31 for ; Wed, 21 Mar 2012 14:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JGU0wwDOCwkeBciIp1A8iNmsGj619Irmpcif6q+03N0=; b=Yzmx8q67uqIRcbEPkjmk5xqXeiQBWc606d61y7aFJereG4eoJK+vnWpiToDjMfourD 3fODntB+hlBLC9yQL8KBOJEnhQIOOzx4yolqTDW4GYoCNGlKABYC2y+Lwa02ir+ZMlr1 FB41nq3kMehHcGzUySvU1HypfglhjRIX1ClHFpgiGQpjWDPrDs7kKEIUhU+PFbzdwBhO g+7Ew7IRL4akjMI/zeQARG2dtfpeITDpAD7Qhbx8hLuHtljqL2cUfsVx+cCf0vTXzmZd /SFgwqQDC8RmUFrw4j4B+CY6d7HYWAS0LX88tWipaOT8RwvidZZdUyUk65MFHCKuVq8I Xykg== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr6522502obb.61.1332365863179; Wed, 21 Mar 2012 14:37:43 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:37:42 -0700 (PDT) In-Reply-To: <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> Date: Wed, 21 Mar 2012 17:37:42 -0400 X-Google-Sender-Auth: cBOzJYQQErji-NmgbP-u8QTeBbQ Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:37:47 -0000 On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante wrote= : > > On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote: >> On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante wr= ote: >>> >>> On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >>>> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil wrote: >>>>> My input is that the current work that does not address the real rout= e leak threat, and it is therefore insufficient. >>>> >>>> and many, many times ... 'how would you do this, really, show me the >>>> math' has been asked. >>> >>> Answer: Evaluate policy. >> >> 'apply prefix lists' you mean? > > No. =A0Evaluate _policy_. =A0Policy is about whether an ASN /intended/ to= announce a path to another ASN _or_ not. =A0More succinctly: one needs inp= ut to verify output, (since you said "show me the math"). > smarty... :) someone reminded me that I shouldn't be quite so flip 'show me the math' is really, 'how can I tell from 2 as-hops away that: 1 -> 2 -> 3 -> me is a leak?' Randy posted on nanog (to you/shane, I think) a message with content like: "to do this rigorously, i would need to form the transitive closure of the business policies of every inter-provider link on the internet." in this: message. This is what you mean as well, yes? -chris From randy@psg.com Wed Mar 21 14:37:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC28921E8144 for ; Wed, 21 Mar 2012 14:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fixfq3U6ReXK for ; Wed, 21 Mar 2012 14:37:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2CE21E8142 for ; Wed, 21 Mar 2012 14:37:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SATED-000OTu-Dz; Wed, 21 Mar 2012 21:37:57 +0000 Date: Wed, 21 Mar 2012 22:37:56 +0100 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:37:58 -0000 >>> Answer: Evaluate policy. >> 'apply prefix lists' you mean? > No. Evaluate _policy_. Policy is about whether an ASN /intended/ to > announce a path to another ASN _or_ not. More succinctly: one needs > input to verify output, (since you said "show me the math"). From: Randy Bush Subject: Re: do not filter your customers To: Shane Amante Cc: North American Network Operators' Group Date: Sat, 25 Feb 2012 15:22:35 +0530 > as would be solving world hunger, war, bad cooking, especially bad > cooking. > > route leaks, as much as i understand them > o are indeed bad ops issues > o are not security per se > o are a violation of business relationshiops > o and 20 years of fighting them have not given us any significant > increase in understanding, formal definition, or prevention. let me try to express how i see the problem. to do this rigorously, i would need to form the transitive closure of the business policies of every inter-provider link on the internet. why i say it is per-link and not just inter-as (which would be hard enough) is that i know a *lot* of examples where two ass have different business policies on different links. [ i'll exchange se asian routes with you in hong kong, but only sell you transit in tokyo. we have two links in frankfurt, one local peering and one international transit. ] it is not just one-hop because telstra was 'supposed to' pass some customers' customers' routes to optus. i find this daunting. but i would *really* like to be able to rigorously solve it. please please please explain to me how it is simpler than this. randy From shane@castlepoint.net Wed Mar 21 14:42:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D421E8032 for ; Wed, 21 Mar 2012 14:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecaCfG4SAvaR for ; Wed, 21 Mar 2012 14:42:18 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5921E8013 for ; Wed, 21 Mar 2012 14:42:18 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 6E387268063; Wed, 21 Mar 2012 15:42:18 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 21 Mar 2012 15:42:18 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60374; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: Date: Wed, 21 Mar 2012 15:42:17 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:42:19 -0000 On Mar 21, 2012, at 3:37 PM, Christopher Morrow wrote: > On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante = wrote: >>=20 >> On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote: >>> On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante = wrote: >>>>=20 >>>> On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >>>>> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil = wrote: >>>>>> My input is that the current work that does not address the real = route leak threat, and it is therefore insufficient. >>>>>=20 >>>>> and many, many times ... 'how would you do this, really, show me = the >>>>> math' has been asked. >>>>=20 >>>> Answer: Evaluate policy. >>>=20 >>> 'apply prefix lists' you mean? >>=20 >> No. Evaluate _policy_. Policy is about whether an ASN /intended/ to = announce a path to another ASN _or_ not. More succinctly: one needs = input to verify output, (since you said "show me the math"). >>=20 >=20 > smarty... :) >=20 > someone reminded me that I shouldn't be quite so flip 'show me the > math' is really, 'how can I tell from 2 as-hops away that: >=20 > 1 -> 2 -> 3 -> me >=20 > is a leak?' >=20 > Randy posted on nanog (to you/shane, I think) a message with content = like: > "to do this rigorously, i > would need to form the transitive closure of the business policies of > every inter-provider link on the internet." >=20 > in this: = > message. This is what you mean as well, yes? Yes. And, to answer Randy's question in that message ... I'm not = asserting that this is a _simple_ problem to be solved, but we should = not ignore the problem b/c it's "hard" ... otherwise, we wouldn't have = the Internet, as it exists today, nor a lot of other things. -shane= From kent@bbn.com Wed Mar 21 14:47:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2496D21E8032 for ; Wed, 21 Mar 2012 14:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os7V61-i0n5S for ; Wed, 21 Mar 2012 14:47:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A143321E801E for ; Wed, 21 Mar 2012 14:47:04 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49180) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SATMp-000Ole-W3; Wed, 21 Mar 2012 17:46:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> Date: Wed, 21 Mar 2012 16:54:12 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:47:05 -0000 As I said in my prior message, I'm not going to continue contributing to a thread that seems pointless at this stage. Steve From randy@psg.com Wed Mar 21 14:47:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD421E8083 for ; Wed, 21 Mar 2012 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betB4IG47k3C for ; Wed, 21 Mar 2012 14:47:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DE73F21E801E for ; Wed, 21 Mar 2012 14:47:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SATNa-000OVE-AH; Wed, 21 Mar 2012 21:47:38 +0000 Date: Wed, 21 Mar 2012 22:47:37 +0100 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:47:39 -0000 >> in this: >> >> message. This is what you mean as well, yes? > Yes. And, to answer Randy's question in that message ... I'm not > asserting that this is a _simple_ problem to be solved, but we should > not ignore the problem b/c it's "hard" ... otherwise, we wouldn't have > the Internet, as it exists today, nor a lot of other things. actually, there is a solution to that problem. it's called bgp. bgpsec is an attempt to protect that solution from some demonstrated attacks. if you have another solution, do tell us. but ranting that world hunger should be solved does not feed anyone. randy From dougm@nist.gov Wed Mar 21 14:48:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60B821F866D for ; Wed, 21 Mar 2012 14:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c7sybgoHNWs for ; Wed, 21 Mar 2012 14:48:56 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A24F121F866C for ; Wed, 21 Mar 2012 14:48:55 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 17:48:50 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 21 Mar 2012 17:48:54 -0400 From: "Montgomery, Douglas" To: Shane Amante , Christopher Morrow Date: Wed, 21 Mar 2012 17:48:51 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0Hq+Ps4FHzn8UDSRymRUjAOm+Npw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:48:56 -0000 Many moons ago (IETF attendance was <100) there was an effort to solve this problem (Open Routing Working Group). Stable refs are hard to find ... But the following gives a decent summary of an approach to such a solution. http://research.cens.ucla.edu/people/estrin/resources/journals/1991jan-Estr in-Streenstrup-InterDomain.pdf A long long way from BGP ... But maybe that is where you wan to go? dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 5:42 PM, "Shane Amante" wrote: > >On Mar 21, 2012, at 3:37 PM, Christopher Morrow wrote: >> On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante >>wrote: >>>=20 >>> On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote: >>>> On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante >>>>wrote: >>>>>=20 >>>>> On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >>>>>> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil >>>>>> wrote: >>>>>>> My input is that the current work that does not address the real >>>>>>>route leak threat, and it is therefore insufficient. >>>>>>=20 >>>>>> and many, many times ... 'how would you do this, really, show me the >>>>>> math' has been asked. >>>>>=20 >>>>> Answer: Evaluate policy. >>>>=20 >>>> 'apply prefix lists' you mean? >>>=20 >>> No. Evaluate _policy_. Policy is about whether an ASN /intended/ to >>>announce a path to another ASN _or_ not. More succinctly: one needs >>>input to verify output, (since you said "show me the math"). >>>=20 >>=20 >> smarty... :) >>=20 >> someone reminded me that I shouldn't be quite so flip 'show me the >> math' is really, 'how can I tell from 2 as-hops away that: >>=20 >> 1 -> 2 -> 3 -> me >>=20 >> is a leak?' >>=20 >> Randy posted on nanog (to you/shane, I think) a message with content >>like: >> "to do this rigorously, i >> would need to form the transitive closure of the business policies of >> every inter-provider link on the internet." >>=20 >> in this:=20 >> >> message. This is what you mean as well, yes? > >Yes. And, to answer Randy's question in that message ... I'm not >asserting that this is a _simple_ problem to be solved, but we should not >ignore the problem b/c it's "hard" ... otherwise, we wouldn't have the >Internet, as it exists today, nor a lot of other things. > >-shane >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 21 14:56:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F60F21E8083 for ; Wed, 21 Mar 2012 14:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udQ5DOgBWhfI for ; Wed, 21 Mar 2012 14:56:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA81A21E801E for ; Wed, 21 Mar 2012 14:56:39 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1130779obb.31 for ; Wed, 21 Mar 2012 14:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QpNN5P+wDPuDW0VUp0s5vCpMpVU5ZtFAmJqJyrRLEco=; b=HxEbDvgnHTHLYNXwegjVycJA3cvPeOwIIJ3UCROIMiAW4rFLKhNj+qjpdbBJ8WVvCS ysDnet/uEz4ePjx48zwb8a0EiZG06upozWRcDjyGm/Wzn4ACql5ocEhF5eZ/oOCd+cK5 m3oMFy9Fv8nB7x8NLQzLNql8JFkBYIC4IEqRTLcw47jgKAttCcCi5bKlAU2gWI4ji11D x2QUKV8+y1nw38EVnpkBQq7lZyyPJ7P1kK3EKhn1uIBZsgmjGCwzWj3MTUeSVAk9vIwn wPopVw3ksYbGOsRIhk1O+aI5EiugOp6zm/mCtrT6lvi5auCLT/BMlgGZSPwH68lGN6u0 NRVQ== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr6649366obb.71.1332366999327; Wed, 21 Mar 2012 14:56:39 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 14:56:38 -0700 (PDT) In-Reply-To: <4F6A45CE.6060607@raszuk.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> <4F6A45CE.6060607@raszuk.net> Date: Wed, 21 Mar 2012 17:56:38 -0400 X-Google-Sender-Auth: thMvIfBOkXawAIx0AvUdahC77nA Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:56:40 -0000 On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk wrote: > Hi Chris, > > >> In the end, I think 'bgpsec suggests' that the operator would make >> some decision... ideally the same decision across the network. > > > Such decision is inherently per prefix. So even assuming ideal case and such yes > policy like in your example would be the same across given AS how would you > see such policy to be the same across the entire path given update traverses > ? is the policy supposed to be the same across the whole of the path? does, today, 2914 have the same policy for prefix 128.2.35.0/24 as as701 as as7018 as as4134 ? The policy wrt any bgp learned (AND ANNOUNCED!) route is per-operator, 'per asn' at best. In reality there are even cases where where the policy is 'per link in an ASN'. I'm not sure why expecting this to be different in SIDR is a good thing to do. > Aren't you afraid about swiss cheese effect for end-to-end connectivity if > some ASes prefer signed and some other non signed paths ? In general, today there is no coherent policy across ASN's. EXCEPT 'make sure packets get as close to the destination as is possible for my asn to do.' I suspect that over the course of ~7-10 years BGPSEC (or similar) would rollout across enough ASN's to ensure 'good enough' security for a large portion of destinations/prefixes on the network. I hope that would be the case. I believe that, as I said before (perhaps not on sidr?) that the process looks something like (for an individual operator): 0) hear about bgpsec 1) figure out which end is up 2) upgrade code/etc to support this function after deciding it's worth your while. 3) start collecting stats on internal usage + customer usage + customer-certification-of-resources 4) action fixes to customer setup and internal setup 5) start signing your prefixes as you can 6) use metrics to judge success there's likely a few middle steps skipped there... I'm sure someone else could find other bits to add. (really jayb@att has done a lot of work on this planning...) > > What happens in your example if singed comes with PATH_SIG listing 4 ASes > (pCount=1 of each) and real AS_PATH is length of 3 ? so, pcount I'm not a fan of.... but, you're suggesting a path that's invalid? or impossible? > If you set local pref on inbound (just like shipping code allows for origin > validation) you will deliberately choose longer path as best since LOC_PREF > is checked much earlier in BGP Best path then AS_PATH length (even assuming > those would be comparable across two attributes). 'use the appropriate knob' I made an example, make it better. > Thx, you too! -chris From eosterweil@verisign.com Wed Mar 21 14:56:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1D21E8083 for ; Wed, 21 Mar 2012 14:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMw9kf0UUqDP for ; Wed, 21 Mar 2012 14:56:44 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9A21E8134 for ; Wed, 21 Mar 2012 14:56:43 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKT2pOmJgkNi5SmGzSKqVtVUZbQDSsANGa@postini.com; Wed, 21 Mar 2012 14:56:43 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2LLuZVt006982; Wed, 21 Mar 2012 17:56:40 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 17:56:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 21 Mar 2012 17:56:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <290EFAEF-DEB9-4FEE-98B1-83F35A7E573C@verisign.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Mar 2012 21:56:35.0358 (UTC) FILETIME=[7BEE8BE0:01CD07AD] Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:56:44 -0000 On Mar 21, 2012, at 5:42 PM, Shane Amante wrote: >=20 > On Mar 21, 2012, at 3:37 PM, Christopher Morrow wrote: >> On Wed, Mar 21, 2012 at 5:26 PM, Shane Amante = wrote: >>>=20 >>> On Mar 21, 2012, at 3:21 PM, Christopher Morrow wrote: >>>> On Wed, Mar 21, 2012 at 5:13 PM, Shane Amante = wrote: >>>>>=20 >>>>> On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote: >>>>>> On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil = wrote: >>>>>>> My input is that the current work that does not address the real = route leak threat, and it is therefore insufficient. >>>>>>=20 >>>>>> and many, many times ... 'how would you do this, really, show me = the >>>>>> math' has been asked. >>>>>=20 >>>>> Answer: Evaluate policy. >>>>=20 >>>> 'apply prefix lists' you mean? >>>=20 >>> No. Evaluate _policy_. Policy is about whether an ASN /intended/ = to announce a path to another ASN _or_ not. More succinctly: one needs = input to verify output, (since you said "show me the math"). >>>=20 >>=20 >> smarty... :) >>=20 >> someone reminded me that I shouldn't be quite so flip 'show me the >> math' is really, 'how can I tell from 2 as-hops away that: >>=20 >> 1 -> 2 -> 3 -> me >>=20 >> is a leak?' >>=20 >> Randy posted on nanog (to you/shane, I think) a message with content = like: >> "to do this rigorously, i >> would need to form the transitive closure of the business policies of >> every inter-provider link on the internet." >>=20 >> in this: = >> message. This is what you mean as well, yes? >=20 > Yes. And, to answer Randy's question in that message ... I'm not = asserting that this is a _simple_ problem to be solved, but we should = not ignore the problem b/c it's "hard" ... otherwise, we wouldn't have = the Internet, as it exists today, nor a lot of other things. Sorry to butt in again, but to follow that up: I'm not sure that "to do = this _rigorously_" was the right phrasing. I think in order to = "completely" model all of the Internet's BGP policies across the entire = AS topology you would need to form the transitive closure over = everything, but it would still be a rigorous exercise to model more = restricted topologies. For example, you might want to scope your = analysis: your adjacencies, or islands of security, or $n$ hops out from = a source, etc... I'm not claiming to have considered all of the relative = benefits or drawbacks of that, but it would still (imho) be a rigorous = process... Maybe it would even be useful to some... Just sayin' Eric= From dougm@nist.gov Wed Mar 21 15:03:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3621E8134 for ; Wed, 21 Mar 2012 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMYxjNYHx02k for ; Wed, 21 Mar 2012 15:03:21 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3C521E8133 for ; Wed, 21 Mar 2012 15:03:21 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 18:03:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 21 Mar 2012 17:59:36 -0400 From: "Montgomery, Douglas" To: Christopher Morrow , "robert@raszuk.net" Date: Wed, 21 Mar 2012 18:03:17 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0Hredq+1RabLl2QHKJgucdty/qeQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:03:22 -0000 On 3/21/12 5:56 PM, "Christopher Morrow" wrote: >On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk wrote: >> Hi Chris, >> >> >>> In the end, I think 'bgpsec suggests' that the operator would make >>> some decision... ideally the same decision across the network. >> >> >> Such decision is inherently per prefix. So even assuming ideal case and >>such > >yes > >> policy like in your example would be the same across given AS how would >>you >> see such policy to be the same across the entire path given update >>traverses >> ? > >is the policy supposed to be the same across the whole of the path? >does, today, 2914 have the same policy for prefix 128.2.35.0/24 as >as701 as as7018 as as4134 ? > >The policy wrt any bgp learned (AND ANNOUNCED!) route is per-operator, >'per asn' at best. In reality there are even cases where where the >policy is 'per link in an ASN'. > >I'm not sure why expecting this to be different in SIDR is a good thing >to do. > >> Aren't you afraid about swiss cheese effect for end-to-end connectivity >>if >> some ASes prefer signed and some other non signed paths ? > >In general, today there is no coherent policy across ASN's. EXCEPT >'make sure packets get as close to the destination as is possible for >my asn to do.' I suspect that over the course of ~7-10 years BGPSEC >(or similar) would rollout across enough ASN's to ensure 'good enough' >security for a large portion of destinations/prefixes on the network. >I hope that would be the case. > >I believe that, as I said before (perhaps not on sidr?) that the >process looks something like (for an individual operator): > 0) hear about bgpsec > 1) figure out which end is up > 2) upgrade code/etc to support this function after deciding it's >worth your while. > 3) start collecting stats on internal usage + customer usage + >customer-certification-of-resources > 4) action fixes to customer setup and internal setup > 5) start signing your prefixes as you can > 6) use metrics to judge success > >there's likely a few middle steps skipped there... I'm sure someone >else could find other bits to add. > >(really jayb@att has done a lot of work on this planning...) > >> >> What happens in your example if singed comes with PATH_SIG listing 4 >>ASes >> (pCount=1 of each) and real AS_PATH is length of 3 ? > >so, pcount I'm not a fan of.... but, you're suggesting a path that's >invalid? or impossible? In the current BGPSEC spec, there is only a PATH_SIG element (with AS hops encoded within), so this specific scenario could not occur. But even if the protocol carried both fields, I think the basic design of the protocol would label the AS_PATH "Invalid" under the simple primise that the SIG data does not validate the AS_PATH data (no matter where/how it is encoded). What your local policy does with that "Invalid" label, is up to you. Dougm From robert@raszuk.net Wed Mar 21 15:05:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB46221F8713 for ; Wed, 21 Mar 2012 15:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCUPQln4WKT5 for ; Wed, 21 Mar 2012 15:05:06 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8742921F8715 for ; Wed, 21 Mar 2012 15:05:05 -0700 (PDT) Received: (qmail 27132 invoked by uid 399); 21 Mar 2012 22:05:05 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.67) by mail1310.opentransfer.com with ESMTPM; 21 Mar 2012 22:05:05 -0000 X-Originating-IP: 83.9.123.67 Message-ID: <4F6A5093.8040004@raszuk.net> Date: Wed, 21 Mar 2012 23:05:07 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> <4F6A45CE.6060607@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:05:08 -0000 >> > What happens in your example if singed comes with PATH_SIG listing 4 ASes >> > (pCount=1 of each) and real AS_PATH is length of 3 ? > > so, pcount I'm not a fan of.... but, you're suggesting a path that's > invalid? or impossible? Worse .. in my example both paths are valid, crystal clear and pass all validations one can apply. >> > If you set local pref on inbound (just like shipping code allows for origin >> > validation) you will deliberately choose longer path as best since LOC_PREF >> > is checked much earlier in BGP Best path then AS_PATH length (even assuming >> > those would be comparable across two attributes). > > 'use the appropriate knob' I made an example, make it better. It is not the question of knob. It is a question of expected behaviour. Thx, R. From christopher.morrow@gmail.com Wed Mar 21 15:22:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF821E8015 for ; Wed, 21 Mar 2012 15:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZXZJGXpX5lq for ; Wed, 21 Mar 2012 15:22:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAD821E813D for ; Wed, 21 Mar 2012 15:22:18 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1146438obb.31 for ; Wed, 21 Mar 2012 15:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rlHRsfyz52DLkbSsrKjYeU06zQePtl7gRZFicq2XIp4=; b=mwm5lo+WaZgjrlQUb/7/5kjdHxrcjYk7Q0ydk31BtqSgqrTua00aeFy2hG69pCcur8 Eez1cOQmeeaNFYbkt6sO+AELKTw2cBNUYt8cy29R1q7SnQGaZYI4/9QR7iqKmqxdXYN5 f/1xEnA0lJdzggtJPjodLIRFMtdUqTg0PFPQIgLAL7/wnI+mRRAS9OKXfvUTBVx7ia7n 9uDslL3ngWkB5Jxb+aLM5EZsyYWDR4R4vu2zkIcmrvGzvKjfy++5XEyxqPJ8FlajASLS 9dmW/K3AogsIQhlDD3amBy37GpJyQ4AH2Ni2yNqMiulRESTKz8dACghCZVEtgRil4/ei 0PSw== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr6849313obv.41.1332368538271; Wed, 21 Mar 2012 15:22:18 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 21 Mar 2012 15:22:17 -0700 (PDT) In-Reply-To: <5C321BE3-F8E0-4206-B057-B2D534088420@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <80D4969F-05AA-480B-A472-222A8376B362@verisign.com> <7A879B42-29A3-4C99-8F91-B774EEF56B40@verisign.com> <13DAFF92-94E7-4FFB-A1C3-7F1F93BD2E0F@verisign.com> <5C321BE3-F8E0-4206-B057-B2D534088420@verisign.com> Date: Wed, 21 Mar 2012 18:22:17 -0400 X-Google-Sender-Auth: _4hU1cUzI_1x3dNcWnt2W3jLTlE Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:22:20 -0000 On Wed, Mar 21, 2012 at 5:17 PM, Eric Osterweil w= rote: > Hey Chris, > > On Mar 21, 2012, at 5:06 PM, Christopher Morrow wrote: > >> On Wed, Mar 21, 2012 at 5:04 PM, Eric Osterweil wrote: >>> >>> On Mar 21, 2012, at 4:57 PM, Christopher Morrow wrote: >>> >>>> On Wed, Mar 21, 2012 at 3:19 PM, Eric Osterweil wrote: >>>> >>>>> How about we turn this around with a simple question: >>>>> Suppose two different feasible paths are being evaluated for a single= prefix/origin pair and one was delivered via a signed bgpsec update, and t= he other was delivered via an unsigned update. =A0What annotations/influenc= ers/considerations/etc. does the bgpsec design suggest when the router is m= aking its path selection between these two? >>>>> >>>> >>>> ideall, I think, the process is something like: >>>> =A01) first path gets evaluated, is it 'good' (next-hop reachable, not >>>> discarded by prefix-list/etc) >>>> =A02) second path gets evaluated, is it 'good' (same as above + >>>> origin-validate + path-validation) >>>> >>>> If both 1 and 2 come out 'ok', assume each path was received from a >>>> different peer on the same device: >>>> =A01) 1 - 2 - 701 - you >>>> =A02) 1 - 3 - 7018 - you >>>> >>>> If you decide that your network's policy is 'prefer signed and valid >>>> over unsigned' paths, you'd pick #2. It could be that your method of >>>> doing this is saying: >>>> =A0route-map inbound-bgp permit 10 >>>> =A0 =A0if route-signed and verified >>>> =A0 =A0set localpref 100 >>>> >>>> Which ideally would let localpref on the #1 route stay normal =3D=3D 8= 0 >>>> and magically you'd just use the 'right' (from your perspective) path. >>>> (signed and verified). >>>> >>>> of course, in the beginning of this you may choose a more conservative= : >>>> =A0 route-map inbound-bgp permit 10 >>>> =A0 =A0 =A0if route-signed and verified >>>> =A0 =A0 =A0 =A0set community you:verified >>>> >>>> so you could measure the deployment state of your customers + rest-o-i= nterwebs. >>>> >>>> In the end, I think 'bgpsec suggests' that the operator would make >>>> some decision... ideally the same decision across the network. >>>> >>>> does that make sense? (the policy is deliberately short and simple, >>>> obviously real policy is longer/stranger, but the end result is the >>>> same) >>> >>> Indeed, this makes sense, thanks for the detailed response. =A0However,= this also illustrates an evolution of semantics under non-attack circumsta= nces. :) >> >> expand please. > > > Sure, there is now a new element in the BGP update (the sig(s)) whose pre= sence, nature, or absence causes the interpretation of the update to differ= . =A0While I still disagree with the earlier caveat that all bets are off d= uring an attack, that statement clearly does cover this case where one upda= te simply isn't signed. =A0That's what I meant, though I didn't mean to be = cavalier when I said it before... Sorry if it came off as a barb. :) > I didn't take it as a barb:) you seemed to have in mind a problem, you showed it above as well, i was curious what the problem was. You highlight a problem that, of course, looks to me like a dnssec sort of thing? "Hey, this domain is supposed to have sigs, it didn't?" I think in this case you could change the simple example above as: 1) unsigned path, everything 'ok' 2) unsigned path, everything 'ok' except there is a prefix with ROA data and no sigs is that right? From shane@castlepoint.net Wed Mar 21 15:27:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831A21E80F1 for ; Wed, 21 Mar 2012 15:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtvbIlBalQWn for ; Wed, 21 Mar 2012 15:27:24 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 259BA21E804E for ; Wed, 21 Mar 2012 15:27:16 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D8028268063; Wed, 21 Mar 2012 16:27:15 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 21 Mar 2012 16:27:15 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=60673; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 21 Mar 2012 16:27:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5E082E6A-3008-47BE-8830-4A88CFA08FA3@castlepoint.net> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1257) Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:27:25 -0000 On Mar 21, 2012, at 3:47 PM, Randy Bush wrote: >>> in this: >>> >>> message. This is what you mean as well, yes? >> Yes. And, to answer Randy's question in that message ... I'm not >> asserting that this is a _simple_ problem to be solved, but we should >> not ignore the problem b/c it's "hard" ... otherwise, we wouldn't = have >> the Internet, as it exists today, nor a lot of other things. >=20 > actually, there is a solution to that problem. it's called bgp. No, it's not. Today, BGP is a mechanism that was strictly designed for = distributing reachability information . Any change = in that is a fundamental change to the way the BGP protocol is operated, = currently. > bgpsec > is an attempt to protect that solution from some demonstrated attacks. ... which have not been enumerated, in detail, in any SIDR WG drafts. = As I look at = there is = /a lot/ of discussion around threats posed to everything surrounding = BGPSEC & the RPKI, but no substance to at least the one "headline" = threat that BGPSEC is supposedly designed to mitigate against, the = so-called "Pilosov/Kapela" attack. Heck, there's not even a _link_ or = _reference_ in the threats document to the Pilosov/Kapela attack. I = can't even find one in = either. Heck, if even the attacks you allude to are not enumerated (in detail), = then IMHO there are much bigger problems here ... > if you have another solution, do tell us. but ranting that world = hunger > should be solved does not feed anyone. -shane= From brian.peter.dickson@gmail.com Wed Mar 21 15:33:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017DB21E80DE for ; Wed, 21 Mar 2012 15:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYqQGPULKCS7 for ; Wed, 21 Mar 2012 15:33:36 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B790921E8051 for ; Wed, 21 Mar 2012 15:33:35 -0700 (PDT) Received: by werb10 with SMTP id b10so1596360wer.31 for ; Wed, 21 Mar 2012 15:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNsJcmVOeZvTgOqZ16UTv8aor9UBPM+aJ1Z1NGxdql8=; b=MVuZa32spLUlqn/wV1yStVeZj+bxtBLSjRjfXjzhXvpU4bdNc+O9eOqM5LTHyXYGhy yKHGtn2UU89xbr3iUI/w21oukGESehxjL1xBSF9a3MJYGzsS1Z0w7HZAy1gKlFIkvjw3 EkSMp2iqKUmtW5VU7JiTT2pSOTwZr9zDdj0qI49jAE1r6oUYLWtV+NFnbj17qnLnxLTY 3iqp6c70Tmmwf5tQjm0xTpb11KVtBUr3lwzcjk3w8Pif7yZGuRNKnuCgbXeTrexRlmSh QPui8WJPUs3Z7ZYZRzUh8SPkLVsJBPLOLMusd2hiULH+UQDiTB+hVAU19I2FDNaaPStN V5gA== MIME-Version: 1.0 Received: by 10.180.107.101 with SMTP id hb5mr14959051wib.3.1332369214938; Wed, 21 Mar 2012 15:33:34 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 21 Mar 2012 15:33:34 -0700 (PDT) In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> Date: Wed, 21 Mar 2012 18:33:34 -0400 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: multipart/alternative; boundary=e89a8f3bb0cfc41cf304bbc86125 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:33:37 -0000 --e89a8f3bb0cfc41cf304bbc86125 Content-Type: text/plain; charset=ISO-8859-1 The drafts (three of them, together) are an attempt to define, constrain, and solve the problem. Yes, it is tricky and difficult. I'm not saying that the solutions (two of them to choose from) are the only way to do it. But, I believe that either of them actually solves the problem. In a nutshell, here's how it works: Mark the path "intent" in one of two ways (customer or non-customer), (based on mutual agreement between adjacent peers) Incorporate some kind of mechanism to detect/prevent fudging (a la bgpsec sig) Apply a simple set of rules based on route color vs peering "type", plus "v-free" type logic. Everything is in-band, and the transitive closure _is_ the transitive closure. ASCII art is not adequate for presenting complex ideas, IMHO. I will attempt to provide a richer presentation for Paris. Please, if anyone is interested, for the love of $deity, read the drafts and provide feedback. Thanks, Brian On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush wrote: > >>> Answer: Evaluate policy. > >> 'apply prefix lists' you mean? > > No. Evaluate _policy_. Policy is about whether an ASN /intended/ to > > announce a path to another ASN _or_ not. More succinctly: one needs > > input to verify output, (since you said "show me the math"). > > From: Randy Bush > Subject: Re: do not filter your customers > To: Shane Amante > Cc: North American Network Operators' Group > Date: Sat, 25 Feb 2012 15:22:35 +0530 > > > as would be solving world hunger, war, bad cooking, especially bad > > cooking. > > > > route leaks, as much as i understand them > > o are indeed bad ops issues > > o are not security per se > > o are a violation of business relationshiops > > o and 20 years of fighting them have not given us any significant > > increase in understanding, formal definition, or prevention. > > let me try to express how i see the problem. to do this rigorously, i > would need to form the transitive closure of the business policies of > every inter-provider link on the internet. > > why i say it is per-link and not just inter-as (which would be hard > enough) is that i know a *lot* of examples where two ass have different > business policies on different links. [ i'll exchange se asian routes > with you in hong kong, but only sell you transit in tokyo. we have two > links in frankfurt, one local peering and one international transit. ] > > it is not just one-hop because telstra was 'supposed to' pass some > customers' customers' routes to optus. > > i find this daunting. but i would *really* like to be able to > rigorously solve it. please please please explain to me how it is > simpler than this. > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --e89a8f3bb0cfc41cf304bbc86125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The drafts (three of them, together) are an attempt to define, constrain, a= nd solve the problem.

    Yes, it is tricky and difficult. I'm not s= aying that the solutions (two of them to choose from) are the only way to d= o it.
    But, I believe that either of them actually solves the problem.

    In a= nutshell, here's how it works:
    Mark the path "intent" in = one of two ways (customer or non-customer), (based on mutual agreement betw= een adjacent peers)
    Incorporate some kind of mechanism to detect/prevent fudging (a la bgpsec s= ig)
    Apply a simple set of rules based on route color vs peering "ty= pe", plus "v-free" type logic.

    Everything is in-band,= and the transitive closure _is_ the transitive closure.

    ASCII art is not adequate for presenting complex ideas, IMHO. I will at= tempt to provide a richer presentation for Paris.

    Please, if anyone = is interested, for the love of $deity, read the drafts and provide feedback= .

    Thanks,
    Brian

    On Wed, Mar 21, 2012= at 5:37 PM, Randy Bush <randy@psg.com> wrote:
    >>> Answer: Evaluate policy.
    >> 'apply prefix lists' you mean?
    > No. =A0Evaluate _policy_. =A0Policy is about whether an ASN /intended/= to
    > announce a path to another ASN _or_ not. =A0More succinctly: one needs=
    > input to verify output, (since you said "show me the math").=

    From: Randy Bush <randy@psg.com>
    Subject: Re: do not filter your customers
    To: Shane Amante <    shane@castlep= oint.net>
    Cc: North American Network Operators' Group <nanog@nanog.org>
    Date: Sat, 25 Feb 2012 15:22:35 +0530

    > as would be solving world hunger, war, bad cooking, especially bad
    > cooking.
    >
    > route leaks, as much as i understand them
    > =A0o are indeed bad ops issues
    > =A0o are not security per se
    > =A0o are a violation of business relationshiops
    > =A0o and 20 years of fighting them have not given us any significant > =A0 =A0increase in understanding, formal definition, or prevention.
    let me try to express how i see the problem. =A0to do this rigorously, i
    would need to form the transitive closure of the business= policies of
    every inter-provider link on the internet.

    why i say it is per-link and not just inter-as (which would be hard enough) is that i know a *lot* of examples where two ass have different
    business policies on different links. =A0[ i'll exchange se asian route= s
    with you in hong kong, but only sell you transit in tokyo. =A0we have two links in frankfurt, one local peering and one international transit. ]

    it is not just one-hop because telstra was 'supposed to' pass some<= br> customers' customers' routes to optus.

    i find this daunting. =A0but i would *really* like to be able to
    rigorously solve it. =A0please please please explain to me how it is
    simpler than this.

    randy

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

    --e89a8f3bb0cfc41cf304bbc86125-- From dougm@nist.gov Wed Mar 21 15:34:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406421E8051 for ; Wed, 21 Mar 2012 15:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIvI6n2Cc-3F for ; Wed, 21 Mar 2012 15:34:55 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9168F21F8661 for ; Wed, 21 Mar 2012 15:34:55 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 18:34:49 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 21 Mar 2012 18:34:54 -0400 From: "Montgomery, Douglas" To: "robert@raszuk.net" , Christopher Morrow Date: Wed, 21 Mar 2012 18:34:51 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0HslAyA/v+mgqKS3+6pZF4pbgfJA== Message-ID: In-Reply-To: <4F6A5093.8040004@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:34:56 -0000 On 3/21/12 6:05 PM, "Robert Raszuk" wrote: > >>> > What happens in your example if singed comes with PATH_SIG listing >>>4 ASes >>> > (pCount=1 of each) and real AS_PATH is length of 3 ? > > >> so, pcount I'm not a fan of.... but, you're suggesting a path that's >> invalid? or impossible? > >Worse .. in my example both paths are valid, crystal clear and pass all >validations one can apply. If you are talking about BGPSEC as currently proposed, this can't happen. The definition of validity of a PATH_SIG is that valid signatures exactly correspond to AS_PATH data. See: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1 Once again, given the encoding of AS_PATH directly in PATH_SIG attribute, the exact scenario is moot (a BGPSEC update will never contain both AS_PATH and PATH_SIG attributes), but the spirit is the same, the validation algorithm will return "Invalid" Dougm From randy@psg.com Wed Mar 21 15:58:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF0B21F8562 for ; Wed, 21 Mar 2012 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmIIxyipIIht for ; Wed, 21 Mar 2012 15:58:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BEFA021F8512 for ; Wed, 21 Mar 2012 15:58:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAUUa-000Odp-1t; Wed, 21 Mar 2012 22:58:56 +0000 Date: Wed, 21 Mar 2012 23:58:54 +0100 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:58:58 -0000 brian, i scanned some time ago and am reading (trying to get other work done too). i think you are too good a typist:) i think your ideas could be reduced to a page. this is a feature, not a bug. but i think you are on a constructive path as opposed to screaming that someone else should solve it for you. [ of course i worry that not all relationships are customer/provider or peer/peer. the droids are amazingly inventive. but let's leave that aside for a while. ] i wonder if i have the prerogative to enforce a business relationship violation that is three hops from me when the op two hops from me chose not to do so. i am still trying to wrap my head around these aspects. but i do agree that, if we get your semantics nailed down simply and well understood, we would want to sign the signals. downright have to. randy From robert@raszuk.net Wed Mar 21 16:11:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575F821E8049 for ; Wed, 21 Mar 2012 16:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-1uOq-mg1uN for ; Wed, 21 Mar 2012 16:11:51 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C921E8087 for ; Wed, 21 Mar 2012 16:11:50 -0700 (PDT) Received: (qmail 18142 invoked by uid 399); 21 Mar 2012 23:11:50 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.67) by mail1310.opentransfer.com with ESMTPM; 21 Mar 2012 23:11:50 -0000 X-Originating-IP: 83.9.123.67 Message-ID: <4F6A6038.3070404@raszuk.net> Date: Thu, 22 Mar 2012 00:11:52 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:11:52 -0000 Maybe there is misunderstanding ... Chris example was stating: 1) first path gets evaluated, is it 'good' (next-hop reachable, not discarded by prefix-list/etc) 2) second path gets evaluated, is it 'good' (same as above + origin-validate + path-validation) One path comes without signature the other one with signature .. AS PATHs they traverse is disjoined at some point. Are you saying this can not happen ? Many thx, R. > On 3/21/12 6:05 PM, "Robert Raszuk" wrote: > >> >>>>> What happens in your example if singed comes with PATH_SIG listing >>>> 4 ASes >>>>> (pCount=1 of each) and real AS_PATH is length of 3 ? >>> >>> so, pcount I'm not a fan of.... but, you're suggesting a path that's >>> invalid? or impossible? >> >> Worse .. in my example both paths are valid, crystal clear and pass all >> validations one can apply. > > If you are talking about BGPSEC as currently proposed, this can't happen. > The definition of validity of a PATH_SIG is that valid signatures exactly > correspond to AS_PATH data. > > See: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1 > > Once again, given the encoding of AS_PATH directly in PATH_SIG attribute, > the exact scenario is moot (a BGPSEC update will never contain both > AS_PATH and PATH_SIG attributes), but the spirit is the same, the > validation algorithm will return "Invalid" > > Dougm > > > From wesley.george@twcable.com Thu Mar 22 06:44:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947F721F863D for ; Thu, 22 Mar 2012 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-MIQeKvW3xW for ; Thu, 22 Mar 2012 06:44:24 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A291D21F862A for ; Thu, 22 Mar 2012 06:44:24 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,630,1325480400"; d="scan'208";a="357302205" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Mar 2012 09:42:50 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 22 Mar 2012 09:43:36 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Thu, 22 Mar 2012 09:43:35 -0400 Thread-Topic: [sidr] SIDR Interim 24/March is CANCELLED Thread-Index: Ac0Hhr4RJ7KoxaClTIK9avdQzQvOSwAGhISA Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:44:25 -0000 I'm sorry to harp on this Sandy, and I appreciate your apology, but frankly= I think this communications breakdown is far larger than whether you accid= entally missed a bit of the letter of the law on scheduling process because= of timezones and missed email addresses, so I want to make sure that what = I believe to be the real problem is addressed. How is it that these interim meetings have been scheduled without solicitin= g the WG for acceptable dates PRIOR to setting the date? How did you determine that an(other) interim was necessary and the appropri= ateness of the date chosen? I gather that consensus to hold an interim or w= hen/where it is held is not strictly required[*], but it seems odd to me th= at the WG list wouldn't be involved in the discussion until the mandatory n= otification deadline. In fairness to the chairs, the NANOG interim's timing and location were mor= e self-explanatory, which is why I didn't bring this up before. Also, I sho= uld have posted about my travel schedule conflict as soon as I saw the 3/7 = announcement, but that announcement was an invite to a webex session, imply= ing at least to me that things were already scheduled, rather than soliciti= ng feedback regarding the date, so I let it go until I saw others raising q= uestions about the scheduling. So while we're making notes for next time, I believe that this process shou= ld start with "dear WG, an interim meeting has been requested to discuss $t= opic(s). Here are some candidate dates [and locations]. Please respond with= feedback." This obviously has to happen well enough prior to the candidate dates to en= sure that you have the proper time to work through the process, so if 4 wee= ks notification are necessary, that discussion probably has to start at 6 w= eeks out. * From http://www.ietf.org/iesg/statement/interim-meetings.html : "Area Directors will advise the Working Group Chair on interim face-to-face= meeting location, timing, and other aspects of the proposed meeting that w= ith a goal of not unfairly favoring some subset of the potential participan= ts or not unfairly biasing the working group discussions. Working Group Cha= irs will evaluate the proposed conference call or jabber session logistics = for similar fairness concerns, consulting with Area Directors as necessary = to resolve any concerns raised by potential participants." I'm wondering if perhaps the above needs to be amended to recommend/require= discussion on the WG list? Anyone have opinions on that? Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Wednesday, March 21, 2012 1:38 PM > To: sidr@ietf.org > Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED > > In the flurry of apologetic emails that preceeded and followed this > announcement, I did not apolgize to the working group. > > This was my strictly my bungle, in two different directions. > > First, I announced the meeting to the sidr mailing list within the time f= rame > required by process. The bungle was that I did not copy the iesg-secreta= ry as > I MEANT to do and I KNEW is required by process. I noticed this myself t= he > next week, but too late to meet the required deadline. I informed the ie= sg- > secretary. They sent the announcement and complaints of process violatio= n > came in immediately. > > Second, I announced the agenda as is required by process one week ahead o= f > time, by my local time zone. However, due to the time of day and time zo= ne > differences, it was reckoned the next day in other time zones. > > --Sandy, the apologetic wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From dougm@nist.gov Thu Mar 22 06:48:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA68821F863D for ; Thu, 22 Mar 2012 06:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwZ+ybrTqDBb for ; Thu, 22 Mar 2012 06:48:42 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E7BA121F862A for ; Thu, 22 Mar 2012 06:48:41 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 22 Mar 2012 09:48:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 22 Mar 2012 09:44:54 -0400 From: "Montgomery, Douglas" To: "robert@raszuk.net" Date: Thu, 22 Mar 2012 09:48:09 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0IMfY+a/wHtghYRkqMu/VAYll4EQ== Message-ID: In-Reply-To: <4F6A6038.3070404@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:48:42 -0000 Sorry, my bad. I somehow thought you were talking about two different PATH elements in the same update. That assumption made your questions sound bizarre. I am sure my misunderstanding made my answers sound equally bizarre. So, yes if they are different updates for the same prefix received from different peers ... Then of course this will happen all the time. As for if you somehow prefer the signed path over the unsigned path, in the end that is a local decision. I think there is/will be strong wording that one SHOULD choose the signed and valid path because at the moment there is no explicit way of distinguishing that a path should have been signed, and as a result, there is a simple downgrade attack to strip the PATHSIG, if one is not strictly preferring signed over unsigned paths. One could think of fixing this, by having AS's push and object in the RPKI that says "I am signing my paths", then it would be possible to detect the simple downgrade attack. I guess one might think of AS_CERTS as such a signal, but that is a bit problematic WRT timing issues. The right way to do it would be some other explicit object. Anyway, to answer your question below, one SHOULD choose the second path, but I doubt the specs will ever say you MUST choose the second path. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 7:11 PM, "Robert Raszuk" wrote: > >Maybe there is misunderstanding ... > >Chris example was stating: > > 1) first path gets evaluated, is it 'good' (next-hop reachable, not >discarded by prefix-list/etc) > > 2) second path gets evaluated, is it 'good' (same as above + >origin-validate + path-validation) > >One path comes without signature the other one with signature .. AS >PATHs they traverse is disjoined at some point. > >Are you saying this can not happen ? > >Many thx, >R. > > >> On 3/21/12 6:05 PM, "Robert Raszuk" wrote: >> >>> >>>>>> What happens in your example if singed comes with PATH_SIG listing >>>>> 4 ASes >>>>>> (pCount=3D1 of each) and real AS_PATH is length of 3 ? >>>> >>>> so, pcount I'm not a fan of.... but, you're suggesting a path that's >>>> invalid? or impossible? >>> >>> Worse .. in my example both paths are valid, crystal clear and pass all >>> validations one can apply. >> >> If you are talking about BGPSEC as currently proposed, this can't >>happen. >> The definition of validity of a PATH_SIG is that valid signatures >>exactly >> correspond to AS_PATH data. >> >> See: >>=20 >>http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1 >> >> Once again, given the encoding of AS_PATH directly in PATH_SIG >>attribute, >> the exact scenario is moot (a BGPSEC update will never contain both >> AS_PATH and PATH_SIG attributes), but the spirit is the same, the >> validation algorithm will return "Invalid" >> >> Dougm >> >> >> > From Sandra.Murphy@sparta.com Thu Mar 22 07:57:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46121F865B for ; Thu, 22 Mar 2012 07:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enmqQO0fNocS for ; Thu, 22 Mar 2012 07:57:13 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 429E521F864F for ; Thu, 22 Mar 2012 07:57:12 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2MEvB9s006997 for ; Thu, 22 Mar 2012 09:57:11 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2MEv7N9019478 for ; Thu, 22 Mar 2012 09:57:10 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 10:57:07 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0BHstYc0RqXyk/RyedShZeul09IAA3lj8wAA1+0AD//8zZTYAAY4eAgAF9xveACDszAIAAuGAAgAADEwCAAB6FAIAAA/SAgAAlXc+AAELcgIAAAwEAgACZKmA= Date: Thu, 22 Mar 2012 14:57:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:57:14 -0000 This has become a long and tortuous rat hole, leading off into branching ra= t holes.=0A= =0A= It all started with prospective text to the idr wg about the route leaks pr= oblem.=0A= =0A= The furor started over the suggested text's stated motivation for asking.= =0A= =0A= But there have been no objections to conferring with idr and some expressio= ns of agreement.=0A= =0A= So can we go just please discuss what the message to idr should say?=0A= =0A= How about something along the lines of:=0A= =0A= There is agreement that route leaks is a problem.=0A= There is agreement that a change to bgp might provide a solution, but conce= rn about sidr undertaking the solution without idr participation.=0A= Would the idr be willing to work with sidr in (a) defining the route leaks = problem, (b) devising a solution and (c) securing that solution? =0A= The actual home for the work (idr, sidr, both, something else) would be dis= cussed.=0A= =0A= --Sandy=0A= =0A= --Sandy, speaking as wg co-chair=0A= From christopher.morrow@gmail.com Thu Mar 22 08:00:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB54121F85EA for ; Thu, 22 Mar 2012 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npk19vl0+dAD for ; Thu, 22 Mar 2012 08:00:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5921F850B for ; Thu, 22 Mar 2012 08:00:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2033701ghb.31 for ; Thu, 22 Mar 2012 08:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=76dCI/ffZXZWTUi6uDIEaFusMctLjgFCwuf+C6Rbk4s=; b=vfz6hyymyNgZ/xRkAOe/8XjqKNaXGcmoCke1pAT5jhfij+ycL8vVWTbQC1LOMdJGJm SEGudDE5W2S4pC/3rWScdORvpei/zoiZgpHSSueT9A4XM9+6R1ShwMRN0dpMY234MtP2 Xsb/PFKgJbj6Orz1F3vIsyYJk6pI3Etgwta31lK8CsIXlqoWNVfB0zFTTTyoIxOLXt9K sflwR4y2dKXm9RCPzWZ9FGosjGiH8rKujqFatJRb9HsFUL9RpLLrJw/vyrY+LbeuTHWz hJI+u213GahE2UQQgvdZoj/+IMAHnalEgL8Wwxpjje765PjspgoKK1cYI2TfT0qSiKQc 3/8g== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr9940709oei.71.1332428403441; Thu, 22 Mar 2012 08:00:03 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 22 Mar 2012 08:00:03 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> Date: Thu, 22 Mar 2012 11:00:03 -0400 X-Google-Sender-Auth: xR7mDtiJCP2rKMRqltjMb2Xxj28 Message-ID: From: Christopher Morrow To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:00:05 -0000 On Thu, Mar 22, 2012 at 10:57 AM, Murphy, Sandra wrote: > This has become a long and tortuous rat hole, leading off into branching rat holes. > > It all started with prospective text to the idr wg about the route leaks problem. > > The furor started over the suggested text's stated motivation for asking. > > But there have been no objections to conferring with idr and some expressions of agreement. > > So can we go just please discuss what the message to idr should say? > > How about something along the lines of: > > There is agreement that route leaks is a problem. > There is agreement that a change to bgp might provide a solution, but concern about sidr undertaking the solution without idr participation. > Would the idr be willing to work with sidr in (a) defining the route leaks problem, (b) devising a solution and (c) securing that solution? > The actual home for the work (idr, sidr, both, something else) would be discussed. sounds good to me. -chris > --Sandy > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From jayb@braeburn.org Thu Mar 22 08:03:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D721F8546 for ; Thu, 22 Mar 2012 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyYtrnBjtKAh for ; Thu, 22 Mar 2012 08:03:06 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1A21F865B for ; Thu, 22 Mar 2012 08:03:06 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 92f3b6f4.0.1379632.00-486.3794369.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 22 Mar 2012 15:03:06 +0000 (UTC) X-MXL-Hash: 4f6b3f2a26cafcc8-01fa83d7104a5425c05a2a80819f5140a35dd4f8 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MF35jR024075 for ; Thu, 22 Mar 2012 11:03:05 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MF31tc024032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Mar 2012 11:03:01 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Thu, 22 Mar 2012 11:02:40 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MF2dHN029915 for ; Thu, 22 Mar 2012 11:02:39 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MF2ZLC029606 for ; Thu, 22 Mar 2012 11:02:35 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id 050632BF2C; Thu, 22 Mar 2012 11:02:34 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20331.16137.916745.831768@oz.mt.att.com> Date: Thu, 22 Mar 2012 11:02:33 -0400 From: Jay Borkenhagen To: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:03:07 -0000 +1 Murphy, Sandra writes: > This has become a long and tortuous rat hole, leading off into branching rat holes. > > It all started with prospective text to the idr wg about the route leaks problem. > > The furor started over the suggested text's stated motivation for asking. > > But there have been no objections to conferring with idr and some expressions of agreement. > > So can we go just please discuss what the message to idr should say? > > How about something along the lines of: > > There is agreement that route leaks is a problem. > There is agreement that a change to bgp might provide a solution, but concern about sidr undertaking the solution without idr participation. > Would the idr be willing to work with sidr in (a) defining the route leaks problem, (b) devising a solution and (c) securing that solution? > The actual home for the work (idr, sidr, both, something else) would be discussed. > > --Sandy > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From jayb@braeburn.org Thu Mar 22 08:27:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E3021F854B for ; Thu, 22 Mar 2012 08:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CgKt8r0kjuH for ; Thu, 22 Mar 2012 08:27:49 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAD21F85C6 for ; Thu, 22 Mar 2012 08:27:48 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4f44b6f4.0.1392673.00-282.3830523.nbfkord-smmo04.seg.att.com (envelope-from ); Thu, 22 Mar 2012 15:27:48 +0000 (UTC) X-MXL-Hash: 4f6b44f403b179fa-d87a2c3722f44698d6a80411ad74b99e7fbaa49e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MFRm41014059 for ; Thu, 22 Mar 2012 11:27:48 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MFRhof013980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Mar 2012 11:27:45 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 22 Mar 2012 11:27:27 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MFRRdA021644 for ; Thu, 22 Mar 2012 11:27:27 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MFRND2021495 for ; Thu, 22 Mar 2012 11:27:23 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id DBA702BF2C; Thu, 22 Mar 2012 11:27:22 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <20331.17624.719267.83969@oz.mt.att.com> Date: Thu, 22 Mar 2012 11:27:20 -0400 From: Jay Borkenhagen To: Brian Dickson In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:27:50 -0000 I am aware of a number of ebgp relationships where the two parties disagree on the nature of their connections:=20 - the first party believes the second is a transit customer - the second party believe the first is a peer Today the two parties agree to disagree, and yet the proper routing works.=20 I am also aware of a number of intricate routing policies, along the lines of in-country transit, per-continent peer, world-wide customer. =20= I'm afraid these kinds of things could make it tricky or even impossible to categorize links in black-and-white terms as is done in these leaks drafts. Brian Dickson writes: > The drafts (three of them, together) are an attempt to define, const= rain, > and solve the problem. >=20 > Yes, it is tricky and difficult. I'm not saying that the solutions (= two of > them to choose from) are the only way to do it. > But, I believe that either of them actually solves the problem. >=20 > In a nutshell, here's how it works: > Mark the path "intent" in one of two ways (customer or non-customer)= , > (based on mutual agreement between adjacent peers) > Incorporate some kind of mechanism to detect/prevent fudging (a la b= gpsec > sig) > Apply a simple set of rules based on route color vs peering "type", = plus > "v-free" type logic. >=20 > Everything is in-band, and the transitive closure =5Fis=5F the trans= itive > closure. >=20 > ASCII art is not adequate for presenting complex ideas, IMHO. I will= > attempt to provide a richer presentation for Paris. >=20 > Please, if anyone is interested, for the love of $deity, read the dr= afts > and provide feedback. >=20 > Thanks, > Brian >=20 > On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush wrote: >=20 > > >>> Answer: Evaluate policy. > > >> 'apply prefix lists' you mean=3F > > > No. Evaluate =5Fpolicy=5F. Policy is about whether an ASN /int= ended/ to > > > announce a path to another ASN =5For=5F not. More succinctly: o= ne needs > > > input to verify output, (since you said "show me the math"). > > > > From: Randy Bush > > Subject: Re: do not filter your customers > > To: Shane Amante > > Cc: North American Network Operators' Group > > Date: Sat, 25 Feb 2012 15:22:35 +0530 > > > > > as would be solving world hunger, war, bad cooking, especially b= ad > > > cooking. > > > > > > route leaks, as much as i understand them > > > o are indeed bad ops issues > > > o are not security per se > > > o are a violation of business relationshiops > > > o and 20 years of fighting them have not given us any significa= nt > > > increase in understanding, formal definition, or prevention. > > > > let me try to express how i see the problem. to do this rigorousl= y, i > > would need to form the transitive closure of the business policies= of > > every inter-provider link on the internet. > > > > why i say it is per-link and not just inter-as (which would be har= d > > enough) is that i know a *lot* of examples where two ass have diff= erent > > business policies on different links. [ i'll exchange se asian ro= utes > > with you in hong kong, but only sell you transit in tokyo. we hav= e two > > links in frankfurt, one local peering and one international transi= t. ] > > > > it is not just one-hop because telstra was 'supposed to' pass some= > > customers' customers' routes to optus. > > > > i find this daunting. but i would *really* like to be able to > > rigorously solve it. please please please explain to me how it is= > > simpler than this. > > > > randy > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > > The drafts (three of them, together) are an attempt to define, const= rain, and solve the problem.

    Yes, it is tricky and difficult. I&= #39;m not saying that the solutions (two of them to choose from) are th= e only way to do it.
    > But, I believe that either of them actually solves the problem.
    <= br>In a nutshell, here's how it works:
    Mark the path "inten= t" in one of two ways (customer or non-customer), (based on mutual= agreement between adjacent peers)
    > Incorporate some kind of mechanism to detect/prevent fudging (a la b= gpsec sig)
    Apply a simple set of rules based on route color vs peeri= ng "type", plus "v-free" type logic.

    Everyth= ing is in-band, and the transitive closure =5Fis=5F the transitive clos= ure.
    >
    ASCII art is not adequate for presenting complex ideas, IMHO. I = will attempt to provide a richer presentation for Paris.

    Please,= if anyone is interested, for the love of $deity, read the drafts and p= rovide feedback.
    >
    Thanks,
    Brian

    On Wed, Mar= 21, 2012 at 5:37 PM, Randy Bush <randy@psg.com> wrote:
    >
    >>> Answer: Evaluate policy.
    > >> 'apply prefix lists' you mean=3F
    > > No. =A0Evaluate =5Fpolicy=5F. =A0Policy is about whether an ASN= /intended/ to
    > > announce a path to another ASN =5For=5F not. =A0More succinctly= : one needs
    > > input to verify output, (since you said "show me the math&= quot;).
    >
    >
    From: Randy Bush <randy@ps= g.com>
    > Subject: Re: do not filter your customers
    > To: Shane Amante <shane@= castlepoint.net>
    > Cc: North American Network Operators' Group <nanog@nanog.org>
    > Date: Sat, 25 Feb 2012 15:22:35 +0530
    >
    > > as would be solving world hunger, war, bad cooking, especially = bad
    > > cooking.
    > >
    > > route leaks, as much as i understand them
    > > =A0o are indeed bad ops issues
    > > =A0o are not security per se
    > > =A0o are a violation of business relationshiops
    > > =A0o and 20 years of fighting them have not given us any signif= icant
    > > =A0 =A0increase in understanding, formal definition, or prevent= ion.
    >
    > let me try to express how i see the problem. =A0to do this rigorousl= y, i
    >
    would need to form the transitive closure of the b= usiness policies of
    > every inter-provider link on the internet.
    >
    >
    why i say it is per-link and not just inter-as (which would be= hard
    > enough) is that i know a *lot* of examples where two ass have differ= ent
    > business policies on different links. =A0[ i'll exchange se asia= n routes
    > with you in hong kong, but only sell you transit in tokyo. =A0we hav= e two
    > links in frankfurt, one local peering and one international transit.= ]
    >
    > it is not just one-hop because telstra was 'supposed to' pas= s some
    > customers' customers' routes to optus.
    >
    > i find this daunting. =A0but i would *really* like to be able to
    = > rigorously solve it. =A0please please please explain to me how it is=
    > simpler than this.
    >
    > randy
    >

    > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
    > sidr mailing list
    > sidr@ietf.org
    > https://www.ietf.org/mailman/listinfo/sidr
    >

    > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From dougm@nist.gov Thu Mar 22 08:34:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B912D21F858B for ; Thu, 22 Mar 2012 08:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-nmnh05eBzI for ; Thu, 22 Mar 2012 08:34:37 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 24F2D21F84B9 for ; Thu, 22 Mar 2012 08:34:37 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 22 Mar 2012 11:34:21 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 22 Mar 2012 11:30:40 -0400 From: "Montgomery, Douglas" To: Jay Borkenhagen , Brian Dickson Date: Thu, 22 Mar 2012 11:34:25 -0400 Thread-Topic: [sidr] route leaks message to IDR Thread-Index: Ac0IQL1csgaNtWV0RV6Ur4ORkiIsbQ== Message-ID: In-Reply-To: <20331.17624.719267.83969@oz.mt.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:34:37 -0000 On 3/22/12 11:27 AM, "Jay Borkenhagen" wrote: >I am aware of a number of ebgp relationships where the two parties >disagree on the nature of their connections: > >- the first party believes the second is a transit customer > >- the second party believe the first is a peer > >Today the two parties agree to disagree, and yet the proper routing >works. > > >I am also aware of a number of intricate routing policies, along the >lines of in-country transit, per-continent peer, world-wide customer. > > >I'm afraid these kinds of things could make it tricky or even >impossible to categorize links in black-and-white terms as is done in >these leaks drafts. I would suggest categorizing directed links as they appear in AS_PATH. It is not clear to me that A->B has to be labeled the same way as B-->A. Given that we are discussing control of further distribution, I think the sender of an UPDATE would label the link with its view of the relationship. Dougm From rogaglia@cisco.com Thu Mar 22 08:48:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481C721F860B for ; Thu, 22 Mar 2012 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.756 X-Spam-Level: X-Spam-Status: No, score=-10.756 tagged_above=-999 required=5 tests=[AWL=1.843, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcgBXorpwQ5c for ; Thu, 22 Mar 2012 08:48:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B597221F85E0 for ; Thu, 22 Mar 2012 08:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=11567; q=dns/txt; s=iport; t=1332431299; x=1333640899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xOKkB+DfIRLOtK8WuGtOxGxDW2EZ2p9JSnutEPcdo9o=; b=QqSilsvDF01FiIgkJsJYv+tOKe8Sr/2oAPRQ6OG6d4nvA8Z6Ac/OlfPm kMVdLXWU/H1QuBRNJcEH7YidH28ZevoXj5cRe2uEZOtC5xw9H+cxf5fhT rS5wPsvpn0PTS/+4gil0kkm4c+iOrjVND8cTH+9zjfppc1VuCARa6BfK4 g=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM1Ia0+rRDoG/2dsb2JhbABDt0WBB4IJAQEBAwEBAQEPAVUGBAcFBwQCAQgRBAEBKAcCJQsUCQgCBA4FCQUUh2MEAQufH5dAimOFHmMEjmaBIoVXjkCBaIJngVQEBA X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="p7s'?scan'208";a="34122502" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Mar 2012 15:48:19 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2MFmJio022086; Thu, 22 Mar 2012 15:48:19 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Thu, 22 Mar 2012 08:48:18 -0700 From: "Roque Gagliano (rogaglia)" To: "George, Wes" Thread-Topic: [sidr] SIDR Interim 24/March is CANCELLED Thread-Index: AQHNCEMzxd+JPoyF0EKZjEQPR5nhXA== Date: Thu, 22 Mar 2012 15:48:18 +0000 Message-ID: <8F0ACA6D-5F9D-4291-B400-927196DE6C08@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18788.004 x-tm-as-result: No--71.876700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-452--210703865"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:48:27 -0000 --Apple-Mail-452--210703865 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Wes, On Mar 22, 2012, at 2:43 PM, George, Wes wrote: > I'm sorry to harp on this Sandy, and I appreciate your apology, but = frankly I think this communications breakdown is far larger than whether = you accidentally missed a bit of the letter of the law on scheduling = process because of timezones and missed email addresses, so I want to = make sure that what I believe to be the real problem is addressed. >=20 > How is it that these interim meetings have been scheduled without = soliciting the WG for acceptable dates PRIOR to setting the date? >=20 > How did you determine that an(other) interim was necessary and the = appropriateness of the date chosen? I gather that consensus to hold an = interim or when/where it is held is not strictly required[*], but it = seems odd to me that the WG list wouldn't be involved in the discussion = until the mandatory notification deadline. >=20 > In fairness to the chairs, the NANOG interim's timing and location = were more self-explanatory, which is why I didn't bring this up before. = Also, I should have posted about my travel schedule conflict as soon as = I saw the 3/7 announcement, but that announcement was an invite to a = webex session, implying at least to me that things were already = scheduled, rather than soliciting feedback regarding the date, so I let = it go until I saw others raising questions about the scheduling. >=20 > So while we're making notes for next time, I believe that this process = should start with "dear WG, an interim meeting has been requested to = discuss $topic(s). Here are some candidate dates [and locations]. Please = respond with feedback." > This obviously has to happen well enough prior to the candidate dates = to ensure that you have the proper time to work through the process, so = if 4 weeks notification are necessary, that discussion probably has to = start at 6 weeks out. >=20 >=20 > * =46rom http://www.ietf.org/iesg/statement/interim-meetings.html : > "Area Directors will advise the Working Group Chair on interim = face-to-face meeting location, timing, and other aspects of the proposed = meeting that with a goal of not unfairly favoring some subset of the = potential participants or not unfairly biasing the working group = discussions. Working Group Chairs will evaluate the proposed conference = call or jabber session logistics for similar fairness concerns, = consulting with Area Directors as necessary to resolve any concerns = raised by potential participants." >=20 > I'm wondering if perhaps the above needs to be amended to = recommend/require discussion on the WG list? Anyone have opinions on = that? I second your comment on the need to discuss in the mailing list timing = and location of interim meeting previous to any formal process to start. When I first saw the webex invite for a meeting in late March I thought = it was related with the collaboration tools for the normal IETF meeting. Roque > Wes George >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >> Murphy, Sandra >> Sent: Wednesday, March 21, 2012 1:38 PM >> To: sidr@ietf.org >> Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED >>=20 >> In the flurry of apologetic emails that preceeded and followed this >> announcement, I did not apolgize to the working group. >>=20 >> This was my strictly my bungle, in two different directions. >>=20 >> First, I announced the meeting to the sidr mailing list within the = time frame >> required by process. The bungle was that I did not copy the = iesg-secretary as >> I MEANT to do and I KNEW is required by process. I noticed this = myself the >> next week, but too late to meet the required deadline. I informed = the iesg- >> secretary. They sent the announcement and complaints of process = violation >> came in immediately. >>=20 >> Second, I announced the agenda as is required by process one week = ahead of >> time, by my local time zone. However, due to the time of day and = time zone >> differences, it was reckoned the next day in other time zones. >>=20 >> --Sandy, the apologetic wg co-chair >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > 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 --Apple-Mail-452--210703865 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MjIxNTQ4MThaMCMGCSqGSIb3DQEJBDEWBBS+4DZYhWMlVej89DU9wpSsl3K+TzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCpGMOV/PfbpbVtDw6gU74InBXguvSNxOEZW8QI3Ymbexz5 Doomu2cOdv1lUnp8FNBpVt2/vtMGzh0EQSDaFqOwNL3mFIpSvoawxy10GomSlJHV9dR1bbilUtjv 2aMxVODtbxljddxI3P2VcErl9fVBvlPggD9h8tEjSS9+QhdZIVBq4pa0YYwdZxL+uH48H5Ih4cus dsnsNgcEh04r36tx8rC8GWm9w79hpHKkhDSSjPF26RDHz5aLv8j56WFYoQhUILNy2PlzAYLK/PlS GipheGB+6LBmmOPKigY2U+V/kFVlCMkMACYMsCC320wE9guV+0YJkqzF0SIMMpeguMpxAAAAAAAA --Apple-Mail-452--210703865-- From heas@shrubbery.net Thu Mar 22 09:07:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B575521F860B for ; Thu, 22 Mar 2012 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Y6IJL87L-o for ; Thu, 22 Mar 2012 09:07:31 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E11621F85ED for ; Thu, 22 Mar 2012 09:07:31 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 4A79D8841F; Thu, 22 Mar 2012 16:07:30 +0000 (UTC) Date: Thu, 22 Mar 2012 16:07:30 +0000 From: heasley To: "George, Wes" Message-ID: <20120322160730.GB35941@shrubbery.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "adrian@olddog.co.uk" , "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:07:31 -0000 oh, come on already. error in timezone calculation. it was cancelled and no one has lost anything. move on with life. From Sandra.Murphy@sparta.com Thu Mar 22 09:07:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AD121F8617 for ; Thu, 22 Mar 2012 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVTjznogBGLA for ; Thu, 22 Mar 2012 09:07:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5230A21F85ED for ; Thu, 22 Mar 2012 09:07:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2MG7tuf008078; Thu, 22 Mar 2012 11:07:55 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2MG7r0X022478; Thu, 22 Mar 2012 11:07:53 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 12:07:53 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: additional interim meetings Thread-Index: Ac0IGYH/rfSTTc18SE+RRljzGrxz8g== Date: Thu, 22 Mar 2012 16:07:52 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:07:58 -0000 As the last few day's email explosion has shown, this is a complex topic, c= overing routing, security, operations, governance, policy, etc. =0A= =0A= The complexities mean more energy and time for debate is needed than is pos= sible in IETF meetings. Progress so far in the working group has been aide= d by intense lengthy discussions in-between the IETF meetings. Those invol= ved in the discussions were wg members, including half-a-dozen draft author= s and individuals from IETF, ops, vendor, academic, research, etc. =0A= =0A= But the ADs were concerned about the effect on the open IETF process.=0A= =0A= To continue the energy and continue to promote progress, several options we= re considered. The ADs' eventual decision was that organizing frequent ope= n interim meetings would be best, so that the entire wg could participate a= s they wished.=0A= =0A= Interim meetings would be face-face meetings co-located with venues of comm= unities of interest to this work (ie nanog, ripe, arin, etc.) when faciliti= es are volunteered, or virtual meetings when volunteer hosts can not be fou= nd.=0A= =0A= The idea is to meet to discuss thorny topics at length. Agendas announced = ahead of time, remote participation always available, minutes reported to t= he wg, proceedings published. When webex is used, recordings will be taken= .=0A= =0A= This should function like regular IETF sidr meetings (but more often and wi= th more remote participation).=0A= =0A= Here is a suggested semi-schedule for the next several months.=0A= =0A= 30 April (chosen so as not to conflict with RIPE or ARIN in the preceding w= eeks) (Likely important topic - the government oversight concerns at RIPE = and mitigating possibilities, impacts of the ARIN and RIPE meeting)=0A= =0A= 6 Jun, co-located with NANOG (that is the Wed after NANOG ends - there are = indications that nanog may be able to lend a room after noon.)=0A= =0A= the last part of June: 25 Jun - 3 July=0A= =0A= at one end or the other of the IETF (sort of like iegp meets at IETFs) in J= uly=0A= =0A= (not likely people will want to try to meet in August)=0A= =0A= Then further out: mid-Sep, mid-October (maybe NANOG/ARIN, as a community of= interest), IETF in November.=0A= =0A= Interim meetings are not supported by the secretariat, so for face-face mee= tings we have to rely on volunteer organizations or hosts. That will mean = that some meetings will have no hosts (virtual) or will have hosts but be s= pace bounded (limited face-face). Remote participation will always be avai= lable.=0A= =0A= Comments?=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= (I begin traveling in a few hours, so replies to responses will be delayed)= From brian.peter.dickson@gmail.com Thu Mar 22 09:09:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525AC21F85C0 for ; Thu, 22 Mar 2012 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhufOfxLr6vp for ; Thu, 22 Mar 2012 09:09:39 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2821F85ED for ; Thu, 22 Mar 2012 09:09:38 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so875343wib.1 for ; Thu, 22 Mar 2012 09:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=USVhNDOjfJyiOhTp4rWBbruch6Bux0Uf6UUHENMFA9E=; b=X083gF41yAW/paXssey5i9H0IG4eYi7hDqFCgTucK2Asu6AMpPvQnvHA2V0AqJ2zss Sp3sez+KSPYX/9AA92jUWLjI9b+B7Xgwvbx2eBmzM07xmTbZ5viQmrBcpOp9Qv8iW6qw M8Z+I9jyTKUixTWW+3ekT5vXL0/Vs7L4FyLgE5ee7UXTLqSkdMvBxdnO9jlkx3W7P/eQ biNsZdn0KkcnWHBiKwwoVzZBq0X6cVV7pz1wlYBkSWf5240ya8j1jlvLytBMWnmCsn8f 1pqWsfDefvWgygnBAkjN7JqjY0954IbfO/QiCJ3YSpuKJcfPP/0OTtKcLTtJ9H8URBGW jJSw== MIME-Version: 1.0 Received: by 10.180.107.101 with SMTP id hb5mr7595154wib.3.1332432577981; Thu, 22 Mar 2012 09:09:37 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Thu, 22 Mar 2012 09:09:37 -0700 (PDT) In-Reply-To: <20331.17624.719267.83969@oz.mt.att.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <20331.17624.719267.83969@oz.mt.att.com> Date: Thu, 22 Mar 2012 12:09:37 -0400 Message-ID: From: Brian Dickson To: Jay Borkenhagen Content-Type: multipart/alternative; boundary=e89a8f3bb0cf7f6d9c04bbd72285 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:09:41 -0000 --e89a8f3bb0cf7f6d9c04bbd72285 Content-Type: text/plain; charset=ISO-8859-1 Hi, Jay, Out of curiosity, have you had a chance to read (or skim over) the drafts? Basically, what they do is say, "how can we categorize the link, with four options to choose from". The categories do not need to handle all the subtleties, they only need to be consistent with whatever local policy is. E.g. Your first example - having the "second party" configure the link as "transit-customer" does not in any way obligate them to apply a transit _policy_ on the link. The link coloring is technically orthogonal to all existing policy mechanisms. It simply adds a mechanism to automatically stop route leaks. The three drafts together have a simple rule of thumb: if all three "standard" link type categorizations would block routes that the peers mutually agree should not be blocked, the fourth, "mutual transit" allows anything to pass. It just so happens that the way "mutual transit" handles customer and non-customer routes, prevents route leaks from crossing the other three types of link (customer, transit, peer). If the "local policy" applied to a given link can fit within one of the three "standard" classes (as a proper subset) without blocking routes that should be sent, then that "standard" class should be used. It is meant to be easy to use, and easy to figure out classification. The question "Am I sending _any_ non-customer routes?", from the perspective of both peers, leads to the correct answer: No/No == Peer Yes/No == Transit No/Yes == Customer Yes/Yes == "mutual transit" (generic for "oddball") This suggests I need to make the docs a little clearer in this regard -- I definitely will. Thanks for your feedback. Brian On Thu, Mar 22, 2012 at 11:27 AM, Jay Borkenhagen wrote: > I am aware of a number of ebgp relationships where the two parties > disagree on the nature of their connections: > > - the first party believes the second is a transit customer > > - the second party believe the first is a peer > > Today the two parties agree to disagree, and yet the proper routing > works. > > > I am also aware of a number of intricate routing policies, along the > lines of in-country transit, per-continent peer, world-wide customer. > > > I'm afraid these kinds of things could make it tricky or even > impossible to categorize links in black-and-white terms as is done in > these leaks drafts. > > > > Brian Dickson writes: > > The drafts (three of them, together) are an attempt to define, > constrain, > > and solve the problem. > > > > Yes, it is tricky and difficult. I'm not saying that the solutions (two > of > > them to choose from) are the only way to do it. > > But, I believe that either of them actually solves the problem. > > > > In a nutshell, here's how it works: > > Mark the path "intent" in one of two ways (customer or non-customer), > > (based on mutual agreement between adjacent peers) > > Incorporate some kind of mechanism to detect/prevent fudging (a la > bgpsec > > sig) > > Apply a simple set of rules based on route color vs peering "type", plus > > "v-free" type logic. > > > > Everything is in-band, and the transitive closure _is_ the transitive > > closure. > > > > ASCII art is not adequate for presenting complex ideas, IMHO. I will > > attempt to provide a richer presentation for Paris. > > > > Please, if anyone is interested, for the love of $deity, read the drafts > > and provide feedback. > > > > Thanks, > > Brian > > > > On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush wrote: > > > > > >>> Answer: Evaluate policy. > > > >> 'apply prefix lists' you mean? > > > > No. Evaluate _policy_. Policy is about whether an ASN /intended/ > to > > > > announce a path to another ASN _or_ not. More succinctly: one needs > > > > input to verify output, (since you said "show me the math"). > > > > > > From: Randy Bush > > > Subject: Re: do not filter your customers > > > To: Shane Amante > > > Cc: North American Network Operators' Group > > > Date: Sat, 25 Feb 2012 15:22:35 +0530 > > > > > > > as would be solving world hunger, war, bad cooking, especially bad > > > > cooking. > > > > > > > > route leaks, as much as i understand them > > > > o are indeed bad ops issues > > > > o are not security per se > > > > o are a violation of business relationshiops > > > > o and 20 years of fighting them have not given us any significant > > > > increase in understanding, formal definition, or prevention. > > > > > > let me try to express how i see the problem. to do this rigorously, i > > > would need to form the transitive closure of the business policies of > > > every inter-provider link on the internet. > > > > > > why i say it is per-link and not just inter-as (which would be hard > > > enough) is that i know a *lot* of examples where two ass have > different > > > business policies on different links. [ i'll exchange se asian routes > > > with you in hong kong, but only sell you transit in tokyo. we have > two > > > links in frankfurt, one local peering and one international transit. ] > > > > > > it is not just one-hop because telstra was 'supposed to' pass some > > > customers' customers' routes to optus. > > > > > > i find this daunting. but i would *really* like to be able to > > > rigorously solve it. please please please explain to me how it is > > > simpler than this. > > > > > > randy > > > > > > _______________________________________________ > > > sidr mailing list > > > sidr@ietf.org > > > https://www.ietf.org/mailman/listinfo/sidr > > > > > The drafts (three of them, together) are an attempt to define, > constrain, and solve the problem.

    Yes, it is tricky and difficult. > I'm not saying that the solutions (two of them to choose from) are the > only way to do it.
    > > But, I believe that either of them actually solves the > problem.

    In a nutshell, here's how it works:
    Mark the path > "intent" in one of two ways (customer or non-customer), (based on > mutual agreement between adjacent peers)
    > > Incorporate some kind of mechanism to detect/prevent fudging (a la > bgpsec sig)
    Apply a simple set of rules based on route color vs peering > "type", plus "v-free" type logic.

    Everything is > in-band, and the transitive closure _is_ the transitive closure.
    > >
    ASCII art is not adequate for presenting complex ideas, IMHO. I > will attempt to provide a richer presentation for Paris.

    Please, if > anyone is interested, for the love of $deity, read the drafts and provide > feedback.
    > >
    Thanks,
    Brian

    On Wed, Mar 21, > 2012 at 5:37 PM, Randy Bush <randy@psg.com> wrote:
    class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"> > >
    >>> Answer: Evaluate policy.
    > > >> 'apply prefix lists' you mean?
    > > > No. Evaluate _policy_. Policy is about whether an ASN /intended/ > to
    > > > announce a path to another ASN _or_ not. More succinctly: one > needs
    > > > input to verify output, (since you said "show me the > math").
    > >
    > >
    From: Randy Bush <randy@psg.com > >
    > > Subject: Re: do not filter your customers
    > > To: Shane Amante < > shane@castlepoint.net>
    > > Cc: North American Network Operators' Group <nanog@nanog.org>
    > > Date: Sat, 25 Feb 2012 15:22:35 +0530
    > >
    > > > as would be solving world hunger, war, bad cooking, especially > bad
    > > > cooking.
    > > >
    > > > route leaks, as much as i understand them
    > > > o are indeed bad ops issues
    > > > o are not security per se
    > > > o are a violation of business relationshiops
    > > > o and 20 years of fighting them have not given us any > significant
    > > > increase in understanding, formal definition, or prevention.
    > >
    > > let me try to express how i see the problem. to do this rigorously, > i
    > >
    would need to form the transitive closure of the > business policies of
    > > every inter-provider link on the internet.
    > >
    > >
    why i say it is per-link and not just inter-as (which would be > hard
    > > enough) is that i know a *lot* of examples where two ass have > different
    > > business policies on different links. [ i'll exchange se asian > routes
    > > with you in hong kong, but only sell you transit in tokyo. we have > two
    > > links in frankfurt, one local peering and one international transit. > ]
    > >
    > > it is not just one-hop because telstra was 'supposed to' pass > some
    > > customers' customers' routes to optus.
    > >
    > > i find this daunting. but i would *really* like to be able to
    > > rigorously solve it. please please please explain to me how it is
    > > simpler than this.
    > >
    > > randy
    > >

    > > _______________________________________________
    > > 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 > --e89a8f3bb0cf7f6d9c04bbd72285 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Jay,

    Out of curiosity, have you had a chance to read (or skim ov= er) the drafts?

    Basically, what they do is say, "how can we cat= egorize the link, with four options to choose from".

    The catego= ries do not need to handle all the subtleties, they only need to be consist= ent with whatever local policy is.

    E.g. Your first example - having the "second party" configure= the link as "transit-customer" does not in any way obligate them= to apply a transit _policy_ on the link. The link coloring is technically = orthogonal to all existing policy mechanisms. It simply adds a mechanism to= automatically stop route leaks.

    The three drafts together have a simple rule of thumb: if all three &qu= ot;standard" link type categorizations would block routes that the pee= rs mutually agree should not be blocked, the fourth, "mutual transit&q= uot; allows anything to pass. It just so happens that the way "mutual = transit" handles customer and non-customer routes, prevents route leak= s from crossing the other three types of link (customer, transit, peer).
    If the "local policy" applied to a given link can fit within = one of the three "standard" classes (as a proper subset) without = blocking routes that should be sent, then that "standard" class s= hould be used.

    It is meant to be easy to use, and easy to figure out classification.The question "Am I sending _any_ non-customer routes?", from th= e perspective of both peers, leads to the correct answer:
    No/No =3D=3D P= eer
    Yes/No =3D=3D Transit
    No/Yes =3D=3D Customer
    Yes/Yes =3D=3D "mut= ual transit" (generic for "oddball")

    This suggests I = need to make the docs a little clearer in this regard -- I definitely will.=

    Thanks for your feedback.

    Brian

    On= Thu, Mar 22, 2012 at 11:27 AM, Jay Borkenhagen <jayb@braeburn.org> wrote:
    =
    I am aware of a number of ebgp relationships where the two parties
    disagree on the nature of their connections:

    - the first party believes the second is a transit customer

    - the second party believe the first is a peer

    Today the two parties agree to disagree, and yet the proper routing
    works.


    I am also aware of a number of intricate routing policies, along the
    lines of in-country transit, per-continent peer, world-wide customer.


    I'm afraid these kinds of things could make it tricky or even
    impossible to categorize links in black-and-white terms as is done in
    these leaks drafts.



    Brian Dickson writes:
    =A0> The drafts (three of them, together) are an attempt to define, cons= train,
    =A0> and solve the problem.
    =A0>
    =A0> Yes, it is tricky and difficult. I'm not saying that the soluti= ons (two of
    =A0> them to choose from) are the only way to do it.
    =A0> But, I believe that either of them actually solves the problem.
    =A0>
    =A0> In a nutshell, here's how it works:
    =A0> Mark the path "intent" in one of two ways (customer or no= n-customer),
    =A0> (based on mutual agreement between adjacent peers)
    =A0> Incorporate some kind of mechanism to detect/prevent fudging (a la = bgpsec
    =A0> sig)
    =A0> Apply a simple set of rules based on route color vs peering "t= ype", plus
    =A0> "v-free" type logic.
    =A0>
    =A0> Everything is in-band, and the transitive closure _is_ the transiti= ve
    =A0> closure.
    =A0>
    =A0> ASCII art is not adequate for presenting complex ideas, IMHO. I wil= l
    =A0> attempt to provide a richer presentation for Paris.
    =A0>
    =A0> Please, if anyone is interested, for the love of $deity, read the d= rafts
    =A0> and provide feedback.
    =A0>
    =A0> Thanks,
    =A0> Brian
    =A0>
    =A0> On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush <randy@psg.com> wrote:
    =A0>
    =A0> > >>> Answer: Evaluate policy.
    =A0> > >> 'apply prefix lists' you mean?
    =A0> > > No. =A0Evaluate _policy_. =A0Policy is about whether an A= SN /intended/ to
    =A0> > > announce a path to another ASN _or_ not. =A0More succinct= ly: one needs
    =A0> > > input to verify output, (since you said "show me the= math").
    =A0> >
    =A0> > From: Randy Bush <randy@ps= g.com>
    =A0> > Subject: Re: do not filter your customers
    =A0> > To: Shane Amante <= shane@castlepoint.net>
    =A0> > Cc: North American Network Operators' Group <nanog@nanog.org>
    =A0> > Date: Sat, 25 Feb 2012 15:22:35 +0530
    =A0> >
    =A0> > > as would be solving world hunger, war, bad cooking, espec= ially bad
    =A0> > > cooking.
    =A0> > >
    =A0> > > route leaks, as much as i understand them
    =A0> > > =A0o are indeed bad ops issues
    =A0> > > =A0o are not security per se
    =A0> > > =A0o are a violation of business relationshiops
    =A0> > > =A0o and 20 years of fighting them have not given us any = significant
    =A0> > > =A0 =A0increase in understanding, formal definition, or p= revention.
    =A0> >
    =A0> > let me try to express how i see the problem. =A0to do this rig= orously, i
    =A0> > would need to form the transitive closure of the business poli= cies of
    =A0> > every inter-provider link on the internet.
    =A0> >
    =A0> > why i say it is per-link and not just inter-as (which would be= hard
    =A0> > enough) is that i know a *lot* of examples where two ass have = different
    =A0> > business policies on different links. =A0[ i'll exchange s= e asian routes
    =A0> > with you in hong kong, but only sell you transit in tokyo. =A0= we have two
    =A0> > links in frankfurt, one local peering and one international tr= ansit. ]
    =A0> >
    =A0> > it is not just one-hop because telstra was 'supposed to= 9; pass some
    =A0> > customers' customers' routes to optus.
    =A0> >
    =A0> > i find this daunting. =A0but i would *really* like to be able = to
    =A0> > rigorously solve it. =A0please please please explain to me how= it is
    =A0> > simpler than this.
    =A0> >
    =A0> > randy
    =A0> >
    =A0> > _______________________________________________
    =A0> > sidr mailing list
    =A0> > sidr@ietf.org
    =A0> > https://www.ietf.org/mailman/listinfo/sidr
    =A0> >
    =A0> The drafts (three of them, together) are an attempt to = define, constrain, and solve the problem.<br><br>Yes, it is tri= cky and difficult. I&#39;m not saying that the solutions (two of them t= o choose from) are the only way to do it.<br>
    =A0> But, I believe that either of them actually solves the problem.<= br><br>In a nutshell, here&#39;s how it works:<br>Mark t= he path &quot;intent&quot; in one of two ways (customer or non-cust= omer), (based on mutual agreement between adjacent peers)<br>
    =A0> Incorporate some kind of mechanism to detect/prevent fudging (a la = bgpsec sig)<br>Apply a simple set of rules based on route color vs pe= ering &quot;type&quot;, plus &quot;v-free&quot; type logic.= <br><br>Everything is in-band, and the transitive closure _is_ = the transitive closure.<br>
    =A0> <br>ASCII art is not adequate for presenting complex ideas, I= MHO. I will attempt to provide a richer presentation for Paris.<br>&l= t;br>Please, if anyone is interested, for the love of $deity, read the d= rafts and provide feedback.<br>
    =A0> <br>Thanks,<br>Brian<br><br><div class= =3D"gmail_quote">On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush &= lt;span dir=3D"ltr">&lt;<a href=3D"mailto:randy@psg.com">randy@psg.com</a>&gt;</span> wrote:<br>= ;<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">
    =A0> <div class=3D"im">&gt;&gt;&gt; Answer: = Evaluate policy.<br>
    =A0> &gt;&gt; &#39;apply prefix lists&#39; you mean?<= br>
    =A0> &gt; No. =A0Evaluate _policy_. =A0Policy is about whether an AS= N /intended/ to<br>
    =A0> &gt; announce a path to another ASN _or_ not. =A0More succinctl= y: one needs<br>
    =A0> &gt; input to verify output, (since you said &quot;show me = the math&quot;).<br>
    =A0> <br>
    =A0> </div>From: Randy Bush &lt;<a href=3D"mailto:randy@psg.com">randy@psg.com</a>&gt;<br>
    =A0> Subject: Re: do not filter your customers<br>
    =A0> To: Shane Amante &lt;<a href=3D"mailto:shane@castlepoint.net">shane@castlepoint.net</a>&gt;<br= >
    =A0> Cc: North American Network Operators&#39; Group &lt;<a h= ref=3D"mailto:nanog@nanog.org&q= uot;>nanog@nanog.org</a>&am= p;gt;<br>
    =A0> Date: Sat, 25 Feb 2012 15:22:35 +0530<br>
    =A0> <br>
    =A0> &gt; as would be solving world hunger, war, bad cooking, especi= ally bad<br>
    =A0> &gt; cooking.<br>
    =A0> &gt;<br>
    =A0> &gt; route leaks, as much as i understand them<br>
    =A0> &gt; =A0o are indeed bad ops issues<br>
    =A0> &gt; =A0o are not security per se<br>
    =A0> &gt; =A0o are a violation of business relationshiops<br><= br> =A0> &gt; =A0o and 20 years of fighting them have not given us any s= ignificant<br>
    =A0> &gt; =A0 =A0increase in understanding, formal definition, or pr= evention.<br>
    =A0> <br>
    =A0> let me try to express how i see the problem. =A0to do this rigorous= ly, i<br>
    =A0> <div class=3D"im">would need to form the transitive= closure of the business policies of<br>
    =A0> every inter-provider link on the internet.<br>
    =A0> <br>
    =A0> </div>why i say it is per-link and not just inter-as (which w= ould be hard<br>
    =A0> enough) is that i know a *lot* of examples where two ass have diffe= rent<br>
    =A0> business policies on different links. =A0[ i&#39;ll exchange se= asian routes<br>
    =A0> with you in hong kong, but only sell you transit in tokyo. =A0we ha= ve two<br>
    =A0> links in frankfurt, one local peering and one international transit= . ]<br>
    =A0> <br>
    =A0> it is not just one-hop because telstra was &#39;supposed to&= ;#39; pass some<br>
    =A0> customers&#39; customers&#39; routes to optus.<br> =A0> <br>
    =A0> i find this daunting. =A0but i would *really* like to be able to<= ;br>
    =A0> rigorously solve it. =A0please please please explain to me how it i= s<br>
    =A0> simpler than this.<br>
    =A0> <span class=3D"HOEnZb"><font color=3D"#8888= 88"><br>
    =A0> randy<br>
    =A0> </font></span><div class=3D"HOEnZb"><= ;div class=3D"h5"><br>
    =A0> _______________________________________________<br>
    =A0> sidr mailing list<br>
    =A0> <a href=3D"mailto:sidr@iet= f.org">sidr@ietf.org</a= ><br>
    =A0> <a href=3D"https://www.ietf.org/mailman/listinfo/sidr&quo= t; target=3D"_blank">https://www.ietf.org/mailman/listinfo/sidr<= /a></a><br>
    =A0> </div></div></blockquote></div><br>
    =A0> ___________________________= ____________________
    =A0> sidr mailing list
    =A0>     sidr@ietf.org
    =A0> https://www.ietf.org/mailman/listinfo/sidr

    --e89a8f3bb0cf7f6d9c04bbd72285-- From jayb@braeburn.org Thu Mar 22 09:22:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8187621F860F for ; Thu, 22 Mar 2012 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfDqkM3K5TaM for ; Thu, 22 Mar 2012 09:22:30 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C193321F85FD for ; Thu, 22 Mar 2012 09:22:29 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 5c15b6f4.0.1423430.00-219.3918737.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 22 Mar 2012 16:22:29 +0000 (UTC) X-MXL-Hash: 4f6b51c517f684f9-c1b45a58b714b24880f54198e640f2bdf68aea02 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MGMSuo031492 for ; Thu, 22 Mar 2012 12:22:28 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2MGMKvY031427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Mar 2012 12:22:25 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 22 Mar 2012 12:21:57 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MGLvTq010726 for ; Thu, 22 Mar 2012 12:21:57 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2MGLn4d010405 for ; Thu, 22 Mar 2012 12:21:49 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id BCB692BF2C; Thu, 22 Mar 2012 12:21:48 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20331.20890.204057.158137@oz.mt.att.com> Date: Thu, 22 Mar 2012 12:21:46 -0400 From: Jay Borkenhagen To: In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <20331.17624.719267.83969@oz.mt.att.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:22:30 -0000 Brian Dickson writes: > Hi, Jay, > > Out of curiosity, have you had a chance to read (or skim over) the drafts? Um, yes. That's where I found your text: --------------------------------------------- Neighbor is: a. Transit Provider - T b. (Transit) Customer - C c. Peer - P d. Mutual Transit In any neighbor relationship, the roles of the parties on either end of the link would be: T-C C-T P-P Mc-Mtp Mtp-Mc (where the last two, Mc/Mtp are a semantic and/or coloring distinction on routes, rather than two separate links.) --------------------------------------------- "P-T" and "T-P" were not listed among the choices. If bi-lateral agreement is not a requirement, then I would suggest modifying the text to not imply that it is. From aservin@lacnic.net Thu Mar 22 09:50:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC34C21F8617 for ; Thu, 22 Mar 2012 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziOwAi8eUqR0 for ; Thu, 22 Mar 2012 09:49:55 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 761DA21F85D7 for ; Thu, 22 Mar 2012 09:49:55 -0700 (PDT) Received: from [192.168.189.119] (r190-135-0-77.dialup.adsl.anteldata.net.uy [190.135.0.77]) by mail.lacnic.net.uy (Postfix) with ESMTP id 74F55308478; Thu, 22 Mar 2012 13:49:47 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> Date: Thu, 22 Mar 2012 13:49:43 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <141D7D7A-899D-4A36-87E4-8AD1784D9A84@lacnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:50:16 -0000 Sandy, I offer (well LACNIC) a room and all the facilities required for = the second week of May (LACNIC XVII) or the last week of October in 2012 = (LACNIC XVII - LACNOG 2012). The meeting in May is in Quito Ecuador and = the one in October is in Montevideo. Just let me know and I would do the arrangements. Regards, as On 22 Mar 2012, at 13:07, Murphy, Sandra wrote: > As the last few day's email explosion has shown, this is a complex = topic, covering routing, security, operations, governance, policy, etc. =20= >=20 > The complexities mean more energy and time for debate is needed than = is possible in IETF meetings. Progress so far in the working group has = been aided by intense lengthy discussions in-between the IETF meetings. = Those involved in the discussions were wg members, including = half-a-dozen draft authors and individuals from IETF, ops, vendor, = academic, research, etc. =20 >=20 > But the ADs were concerned about the effect on the open IETF process. >=20 > To continue the energy and continue to promote progress, several = options were considered. The ADs' eventual decision was that organizing = frequent open interim meetings would be best, so that the entire wg = could participate as they wished. >=20 > Interim meetings would be face-face meetings co-located with venues of = communities of interest to this work (ie nanog, ripe, arin, etc.) when = facilities are volunteered, or virtual meetings when volunteer hosts can = not be found. >=20 > The idea is to meet to discuss thorny topics at length. Agendas = announced ahead of time, remote participation always available, minutes = reported to the wg, proceedings published. When webex is used, = recordings will be taken. >=20 > This should function like regular IETF sidr meetings (but more often = and with more remote participation). >=20 > Here is a suggested semi-schedule for the next several months. >=20 > 30 April (chosen so as not to conflict with RIPE or ARIN in the = preceding weeks) (Likely important topic - the government oversight = concerns at RIPE and mitigating possibilities, impacts of the ARIN and = RIPE meeting) >=20 > 6 Jun, co-located with NANOG (that is the Wed after NANOG ends - there = are indications that nanog may be able to lend a room after noon.) >=20 > the last part of June: 25 Jun - 3 July >=20 > at one end or the other of the IETF (sort of like iegp meets at IETFs) = in July >=20 > (not likely people will want to try to meet in August) >=20 > Then further out: mid-Sep, mid-October (maybe NANOG/ARIN, as a = community of interest), IETF in November. >=20 > Interim meetings are not supported by the secretariat, so for = face-face meetings we have to rely on volunteer organizations or hosts. = That will mean that some meetings will have no hosts (virtual) or will = have hosts but be space bounded (limited face-face). Remote = participation will always be available. >=20 > Comments? >=20 > --Sandy, speaking as wg co-chair >=20 >=20 > (I begin traveling in a few hours, so replies to responses will be = delayed) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Mar 22 11:08:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103C21F84F2 for ; Thu, 22 Mar 2012 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Kw511RIJSl for ; Thu, 22 Mar 2012 11:08:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0409F21F84D9 for ; Thu, 22 Mar 2012 11:08:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAmRU-0001Ea-Sv; Thu, 22 Mar 2012 18:08:57 +0000 Date: Thu, 22 Mar 2012 19:08:55 +0100 Message-ID: From: Randy Bush To: Jay Borkenhagen In-Reply-To: <20331.17624.719267.83969@oz.mt.att.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <20331.17624.719267.83969@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:08:59 -0000 > I am aware of a number of ebgp relationships where the two parties > disagree on the nature of their connections: > - the first party believes the second is a transit customer > - the second party believe the first is a peer yep. as i said, i will save this part of the mess until we have shown that brian's approach at least deals with the basics, the gao-rexford fantasy that the world is flat. then we can see if we can stretch the solution to deal with these cases. > I am also aware of a number of intricate routing policies, along the > lines of in-country transit, per-continent peer, world-wide customer. that may be simpler. it may just be different policies for different prefixes. and we know it's all per prefix anyway. randy From randy@psg.com Thu Mar 22 11:09:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54B21F8552 for ; Thu, 22 Mar 2012 11:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-3G-jCpx+4w for ; Thu, 22 Mar 2012 11:09:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C233521F8550 for ; Thu, 22 Mar 2012 11:09:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAmS3-0001Ey-FL; Thu, 22 Mar 2012 18:09:31 +0000 Date: Thu, 22 Mar 2012 19:09:30 +0100 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> <20331.17624.719267.83969@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:09:34 -0000 > Basically, what they do is say, "how can we categorize the link, you can't. it has to be per prefix. randy From randy@psg.com Thu Mar 22 11:29:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F121F855B for ; Thu, 22 Mar 2012 11:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ttde+8IKMNn7 for ; Thu, 22 Mar 2012 11:29:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 28D4521F8559 for ; Thu, 22 Mar 2012 11:29:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAmku-0001JA-DE; Thu, 22 Mar 2012 18:29:01 +0000 Date: Thu, 22 Mar 2012 19:28:53 +0100 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91BF@Hermes.columbia.ads.sparta.com> References: <4F69F033.7040207@riw.us> <41B12A9C-7750-452C-8A80-304E05D4F94C@verisign.com> <1F12FDD3-9355-4B26-B6C4-04539795982A@castlepoint.net> <96343740-CEA9-4C77-B55D-410537275FDE@castlepoint.net> User-Agent: Wanderlust/2.15.9 (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 Cc: "sidr@ietf.org" Subject: Re: [sidr] route leaks message to IDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:29:02 -0000 > There is agreement that route leaks is a problem. > There is agreement that a change to bgp might provide a solution, but > concern about sidr undertaking the solution without idr participation. > Would the idr be willing to work with sidr in (a) defining the route > leaks problem, (b) devising a solution and (c) securing that solution? > The actual home for the work (idr, sidr, both, something else) would > be discussed. route leaks s/is/are/ a problem :) From randy@psg.com Thu Mar 22 11:33:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349B21F85D2 for ; Thu, 22 Mar 2012 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQkU2ZyxK1PL for ; Thu, 22 Mar 2012 11:33:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 121E721F85C9 for ; Thu, 22 Mar 2012 11:33:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SAmou-0001PQ-03; Thu, 22 Mar 2012 18:33:08 +0000 Date: Thu, 22 Mar 2012 19:32:58 +0100 Message-ID: From: Randy Bush To: heasley In-Reply-To: <20120322160730.GB35941@shrubbery.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C8F32@Hermes.columbia.ads.sparta.com> <20120322160730.GB35941@shrubbery.net> User-Agent: Wanderlust/2.15.9 (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 Cc: "adrian@olddog.co.uk" , "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] SIDR Interim 24/March is CANCELLED X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:33:16 -0000 > oh, come on already. error in timezone calculation. it was cancelled and > no one has lost anything. move on with life. a few years back i made some tee shirts "the ietf, where process is our most important product." [ apologies to the young and to non-americans. scroll down to ronnie's pic in http://www.smecc.org/frontiers_of_progress_-_1961_sales_meeting.htm ] randy From eosterweil@verisign.com Thu Mar 22 11:43:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB7E21F85EA for ; Thu, 22 Mar 2012 11:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MByimxulihBp for ; Thu, 22 Mar 2012 11:43:34 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id D9AE821F85E0 for ; Thu, 22 Mar 2012 11:43:22 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKT2tyyUy0akaLqngIJjCc/wcnYghZj3nc@postini.com; Thu, 22 Mar 2012 11:43:24 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q2MIhHMq020243; Thu, 22 Mar 2012 14:43:17 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 14:43:15 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> Date: Thu, 22 Mar 2012 14:43:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D4CB71B-60D2-4204-B434-BDC7BDE98BC7@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 22 Mar 2012 18:43:15.0765 (UTC) FILETIME=[A472DE50:01CD085B] Cc: "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:43:35 -0000 My 0.02 below: On Mar 22, 2012, at 12:07 PM, Murphy, Sandra wrote: > As the last few day's email explosion has shown, this is a complex = topic, covering routing, security, operations, governance, policy, etc. =20= >=20 > The complexities mean more energy and time for debate is needed than = is possible in IETF meetings. Progress so far in the working group has = been aided by intense lengthy discussions in-between the IETF meetings. = Those involved in the discussions were wg members, including = half-a-dozen draft authors and individuals from IETF, ops, vendor, = academic, research, etc. =20 >=20 > But the ADs were concerned about the effect on the open IETF process. >=20 > To continue the energy and continue to promote progress, several = options were considered. The ADs' eventual decision was that organizing = frequent open interim meetings would be best, so that the entire wg = could participate as they wished. >=20 > Interim meetings would be face-face meetings co-located with venues of = communities of interest to this work (ie nanog, ripe, arin, etc.) when = facilities are volunteered, or virtual meetings when volunteer hosts can = not be found. So, for those that make special plans to attend IETF meetings, we now = must _also_ make plans to attend a lot more meetings (re: the f2f = comment). I understand that the hope here is to increase the rate of = progress that the wg makes. However, I fear the effect would be that = those who can travel more will develop more context and influence more = decisions than others. If I'm not mistaken, the mailing list is open = 24/7, IDs are processed during those same hours, so (wrt trying to = increase some rate of progress) why is there a special case being made = for sidr, as opposed to other ietf wgs? >=20 > The idea is to meet to discuss thorny topics at length. Agendas = announced ahead of time, remote participation always available, minutes = reported to the wg, proceedings published. When webex is used, = recordings will be taken. Why is this an exceptional case? Have there not been other wgs w/ these = issues before? >=20 > This should function like regular IETF sidr meetings (but more often = and with more remote participation). >=20 > Here is a suggested semi-schedule for the next several months. >=20 > 30 April (chosen so as not to conflict with RIPE or ARIN in the = preceding weeks) (Likely important topic - the government oversight = concerns at RIPE and mitigating possibilities, impacts of the ARIN and = RIPE meeting) >=20 > 6 Jun, co-located with NANOG (that is the Wed after NANOG ends - there = are indications that nanog may be able to lend a room after noon.) >=20 > the last part of June: 25 Jun - 3 July >=20 > at one end or the other of the IETF (sort of like iegp meets at IETFs) = in July >=20 > (not likely people will want to try to meet in August) >=20 > Then further out: mid-Sep, mid-October (maybe NANOG/ARIN, as a = community of interest), IETF in November. >=20 > Interim meetings are not supported by the secretariat, so for = face-face meetings we have to rely on volunteer organizations or hosts. = That will mean that some meetings will have no hosts (virtual) or will = have hosts but be space bounded (limited face-face). Remote = participation will always be available. >=20 > Comments? This is a large amount of travel and I think it unduly reduces the = ability of many of the wg's members to participate at the same level as = they do today. I think this is a bad idea. Eric= From robert@raszuk.net Thu Mar 22 13:40:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAA721F851A for ; Thu, 22 Mar 2012 13:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn2N4PHTl8Rh for ; Thu, 22 Mar 2012 13:40:15 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 26D4721F8517 for ; Thu, 22 Mar 2012 13:40:15 -0700 (PDT) Received: (qmail 2645 invoked by uid 399); 22 Mar 2012 20:40:14 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.31.183.245) by mail1310.opentransfer.com with ESMTPM; 22 Mar 2012 20:40:14 -0000 X-Originating-IP: 83.31.183.245 Message-ID: <4F6B8E31.3010108@raszuk.net> Date: Thu, 22 Mar 2012 21:40:17 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:40:16 -0000 Hi Doug, Actually I am not that concerned what spec will recommend for the operator to do. I am more concerned what should be the router's default? Considering the example below should it be: To prefer signed longer path versus unsigned shorter ? Specifically I am asking - where does the signed vs unsigned decision step inserts itself into today's BGP best path decision ? Should it be complete haos by allowing full freedom for local operator's configuration ? Should the default be "Do not care" if this is signed or unsigned ... just run your BGP best path as today ? Thx, R. > Sorry, my bad. I somehow thought you were talking about two different > PATH elements in the same update. That assumption made your questions > sound bizarre. I am sure my misunderstanding made my answers sound > equally bizarre. > > So, yes if they are different updates for the same prefix received from > different peers ... Then of course this will happen all the time. > > As for if you somehow prefer the signed path over the unsigned path, in > the end that is a local decision. I think there is/will be strong wording > that one SHOULD choose the signed and valid path because at the moment > there is no explicit way of distinguishing that a path should have been > signed, and as a result, there is a simple downgrade attack to strip the > PATHSIG, if one is not strictly preferring signed over unsigned paths. > > One could think of fixing this, by having AS's push and object in the RPKI > that says "I am signing my paths", then it would be possible to detect the > simple downgrade attack. I guess one might think of AS_CERTS as such a > signal, but that is a bit problematic WRT timing issues. The right way to > do it would be some other explicit object. > > Anyway, to answer your question below, one SHOULD choose the second path, > but I doubt the specs will ever say you MUST choose the second path. > > dougm From rv@x37.NIC.DTAG.DE Thu Mar 22 14:31:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23621E8037 for ; Thu, 22 Mar 2012 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz+xeAG6IzwW for ; Thu, 22 Mar 2012 14:31:20 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7A521E802B for ; Thu, 22 Mar 2012 14:31:19 -0700 (PDT) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id WAA01107; Thu, 22 Mar 2012 22:31:14 +0100 (MET) To: robert@raszuk.net From: Ruediger Volk In-Reply-To: Your message of "Thu, 22 Mar 2012 21:40:17 +0100." <4F6B8E31.3010108@raszuk.net> Date: Thu, 22 Mar 2012 22:31:16 +0100 Message-ID: <19249.1332451876@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 21:31:21 -0000 > Hi Doug, > > Actually I am not that concerned what spec will recommend for the > operator to do. I am more concerned what should be the router's default? NO change to current rules! > Considering the example below should it be: To prefer signed longer path > versus unsigned shorter ? leave it entirely to operator to define policy for mapping signed/unsigned/ recieved from friend/received from foe/etc. onto the attribute set used in the path selection algorithm > Specifically I am asking - where does the signed vs unsigned decision > step inserts itself into today's BGP best path decision ? at exactly the same point where the not well known community attributes are used (i.e. NOT in the scope of the standrad bgp path selection algorithm) > Should it be complete haos by allowing full freedom for local operator's > configuration ? Should the default be "Do not care" if this is signed or > unsigned ... just run your BGP best path as today ? don't interfere with whatever chaos (you think) the operator is working with. Just provide the operator with trustworthy information and do not force any nanny on him to help... This does not preclude offering cookbook recipes and providing advice on healthy or unhealthy (e.g. opening opportunities for downgrade attacks...) ways of preparation... Some may feel that offering ways of more flexible or granular decision criteria in the path selection algorithm would be helpful, but that quite certainly should be considered and provided from a more general point of view (as extension in IDR) rather than being a special purpose extension for AS path authenticity. Ruediger From robert@raszuk.net Thu Mar 22 16:28:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4521F84FB for ; Thu, 22 Mar 2012 16:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9PQLkXXvl0A for ; Thu, 22 Mar 2012 16:28:18 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B10B521F84F6 for ; Thu, 22 Mar 2012 16:28:17 -0700 (PDT) Received: (qmail 26691 invoked by uid 399); 22 Mar 2012 23:28:17 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.183.245) by mail1310.opentransfer.com with ESMTPM; 22 Mar 2012 23:28:17 -0000 X-Originating-IP: 83.31.183.245 Message-ID: <4F6BB594.5040202@raszuk.net> Date: Fri, 23 Mar 2012 00:28:20 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ruediger Volk References: <19249.1332451876@x37.NIC.DTAG.DE> In-Reply-To: <19249.1332451876@x37.NIC.DTAG.DE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:28:18 -0000 Hello Ruediger, Many thx for your reply. > don't interfere with whatever chaos (you think) the operator is working with. By chaos I meant complete autonomous selection of what paths are preferred to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and UNSIGNED paths being consider in this _local_ decision as you stated it seems to me just like it is the case with bad uncorrelated policies more harm can be accomplished then good. Are you guaranteeing that such local autonomy how to prefer signed vs unsigned paths is safe in the bigger picture ? > Just provide the operator with trustworthy information While signed BGP information may be made trustworthy I think the end goal is that your customers will get service they pay for meaning that their packets will reach the destination. How singed BGP updates are sufficient to accomplish such goal if anyone on the path by simple static route may overwrite directly in the data plane such trustworthy information and redirect your customer packets left and right without you knowing about it ? Note that such overwrite would not happen if BGP would _always_ advertise only RIB/FIB active routes, but we all know that this is not always the case in some major implementations. Regards, R. From terry.manderson@icann.org Thu Mar 22 16:56:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDF21E801B for ; Thu, 22 Mar 2012 16:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrpNBDc01UTS for ; Thu, 22 Mar 2012 16:56:51 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id CC44221E801A for ; Thu, 22 Mar 2012 16:56:51 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 22 Mar 2012 16:56:51 -0700 From: Terry Manderson To: Eric Osterweil , "Murphy, Sandra" Date: Thu, 22 Mar 2012 16:56:51 -0700 Thread-Topic: [sidr] additional interim meetings Thread-Index: Ac0IW75tVqZFtWbzSoWGaLSriwrHFAAK7TFf Message-ID: In-Reply-To: <6D4CB71B-60D2-4204-B434-BDC7BDE98BC7@verisign.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:56:52 -0000 On 23/03/12 4:43 AM, "Eric Osterweil" wrote: >>=20 >> Comments? >=20 > This is a large amount of travel and I think it unduly reduces the abilit= y of > many of the wg's members to participate at the same level as they do toda= y. I > think this is a bad idea. >=20 I predict travel related to a particular work focus a full 13-15 months in advance of going somewhere, there is generally some contingency, but not to these levels - as I exist as a part of a healthy budget process. I expect many others would be in a similar or worse situation as to their travel flexibility. I accept that the drivers/authors of the BGPSEC work along with chairs and ADs want to maintain momentum - but given the importance of this topic and the many many layers it crosses (in some cases without meaning to), both breadth and depth of participation to produce the best effort (including palatability) result is needed over trying to meet WG milestones. I expect that can only be satisfied with ML participation and IETF attendance. So I also think adding interim meetings is bad. Cheers Terry From christopher.morrow@gmail.com Thu Mar 22 18:05:50 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BFC21E8024 for ; Thu, 22 Mar 2012 18:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5DF+Yvixrxy for ; Thu, 22 Mar 2012 18:05:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0F21E8013 for ; Thu, 22 Mar 2012 18:05:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2251992obb.31 for ; Thu, 22 Mar 2012 18:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=O9wI/A0wp4J4kVGA4WWw6uG3nMhdu+tWLRbe/kkbvzA=; b=WQcp0fgK6ggWRnui35esmP2D1GIfcSP5raq92rQt8FO4lV2hTIyNfzG9JtNHlh/UuJ nbZxeBM8pVtJrav9tZj8xIL/N8Ds4jvxfM5zAYs64hdmuwlbjohplNSbllx4x1C8EvrE T5Edj71n21ZjnwlNEkHNCihdm73XEDFV/WIrmF1qkaGn5xXhV7bHuE4ZP5A7gWoFfQTc g+ZI1P9uwAfsWChaHg4vU1zxUhs4jAwqIoAUdSn7ZbABlMjVVC97Mudfw+FAdNVFfAQQ tlXPkyCW//xWNxXSvasTX221x31tf92BPeU9bNBtViz9WwH8BFduVRSSbU8fhym2B5zO /Sqg== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr12539878obv.41.1332464749186; Thu, 22 Mar 2012 18:05:49 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 22 Mar 2012 18:05:48 -0700 (PDT) In-Reply-To: References: <6D4CB71B-60D2-4204-B434-BDC7BDE98BC7@verisign.com> Date: Thu, 22 Mar 2012 21:05:48 -0400 X-Google-Sender-Auth: 79zP1YDSutg0bEwpErVxSNpqyCo Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:05:50 -0000 On Thu, Mar 22, 2012 at 7:56 PM, Terry Manderson wrote: > I accept that the drivers/authors of the BGPSEC work along with chairs and > ADs want to maintain momentum - but given the importance of this topic and > the many many layers it crosses (in some cases without meaning to), both > breadth and depth of participation to produce the best effort (including > palatability) result is needed over trying to meet WG milestones. I expect > that can only be satisfied with ML participation and IETF attendance. > > So I also think adding interim meetings is bad. significant progress has been made on the topics here because of frequent (monthly about) face-to-face meetings, focused meetings even. Would making the f2f meetings have virtual capabilities be acceptable? (webex or the like, or maybe meeting rooms at diverse locations with that fancy cisco meeting-room thing? or other of the same ilk?) Are there enough central locations to where the folks who want to participate to make more network connected office conversations workable? (sunnyvale/pao/etc + washington + london + ???) -chris From terry.manderson@icann.org Thu Mar 22 18:21:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9721F8484 for ; Thu, 22 Mar 2012 18:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1vf4yXxUhHW for ; Thu, 22 Mar 2012 18:21:50 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B222721F847C for ; Thu, 22 Mar 2012 18:21:50 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 22 Mar 2012 18:21:50 -0700 From: Terry Manderson To: Christopher Morrow Date: Thu, 22 Mar 2012 18:21:49 -0700 Thread-Topic: [sidr] additional interim meetings Thread-Index: Ac0IkSKnhh7P+lhJTJuzQDzWj7DOUQAAi8xR Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:21:51 -0000 Hi Chris, On 23/03/12 11:05 AM, "Christopher Morrow" wrote: >=20 > significant progress has been made on the topics here because of > frequent (monthly about) face-to-face meetings, focused meetings even. Wow.. that is news to me. Are those meetings under the guise of something other than SIDR? Do the SIDR WG chairs attend as WG chairs? How does one get invited to such a meeting? (it appears not to be self selected) and are there minutes/transcripts to those meetings? ok they are in the past, but i= t would help to read minutes/trasnscripts and thus maybe get a finer understanding about why decisions have been made in regard to the solutions presented thus far. > Would making the f2f meetings have virtual capabilities be acceptable? > (webex or the like, or maybe meeting rooms at diverse locations with > that fancy cisco meeting-room thing? or other of the same ilk?) >=20 it depends. bad answer I know. but that's what you get without knowing the agenda, number of participants, history of past meetings etc etc... > Are there enough central locations to where the folks who want to > participate to make more network connected office conversations > workable? (sunnyvale/pao/etc + washington + london + ???) T. From christopher.morrow@gmail.com Thu Mar 22 18:26:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AFD21E803C for ; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=-0.427, BANG_GUAR=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkfdieAJ6q+Y for ; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66921E8024 for ; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2266281obb.31 for ; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=61r2zkPOpzFRkHwZlBIvtKQPMj4vwBsBW8Fr//67raM=; b=zQripyiPnNyVkEAbLCHk8WLTvdQz0cCkEysU3lM0vOPfiv/yPVEP3X4ck0K10LmcI6 hEKTYBHaU/t27GhPNphy7Aze1f2uI22JGGgC1GAaGmnudARPCsPVuev0yNyumG0qkKL7 n9Jh9Ee7GILXQ5f7kQfe8fKmyFU9rG/Iq91i5XoYYZtsmGvKQKF+osGj17Czp13Vp4MY zYG++uZXubOBbFn2bu9TDZsX2RzJOV9uShIkOOBm0v1KOHxI2RCwKp69iZMFxxhaxEdF FouxFfW+hGavU16+8dillfifjtF7YzM1GDraClDdHOQbK1q+Pn7Y+9rTyvhzu7BN//YS XKtQ== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr12288373obz.51.1332465960163; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 22 Mar 2012 18:26:00 -0700 (PDT) In-Reply-To: <4F6BB594.5040202@raszuk.net> References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> Date: Thu, 22 Mar 2012 21:26:00 -0400 X-Google-Sender-Auth: BWJYEtI12yFLYXxZaSlEnYCXq3M Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:26:01 -0000 On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk wrote: > By chaos I meant complete autonomous selection of what paths are preferred > to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and how is the above any different that what happens today? (inside a single ASN, each router decides what it thinks is 'best', hopefully with a coordinated policy across all devices, but ... that is not guaranteed!) > UNSIGNED paths being consider in this _local_ decision as you stated it > seems to me just like it is the case with bad uncorrelated policies more > harm can be accomplished then good. sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME POLICY ON ALL DEVICES!!" ? I think, I thought, I hope that the above message is (perhaps less comically) stated to all network engineers when they graduate and get their striped hats... (so thus NOT a required statement in an RFC-like document) -chris From christopher.morrow@gmail.com Thu Mar 22 18:39:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F87221F84D3 for ; Thu, 22 Mar 2012 18:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G27ppNAt+gS7 for ; Thu, 22 Mar 2012 18:39:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A60621F84CF for ; Thu, 22 Mar 2012 18:39:14 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2275103obb.31 for ; Thu, 22 Mar 2012 18:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rpjBAka+PNFPBBUwc0M6gUGcMDPDPpOFf0o6Ue+4WE0=; b=g8BWu0F58dgDzta+5OS+JQbGSPyi1o6iyrbUpLkycTBzr+lErpcMXNt1YRcnDYvAKx Fhei5tJMRkDgzXmN9ANdp/rv6wzMDj2pWXGwu+rgN09hrzAyQGHD75SDuVZu8CBT5WLd 72tRQ35v48dc8AXrJH0fui0uEvRxojvCoRFPFySdeI2iyMJhknuZ7NHsDQYabCA3v5+c OXARrIVBy/HOsj5aMtLrrayCw0nNbo8WuNgE96N5Ug+3Vl4dyW62C1pVrhpG97qzkDtF BeMnvY6TN0nr5uhJHRCyrblg+N0GzPdJIZRMyOxBleFs+OiHj1rmEpjSzduMXn13PKEL bSMw== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr12339641obb.61.1332466754195; Thu, 22 Mar 2012 18:39:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 22 Mar 2012 18:39:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 21:39:14 -0400 X-Google-Sender-Auth: jTtg5PqV4ThrW6X3O3khsW4QWoc Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:39:19 -0000 On Thu, Mar 22, 2012 at 9:21 PM, Terry Manderson wrote: > Hi Chris, > > On 23/03/12 11:05 AM, "Christopher Morrow" wrot= e: > >> >> significant progress has been made on the topics here because of >> frequent (monthly about) face-to-face meetings, focused meetings even. > > Wow.. that is news to me. Are those meetings under the guise of something > other than SIDR? Do the SIDR WG chairs attend as WG chairs? =A0How does o= ne people attend as people, not as roles, in an attempt to get some progress made. Traditionally these have been all-day-affairs (slog-fests?) > get invited to such a meeting? (it appears not to be self selected) and a= re > there minutes/transcripts to those meetings? ok they are in the past, but= it i believe there are some minutes, I've not read them :( > would help to read minutes/trasnscripts and thus maybe get a finer > understanding about why decisions have been made in regard to the solutio= ns > presented thus far. actually the sriram doc was an attempt at documenting that... it seems some of the reasoning (looking at some of brian.dickson's comments, I think it was him...) could use some fleshing out. It may actually be useful to corner sriram at the next meeting and see if he could expand context where necessary. >> Would making the f2f meetings have virtual capabilities be acceptable? >> (webex or the like, or maybe meeting rooms at diverse locations with >> that fancy cisco meeting-room thing? or other of the same ilk?) >> > > it depends. bad answer I know. but that's what you get without knowing th= e suspected as much :) > agenda, number of participants, history of past meetings etc etc... so... number of participants probably would flex some, eh? and I suspect the agendas could be figured out in advance of each meeting. I also suspect that some of the agenda stuff would have to get done serially? (or that's been the case so far) I suspect (example): april - route-leaks, what/where/how? beaconing, yes? no? impact (with/without?) cpe signing? impacts? costs? need? may - cpe impacts? without beaconing how's that cpe doing? june - route leaks, again, with progress on docs and maths my point I suppose is, nailing down a 13-15month set of agendas doesn't seem practical either... or fanciful at the very least :( You'd probably either end up: "This meeting is coincident with something else I have to be at, extend 1 day =3D=3D win!" and some cases of: "Yea, I can't go to arctic-nog...skip" >> Are there enough central locations to where the folks who want to >> participate to make more network connected office conversations >> workable? (sunnyvale/pao/etc + washington + london + ???) is the idea of showing up in 3 locations close to a majority of participants and participating over video conference laughable or possibly doable? (not just for terry the question here is meant for) -chris From jakob.heitz@ericsson.com Thu Mar 22 18:58:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DBA21E803C for ; Thu, 22 Mar 2012 18:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.319, BANG_GUAR=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZfYzkyb1lud for ; Thu, 22 Mar 2012 18:58:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 662E521E8013 for ; Thu, 22 Mar 2012 18:58:52 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2N1wQTC021412; Thu, 22 Mar 2012 20:58:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.140]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 22 Mar 2012 21:58:32 -0400 From: Jakob Heitz To: Christopher Morrow , "robert@raszuk.net" Date: Thu, 22 Mar 2012 21:58:30 -0400 Thread-Topic: [sidr] Signed vs unsgned and bgp best path decision Thread-Index: Ac0Ik+vINMQHxqRgRk6HVZIH300TrgAAtn2Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3CCC76C0@EUSAACMS0701.eamcs.ericsson.se> References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 01:58:53 -0000 I think this question is more about what step in the route selection process (rfc 4271, 9.1.2.2) at which to consider the verification state. I would answer: nowhere. The verification state should be used as an input to the policy. For example, something for a route-map to match on. The policy would then set another attribute, such as the LOCAL_PREF or deny the path altogether. It may also set a cost community as described in draft-ietf-idr-custom-decision. This resulting attribute would then be used in the route selection process as normal. Exactly how the verification state is used would be up to the network operator. By default, it would not be considered at all. -- Jakob Heitz. -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Chr= istopher Morrow Sent: Thursday, March 22, 2012 6:26 PM To: robert@raszuk.net Cc: sidr@ietf.org list Subject: Re: [sidr] Signed vs unsgned and bgp best path decision On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk wrote: > By chaos I meant complete autonomous selection of what paths are preferre= d > to be chosen as best on an AS by AS basis. In the case of mixed SIGNED an= d how is the above any different that what happens today? (inside a single ASN, each router decides what it thinks is 'best', hopefully with a coordinated policy across all devices, but ... that is not guaranteed!) > UNSIGNED paths being consider in this _local_ decision as you stated it > seems to me just like it is the case with bad uncorrelated policies more > harm can be accomplished then good. sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME POLICY ON ALL DEVICES!!" ? I think, I thought, I hope that the above message is (perhaps less comically) stated to all network engineers when they graduate and get their striped hats... (so thus NOT a required statement in an RFC-like document) -chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From wwwrun@rfc-editor.org Fri Mar 23 01:59:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C021F84E4 for ; Fri, 23 Mar 2012 01:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJvw5m1MaF4L for ; Fri, 23 Mar 2012 01:59:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE3421F84B2 for ; Fri, 23 Mar 2012 01:59:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 959B7B1E002; Fri, 23 Mar 2012 01:57:58 -0700 (PDT) To: gih@apnic.net, stbryant@cisco.com, adrian@olddog.co.uk, Sandra.Murphy@sparta.com, morrowc@ops-netman.net From: RFC Errata System Message-Id: <20120323085758.959B7B1E002@rfc-editor.org> Date: Fri, 23 Mar 2012 01:57:58 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, fortotalanonymity@gmail.com, sidr@ietf.org Subject: [sidr] [Editorial Errata Reported] RFC6485 (3162) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 08:59:08 -0000 The following errata report has been submitted for RFC6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=3162 -------------------------------------- Type: Editorial Reported by: Danny Rios Section: 9 Original Text ------------- 9. Normative References Corrected Text -------------- 8. Normative References Notes ----- Section 8 was incorrectly numbered as section 9 in final RFC. This was due to the draft including a section 7 for "IANA Considerations," which was later removed. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6485 (draft-ietf-sidr-rpki-algs-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From fortotalanonymity@gmail.com Fri Mar 23 02:04:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF60221F8505 for ; Fri, 23 Mar 2012 02:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3M883MAT1IO for ; Fri, 23 Mar 2012 02:04:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E079021F84AE for ; Fri, 23 Mar 2012 02:04:42 -0700 (PDT) Received: by werb10 with SMTP id b10so2973083wer.31 for ; Fri, 23 Mar 2012 02:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6EHR9zouh0RkOBDtlNq59bZFskdwj1KqkfBt4hnX+Vc=; b=QvLgWgKCrvAfXBg167T/v3g3udh4RECFV2KkYI65f5XKzhXeYJrLEihdJvyJ4lQRr6 AlNRDbsLsRmC9p8+fN+uN1ODneR24aa/n2iLO2Ks3tHlVmDxpjPqesRat8XDsN72VjQp sTqmM8cREoUI+Y60isqBcJUCxI7SOkX5MwJnDvBltbJCc3ZIDnci2IopCL+RSRy36+zc QnjFmoorBQ4buMG7AEwrV7sdjaSpDE8g0JGfhDVbgBAhQ5jfhi9R9di+y/D4iC+2ECpU kZeWegtvH+LCnuboO433maXr8NFA0yYiCrxAWtlZvP8V8+H+ovs+qxZTSkWip7tFsok6 cOkQ== MIME-Version: 1.0 Received: by 10.180.80.70 with SMTP id p6mr4544884wix.21.1332493481941; Fri, 23 Mar 2012 02:04:41 -0700 (PDT) Received: by 10.223.89.22 with HTTP; Fri, 23 Mar 2012 02:04:41 -0700 (PDT) In-Reply-To: <20120323085758.959B7B1E002@rfc-editor.org> References: <20120323085758.959B7B1E002@rfc-editor.org> Date: Fri, 23 Mar 2012 02:04:41 -0700 Message-ID: From: Danny Rios To: RFC Errata System Content-Type: multipart/alternative; boundary=f46d04428358a81ad104bbe550ad Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, adrian@olddog.co.uk Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (3162) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:08:12 -0000 --f46d04428358a81ad104bbe550ad Content-Type: text/plain; charset=ISO-8859-1 I'm not precisely sure how this works as it is my first time reporting errata regarding an RFC, but do believe my claim warrants verification. Please get back to me on the process and possible verification. Thank you for your time (all), Danny Rios On Fri, Mar 23, 2012 at 1:57 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC6485, > "The Profile for Algorithms and Key Sizes for Use in the Resource Public > Key Infrastructure (RPKI)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=3162 > > -------------------------------------- > Type: Editorial > Reported by: Danny Rios > > Section: 9 > > Original Text > ------------- > 9. Normative References > > Corrected Text > -------------- > 8. Normative References > > Notes > ----- > Section 8 was incorrectly numbered as section 9 in final RFC. This was due > to the draft including a section 7 for "IANA Considerations," which was > later removed. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6485 (draft-ietf-sidr-rpki-algs-05) > -------------------------------------- > Title : The Profile for Algorithms and Key Sizes for Use in > the Resource Public Key Infrastructure (RPKI) > Publication Date : February 2012 > Author(s) : G. Huston > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > --f46d04428358a81ad104bbe550ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not precisely sure how this works as it is my first time reporting = errata regarding an RFC, but do believe my claim warrants verification. Ple= ase get back to me on the process and possible verification.

    Thank you for your time (all),
    Danny Rios

    On Fri, Mar 23, 2012 at 1:57 AM, RFC Errata System <rfc-editor@rfc-= editor.org> wrote:

    The following errata report has been submitted for RFC6485,
    "The Profile for Algorithms and Key Sizes for Use in the Resource Publ= ic Key Infrastructure (RPKI)".

    --------------------------------------
    You may review the report below and at:
    http://www.rfc-editor.org/errata_search.php?rfc= =3D6485&eid=3D3162

    --------------------------------------
    Type: Editorial
    Reported by: Danny Rios <= fortotalanonymity@gmail.com>

    Section: 9

    Original Text
    -------------
    9. =A0Normative References

    Corrected Text
    --------------
    8. =A0Normative References

    Notes
    -----
    Section 8 was incorrectly numbered as section 9 in final RFC. This was due = to the draft including a section 7 for "IANA Considerations," whi= ch was later removed.

    Instructions:
    -------------
    This errata is currently posted as "Reported". If necessary, plea= se
    use "Reply All" to discuss whether it should be verified or
    rejected. When a decision is reached, the verifying party (IESG)
    can log in to change the status and edit the report, if necessary.

    --------------------------------------
    RFC6485 (draft-ietf-sidr-rpki-algs-05)
    --------------------------------------
    Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The Profile for Algorithms and Key Size= s for Use in the Resource Public Key Infrastructure (RPKI)
    Publication Date =A0 =A0: February 2012
    Author(s) =A0 =A0 =A0 =A0 =A0 : G. Huston
    Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
    Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Secure Inter-Domain Routing
    Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
    Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
    Verifying Party =A0 =A0 : IESG

    --f46d04428358a81ad104bbe550ad-- From tim@ripe.net Fri Mar 23 02:43:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD08F21F844B for ; Fri, 23 Mar 2012 02:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIMTNo6lal3H for ; Fri, 23 Mar 2012 02:43:49 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 4807621F849B for ; Fri, 23 Mar 2012 02:43:49 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SB12B-0004mh-Mx; Fri, 23 Mar 2012 10:43:48 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SB12B-0003ne-HW; Fri, 23 Mar 2012 10:43:47 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--146174442 From: Tim Bruijnzeels In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> Date: Fri, 23 Mar 2012 10:43:47 +0100 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) 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] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071959a1fa945b50c0a25ad0b08ba1077031 Cc: "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:43:55 -0000 --Apple-Mail-1--146174442 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 22 Mar 2012, at 17:07, Murphy, Sandra wrote: > ..... > Interim meetings are not supported by the secretariat, so for = face-face meetings we have to rely on volunteer organizations or hosts. = That will mean that some meetings will have no hosts (virtual) or will = have hosts but be space bounded (limited face-face). Remote = participation will always be available. >=20 > Comments? I do see the point of keeping and improving momentum. Is the biggest problem though that 1 slot providing 2 hours f2f during a = regular IETF is not enough, or is the 4 month interval between f2f = meetings the major issue? I share people's concerns about additional travel, so I would prefer to = go for 2 or even 3 slots at the upcoming IETFs instead. I don't know = what IETF policy is on this, but it's quite clear that there is enough = on the agenda that needs f2f. Tim=20= --Apple-Mail-1--146174442 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii .....
    Interim = meetings are not supported by the secretariat, so for face-face meetings = we have to rely on volunteer organizations or hosts.  That will = mean that some meetings will have no hosts (virtual) or will have hosts = but be space bounded (limited face-face).  Remote participation = will always be = available.

    Comments?

    =
    I do see the point of keeping and improving = momentum.

    Is the biggest problem though that 1 = slot providing 2 hours f2f during a regular IETF is not enough, or is = the 4 month interval between f2f meetings the major = issue?

    I share people's concerns about = additional travel, so I would prefer to go for 2 or even 3 slots at = the upcoming IETFs instead. I don't know what IETF policy is on this, = but it's quite clear that there is enough on the agenda that needs = f2f.


    Tim 
    = --Apple-Mail-1--146174442-- From robert@raszuk.net Fri Mar 23 03:30:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5E21F84D5 for ; Fri, 23 Mar 2012 03:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.417, BANG_GUAR=0.939, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY+z3EG5gUMT for ; Fri, 23 Mar 2012 03:30:31 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32D21F856D for ; Fri, 23 Mar 2012 03:30:31 -0700 (PDT) Received: (qmail 793 invoked by uid 399); 23 Mar 2012 10:30:30 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.122.1) by mail1310.opentransfer.com with ESMTPM; 23 Mar 2012 10:30:30 -0000 X-Originating-IP: 83.9.122.1 Message-ID: <4F6C50C9.8070702@raszuk.net> Date: Fri, 23 Mar 2012 11:30:33 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:30:35 -0000 Chris, I am talking about inter-domain policy not intra-domain. "ACHTUNG" may not help as folks around seem very reluctant to share their internal policies outside. When compared to what is today I don't think folks are mandated by any RFC to make a choice between two attributes which carry the same metric to decide which one should win on a per AS basis. Jakob, > I think this question is more about what step in the route selection > process (rfc 4271, 9.1.2.2) at which to consider the verification state. > > I would answer: nowhere. Really ? Assume there is no policy set by the operator. You have received on your ASBR a net with two paths from two different upstreams. One SIGNED containing sequence of embedded paths with pCounts hacks and the other path with just old plane AS_PATH. First you need to expand internally the signed path to mimic the old AS_PATH format for comparison (both length and content for multipath). So you can't just clearly do nothing with the signed path - I hope we all agree on that. Now let's talk policy. An operator would like to express his policy to mean: "PREFER SIGNED PATHS ONLY IF NOT LONGER THEN NOT SIGNED PATHS" How do you express such policy with local_pref or with cost_community today ? --- While I think it is very easy to say BGPSEC just works as enhancement to today's policy I think I have illustrated above that it is not right analogy in all case. --- Also on the topic of other email reg replace-as functionality I described in http://goo.gl/7aT5c what is router supposed to do when it receives signed as_path and replace-as is in the in/out policy ? Thx, R. > On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk wrote: >> By chaos I meant complete autonomous selection of what paths are preferred >> to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and > > how is the above any different that what happens today? (inside a > single ASN, each router decides what it thinks is 'best', hopefully > with a coordinated policy across all devices, but ... that is not > guaranteed!) > >> UNSIGNED paths being consider in this _local_ decision as you stated it >> seems to me just like it is the case with bad uncorrelated policies more >> harm can be accomplished then good. > > sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME > POLICY ON ALL DEVICES!!" ? > > I think, I thought, I hope that the above message is (perhaps less > comically) stated to all network engineers when they graduate and get > their striped hats... (so thus NOT a required statement in an RFC-like > document) > > -chris > > From christopher.morrow@gmail.com Fri Mar 23 03:44:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1097C21F8505 for ; Fri, 23 Mar 2012 03:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.533 X-Spam-Level: X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arR6y022wXoE for ; Fri, 23 Mar 2012 03:44:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2321F84F5 for ; Fri, 23 Mar 2012 03:44:31 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2700584obb.31 for ; Fri, 23 Mar 2012 03:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=s/NU2FTmb8xVh+kcOZXbfo6gLEiqodYN1KXNcE9koLU=; b=tv4LNiYg0sqkCOlazlQF86acVn5e1pUHEaKBaUI6q32clzabCbrvWYg8YwKMTD/9TI o/NmuFyhuprChTACMUievfxvKeGawvXixG/p642ZZW2XRnGUthlpt5k6pyXCXpi2nCs0 Sk0CqBgSM5vZTCTHOn0vBfT4ZpIoOym5RDVyr5nCKUEzZXzLyHl05aG7q3TzbVkjQPZU rhLxf17ppadhTggTTetZBb/Sdc5DyvQkTH1YNY0qzYQPnTsBSpsQzE33VqqUqfV3qdsJ WxyzUZfEkTyUP+ixzbtmlfMAyrWswVihcpYmeQr+y0B/EQWFR73+XQX3A/MwDdn2asdv 8MOw== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr13633238obz.51.1332499468970; Fri, 23 Mar 2012 03:44:28 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Fri, 23 Mar 2012 03:44:28 -0700 (PDT) In-Reply-To: <4F6C50C9.8070702@raszuk.net> References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> <4F6C50C9.8070702@raszuk.net> Date: Fri, 23 Mar 2012 06:44:28 -0400 X-Google-Sender-Auth: GaofMpD3rY9D4UjperZWveAzlOA Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:44:33 -0000 On Fri, Mar 23, 2012 at 6:30 AM, Robert Raszuk wrote: > Chris, > > I am talking about inter-domain policy not intra-domain. "ACHTUNG" may not > help as folks around seem very reluctant to share their internal policies > outside. sure, interdomain policies today differ between domains... nothing has/will change(d). > When compared to what is today I don't think folks are mandated by any RFC > to make a choice between two attributes which carry the same metric to > decide which one should win on a per AS basis. they are not, and in the future the 'mandate' is I believe a 'SHOULD', not a 'MUST' so not really a 'mandate', but a 'suggestion', eh? It seems that the intent of the effort here is really just to provide an informational blob to the operators which they can use as they see fit... much like other optional transitive attributes today. -chris From robert@raszuk.net Fri Mar 23 03:59:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A2021F8542 for ; Fri, 23 Mar 2012 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljYnBjXM7YPh for ; Fri, 23 Mar 2012 03:59:37 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A076521F8541 for ; Fri, 23 Mar 2012 03:59:37 -0700 (PDT) Received: (qmail 5450 invoked by uid 399); 23 Mar 2012 10:59:36 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.122.1) by mail1310.opentransfer.com with ESMTPM; 23 Mar 2012 10:59:36 -0000 X-Originating-IP: 83.9.122.1 Message-ID: <4F6C579A.5080702@raszuk.net> Date: Fri, 23 Mar 2012 11:59:38 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> <4F6C50C9.8070702@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:59:38 -0000 >> When compared to what is today I don't think folks are mandated by any RFC >> to make a choice between two attributes which carry the same metric to >> decide which one should win on a per AS basis. > > they are not, and in the future the 'mandate' is I believe a 'SHOULD', > not a 'MUST' so not really a 'mandate', but a 'suggestion', eh? > > It seems that the intent of the effort here is really just to provide > an informational blob to the operators which they can use as they see > fit... much like other optional transitive attributes today. Ok that sounds very reasonable indeed. However number of folks have stated that bgpsec protocol proposal calls for replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig attribute. In particular this text from /draft-ietf-sidr-bgpsec-protocol-02 sort of suggests that: The other option is that the BGPSEC speaker discards anything in the AS_PATH attribute and reconstructs the AS_PATH from the data in the BGPSEC_Path_Signatures attribute. I believe that there are no interoperability problems if the choice between these two options is left up to the BGPSEC speaker. Also it says in the same section 5: One option the BGPSEC speaker checks the AS_PATH attribute against the information in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the two do not match. That means that if AS_PATH for example contains AS_SET that someone doing BGP multipath (across non identical paths) has correctly inserted into AS_PATH or as mentioned before did replace-as the update will be dropped as BGPSEC just can not handle those .... Meta question: Can optional attribute result in such drastic actions (nothing to do with operator's choice of local behavior) against mandatory attribute(s) ? Best, R. From christopher.morrow@gmail.com Fri Mar 23 04:32:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB79F21F8527 for ; Fri, 23 Mar 2012 04:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYfdrtEcx46K for ; Fri, 23 Mar 2012 04:32:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99521F851D for ; Fri, 23 Mar 2012 04:32:55 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2739503obb.31 for ; Fri, 23 Mar 2012 04:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sA535UB1ld5rRMmVjAWtEAxGaJXsqiTCXHxrwgkRdVs=; b=fSCIfxGdtxAS1+D9SHXhNDO20+Ae0oUQTDsH74t96/mPOaKLgpkWGNemDPeRuH9IM/ sKzkBB8YvFouSSVEXu1h636Ne48SC5TrGFfZFCdC7igmnKTiXaa09fjxyPaG1oSD5+sf tv/7bH8q17VIlO3sngMTikuulQ5FkMCzxNyPYX4Bw6jjHvhgDDeTS0UN9gIr3C4klf5H b6qFBnSo1VfgAt14che128KJFfmmXf0iYYVYRY3QRSb1GaGX1JVux5mkVgPXi0VXgZ6n khssmzL5vdlntLCbPRrm2rdyUx3oIkD7lezAjAOAClc7pWYaziJqyNG3Zo0TJPQ4YLAr eikg== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr13845572obb.61.1332502374789; Fri, 23 Mar 2012 04:32:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Fri, 23 Mar 2012 04:32:54 -0700 (PDT) In-Reply-To: <4F6C579A.5080702@raszuk.net> References: <19249.1332451876@x37.NIC.DTAG.DE> <4F6BB594.5040202@raszuk.net> <4F6C50C9.8070702@raszuk.net> <4F6C579A.5080702@raszuk.net> Date: Fri, 23 Mar 2012 07:32:54 -0400 X-Google-Sender-Auth: Kby9s0dY6vWCJ_OT2ODhSMFWEo0 Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] Signed vs unsgned and bgp best path decision X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:32:55 -0000 On Fri, Mar 23, 2012 at 6:59 AM, Robert Raszuk wrote: > >>> When compared to what is today I don't think folks are mandated by any >>> RFC >>> to make a choice between two attributes which carry the same metric to >>> decide which one should win on a per AS basis. >> >> >> they are not, and in the future the 'mandate' is I believe a 'SHOULD', >> not a 'MUST' so not really a 'mandate', but a 'suggestion', eh? >> >> It seems that the intent of the effort here is really just to provide >> an informational blob to the operators which they can use as they see >> fit... much like other optional transitive attributes today. > > > Ok that sounds very reasonable indeed. progress! > However number of folks have stated that bgpsec protocol proposal calls f= or > replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig attribute.= In > particular this text from /draft-ietf-sidr-bgpsec-protocol-02 sort of > suggests that: > > =A0 The other option is that the BGPSEC speaker 'other option' > =A0 discards anything in the AS_PATH attribute and reconstructs the I believe this means: "You could just ignore AS_PATH and reconstruct the content there from ..." (or that's how I read the clipping) > =A0 AS_PATH from the data in the BGPSEC_Path_Signatures attribute. =A0I > =A0 believe that there are no interoperability problems if the choice > =A0 between these two options is left up to the BGPSEC speaker. probably in this last sentence they mean "bgpsec listener" (since this is on the receiver, not the sender?) > Also it says in the same section 5: > > =A0 One option the 'option' > =A0 BGPSEC speaker checks the AS_PATH attribute against the information > =A0 in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the > =A0 two do not match. > > That means that if AS_PATH for example contains AS_SET that someone doing > BGP multipath (across non identical paths) has correctly inserted into > AS_PATH or as mentioned before did replace-as the update will be dropped = as > BGPSEC just can not handle those .... sure. 'option' I don't think if there were an AS_SET in the update coming from the BGPSEC speaking peer there would be sig parts to worry about (since the inclusion of AS_SET means you can't secure the path...So, I suppose if this condition exists the path is invalid by default? and likely spoof/bad/malicious?) > > > Meta question: > > Can optional attribute result in such drastic actions (nothing to do with > operator's choice of local behavior) against mandatory attribute(s) ? I think you created a situation which is actually in violation of the standard... or which would be seen as a malicious update and which should be dropped, so I'm not sure your meta-question follows properly here? -chris From henk.uijterwaal@gmail.com Fri Mar 23 06:01:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84321F8526 for ; Fri, 23 Mar 2012 06:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MEJgAraL0Ke for ; Fri, 23 Mar 2012 06:01:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0421F8514 for ; Fri, 23 Mar 2012 06:01:23 -0700 (PDT) Received: by eaaq11 with SMTP id q11so995091eaa.31 for ; Fri, 23 Mar 2012 06:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rgpChA9N0SE8YMBj8JP4F0rJ22Sk2LgAYJbqhSo0eb8=; b=o5cHlyoDgoagh0AxPrypAlhzXt5WiVwdb+0F1vLz3950oTTKNEhQbp2AKlbr8LaXTa aJxNlPPRv4iCaCM2JIM2mui4erI4g5Ux2hxgASWL25S150bEFY+epj2Qmci/F4legjLL gufW0M6n+24uDnsNhdyns2Iqua9fbZUmQQ6nC+cqQD5zQzDXhkX3jaHtop60UU0LFUxo Yrqf3hoBla4I9dmwGdtilXKUI69dBK2cjl7W0r8kRVs9U8W+HigV6g0P3oj3L0+frHq6 aTko7RqGqhMIq8A1kXuW+h0X20lFT50x5C1S5r2YoDgFjYr4hzH7hAE+tGRUeTihjlAh 2O1w== Received: by 10.213.14.11 with SMTP id e11mr879724eba.95.1332507683108; Fri, 23 Mar 2012 06:01:23 -0700 (PDT) Received: from geir.local ([2001:980:1203:1:e6ce:8fff:fe11:e7a8]) by mx.google.com with ESMTPS id n56sm27971813eeb.4.2012.03.23.06.01.21 (version=SSLv3 cipher=OTHER); Fri, 23 Mar 2012 06:01:22 -0700 (PDT) Message-ID: <4F6C741F.3020309@gmail.com> Date: Fri, 23 Mar 2012 14:01:19 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: henk@uijterwaal.nl List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:01:28 -0000 Hi Tim, > I share people's concerns about additional travel, so I would prefer to go for 2 > or even 3 slots at the upcoming IETFs instead. I don't know what IETF policy is > on this, but it's quite clear that there is enough on the agenda that needs f2f. The IETF has a limited number of slots (150 or so) and about as many working groups. That gives about 1 slot to each WG, a second slot is only granted after all requests for a 1st slot have been met. That makes it hard to plan for multiple slots during the week, as it isn't clear that the 2nd slot will be available. The solution is to have a meeting the day before or after the meeting, like the meeting that was cancelled. Then a slot is guaranteed, the additional costs are small for the participants. This is allowed if the request is made on time. In the past we have done this, with a friendly RIR footing the bill for the room and the coffee. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From wesley.george@twcable.com Fri Mar 23 07:21:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B721F8455 for ; Fri, 23 Mar 2012 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOGNie1AUGAv for ; Fri, 23 Mar 2012 07:21:22 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE621F8566 for ; Fri, 23 Mar 2012 07:21:21 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,636,1325480400"; d="scan'208";a="357945716" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Mar 2012 10:20:19 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 23 Mar 2012 10:21:08 -0400 From: "George, Wes" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Fri, 23 Mar 2012 10:21:11 -0400 Thread-Topic: additional interim meetings Thread-Index: Ac0IGYH/rfSTTc18SE+RRljzGrxz8gA4/x5Q Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:21:23 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Thursday, March 22, 2012 12:08 PM > To: sidr@ietf.org > Subject: [sidr] additional interim meetings > > Interim meetings would be face-face meetings co-located with venues of > communities of interest to this work (ie nanog, ripe, arin, etc.) when > facilities are volunteered, or virtual meetings when volunteer hosts can = not > be found. > [WEG] I think I'd rather see these be planned as solely virtual meetings wh= en they are not collocated with another event which contains an audience we= 'd like to engage (either current SIDR participants or "tourists" whose inp= ut would be valuable). Personally, I'm already approaching the maximum amou= nt of travel that I can do and still keep my happy home, well, happy, so ca= rving out time for separate trips even for short-duration things like this = is less than preferable. Finances are a consideration as well. I'm respondi= ng with some ideas about virtual meetings in another reply. > The idea is to meet to discuss thorny topics at length. Agendas announce= d > ahead of time, remote participation always available, minutes reported to= the > wg, proceedings published. When webex is used, recordings will be taken. [WEG] Generally, I think that the topics proposed are important, and would = benefit from discussion beyond the typical few hours at IETF meetings or 20= 0+ message threads, so I support the idea of some focused time outside of I= ETF meetings. However, I'm not convinced that monthly is necessary. It may = be that they are scheduled with that frequency and we do some agenda bashin= g to make sure that people can attend the things that they have opinions ab= out without needing to commit one full day a month to this. When one consid= ers keeping up with the rest of IETF + $day_job, that starts to get difficu= lt in a hurry. > > Here is a suggested semi-schedule for the next several months. > > 30 April (chosen so as not to conflict with RIPE or ARIN in the preceding > weeks) (Likely important topic - the government oversight concerns at RI= PE > and mitigating possibilities, impacts of the ARIN and RIPE meeting) [WEG] prefer virtual > > 6 Jun, co-located with NANOG (that is the Wed after NANOG ends - there ar= e > indications that nanog may be able to lend a room after noon.) [WEG] Makes sense, please publicize WELL (6wks+) in advance on NANOG so tha= t people in the operations community who aren't paying attention to SIDR ca= n make plans to attend, focus the agenda on operational considerations. > > the last part of June: 25 Jun - 3 July [WEG] I'm not convinced we need this one, and summer scheduling is problema= tic due to vacation. We may have to wait and see what comes of the previous= few before determining if we need another one prior to IETF. > > at one end or the other of the IETF (sort of like iegp meets at IETFs) in= July [WEG] Manageable as long as the date is set before people make travel plans= , probably at least 6 weeks out, preferably 8. Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Fri Mar 23 07:36:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8B21F851A for ; Fri, 23 Mar 2012 07:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlf1oVRqMpGQ for ; Fri, 23 Mar 2012 07:36:24 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id ECA5221F8518 for ; Fri, 23 Mar 2012 07:36:23 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,636,1325480400"; d="scan'208";a="341532509" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 23 Mar 2012 10:35:51 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 23 Mar 2012 10:36:20 -0400 From: "George, Wes" To: Christopher Morrow Date: Fri, 23 Mar 2012 10:36:22 -0400 Thread-Topic: [sidr] additional interim meetings Thread-Index: Ac0IlcaxuEyYJJZRTyKSJuJsiygzBAAZkW0Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:36:24 -0000 > >> Are there enough central locations to where the folks who want to > >> participate to make more network connected office conversations > >> workable? (sunnyvale/pao/etc + washington + london + ???) > > is the idea of showing up in 3 locations close to a majority of > participants and participating over video conference laughable or > possibly doable? [WEG] well, I think that videoconf would be an acceptable option, assuming = we can cobble together the right set of multi-location supporting gear amon= g the candidate locations. Other than those pesky timezones, the problem we= run into with coordinated virtual meetings of this type is usually one of = poor execution of the technology - e.g. systems that can only talk to other= identical systems within the company network (no external/interwork suppor= t), huge rooms without appropriate mics/speakers to make a video or audio c= onf anything other than frustrating, or systems that aren't capable of mana= ging a presentation + a speaker video at the same time, etc. We won't know unless we try it, and I think that we should. The worst that = happens is that we decide it's not worth the hassle in the future and simpl= y rely on the built-in support for webcams in things like Webex in lieu of = videoconf. The benefit of having it in a physical location is that it helps= to reduce distractions and let us focus on what we're actually there to do= . I would assume that if Cisco is willing to volunteer the resources for its = customers' use, there are likely telepresence rooms in the Cisco offices co= nvenient to nearly all of us, and that's a system that I know from personal= experience would work for this type of thing. The challenges are that ther= e is an 8-10 person limit to the rooms, meaning that some of the areas with= larger clusters of folks might need multiple rooms, and it's typically dif= ficult to schedule that many simultaneous rooms for any length of time with= out doing so months in advance. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Fri Mar 23 08:08:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D1D21F847E for ; Fri, 23 Mar 2012 08:08:45 -0700 (PDT) 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=[AWL=-0.239, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVCo5SvSSgMW for ; Fri, 23 Mar 2012 08:08:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9A21F8599 for ; Fri, 23 Mar 2012 08:08:44 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,636,1325480400"; d="scan'208";a="357977419" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Mar 2012 11:07:55 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 23 Mar 2012 11:08:44 -0400 From: "George, Wes" To: "henk@uijterwaal.nl" , "sidr@ietf.org" Date: Fri, 23 Mar 2012 11:08:47 -0400 Thread-Topic: [sidr] additional interim meetings Thread-Index: Ac0I9SGwFanPVVDYT7SfdIbt1uSuCQAEK+8Q Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> <4F6C741F.3020309@gmail.com> In-Reply-To: <4F6C741F.3020309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:08:45 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of H= enk > Uijterwaal > Sent: Friday, March 23, 2012 9:01 AM > To: sidr@ietf.org > Subject: Re: [sidr] additional interim meetings > > > The IETF has a limited number of slots (150 or so) and about as many work= ing > groups. That gives about 1 slot to each WG, a second slot is only grante= d > after > all requests for a 1st slot have been met. That makes it hard to plan fo= r > multiple slots during the week, as it isn't clear that the 2nd slot will > be available. > [WEG] One point to make here... I think you're overselling the difficulty o= f requesting and receiving additional slots when they are all requested at = the same time, rather than retroactively as was done this time. Yes by stri= ct math you're correct, but rarely do all of the WGs meet. Once the agenda = is set, you know how many sessions you have, it's not like the add'l sessio= ns are scheduled after the agenda is set. V6ops has consistently had 2 sess= ions per IETF, and was up to 3 sessions in one IETF before a number of folk= s told the chairs that this was excessive and that we needed to better mana= ge what was actually getting agenda time. So it can be done. Really, the problem with multiple sessions is that they are opposite 7 othe= r WG meetings no matter what their timeslot, meaning that it becomes increa= singly difficult to deconflict time for those who need to attend. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Sandra.Murphy@sparta.com Fri Mar 23 17:29:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ABB21E8085 for ; Fri, 23 Mar 2012 17:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjMvFRwXhe6G for ; Fri, 23 Mar 2012 17:29:09 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E27921E800F for ; Fri, 23 Mar 2012 17:29:09 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2O0T833023518 for ; Fri, 23 Mar 2012 19:29:08 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2O0T8Ma002836 for ; Fri, 23 Mar 2012 19:29:08 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 20:29:07 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: sidr meetings, Monday and Wednesday Thread-Index: Ac0JVR3GCaTenUHpSUurZzvcqYedOg== Date: Sat, 24 Mar 2012 00:29:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C9977@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] sidr meetings, Monday and Wednesday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 00:29:10 -0000 The Secretariat confirmed today that the sidr meeting will have the slot on= Monday 1300-1500 vacated by EAI.=0A= =0A= The IETF agenda site is not yet updated with this information, as they must= also do a room change.=0A= =0A= Brian Dickson has agreed to move his presentation to the Monday time slot. = =0A= =0A= Unfortunately I got word today (Friday) from another author that there was = no way to move his presentation to Monday. Therefore, I am checking with o= ther authors to see what presentations can move to Monday.=0A= =0A= So expect a change in agenda to be announced soon.=0A= =0A= --Sandy, speaking as wg co-chair= From Sandra.Murphy@sparta.com Fri Mar 23 17:45:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3215F21E8034 for ; Fri, 23 Mar 2012 17:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28QqNNW8Y+Vs for ; Fri, 23 Mar 2012 17:45:18 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 426B621E800F for ; Fri, 23 Mar 2012 17:45:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2O0jHvk023568 for ; Fri, 23 Mar 2012 19:45:17 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2O0jHPf002993 for ; Fri, 23 Mar 2012 19:45:17 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 20:45:17 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: get slides to chairs early Thread-Index: AQHNCVdhTDky/ngFlkK+V7TC2zKflA== Date: Sat, 24 Mar 2012 00:45:15 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C9989@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] get slides to chairs early X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 00:45:19 -0000 Slides need to be uploaded to the meetings materials site before the meetin= g. The chair laptops will be busy, so if you walk in with a memory stick, = you may be speaking to a blank screen.=0A= =0A= So presenters on Wednesday, please have your slides to the wg chairs by mid= night Wed morning IETF local time.=0A= =0A= Presenters on Monday - you get a bit more time, since the Monday wg agenda = is not yet set. But please - have slides to the wg chairs by 9am IETF loca= l time.=0A= =0A= --Sandy= From randy@psg.com Fri Mar 23 21:28:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364B021E804A for ; Fri, 23 Mar 2012 21:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vut71etHzwcZ for ; Fri, 23 Mar 2012 21:28:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5AE21E802C for ; Fri, 23 Mar 2012 21:28:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SBIaY-00060y-Uk; Sat, 24 Mar 2012 04:28:27 +0000 Date: Sat, 24 Mar 2012 05:28:25 +0100 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C9977@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C9977@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (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 Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr meetings, Monday and Wednesday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 04:28:32 -0000 > Unfortunately I got word today (Friday) from another author that there > was no way to move his presentation to Monday. Therefore, I am > checking with other authors to see what presentations can move to > Monday. i think pfx-validate is not well understood. i did send some slides around, but from questions i am getting, some of the details and implications of 'covered', 'matched', and multiple roas are not as clear as they might be. i could do it in ten minutes. randy From christopher.morrow@gmail.com Sat Mar 24 03:18:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2121F845C for ; Sat, 24 Mar 2012 03:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS70-48BOfra for ; Sat, 24 Mar 2012 03:18:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C512121F8459 for ; Sat, 24 Mar 2012 03:18:55 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3761751obb.31 for ; Sat, 24 Mar 2012 03:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YkMCV8e/BvvMX1CTmy9Tu8nwm6rGX/gZjgmiWvVIBGo=; b=Na41IxK2KgqOywiE2ppgo4UwJa82n88I8ZSWiYfEuhrBpnMUHkQGUk0pQOGFlyaiaB R7itRmqfOtU3d+iE3bVJReSccWbZ5i7R9qzPw8aopi6t7Lvhjch0dVNuoui/zpm2uj0B Np4CLwAsQMJodYFWgev5BUESWKjfaRI9+SRV576qrnXM/juJRwVMs5MBfkwnhsIZOLGd v61zgr24sFWpfjxdzaqewtMPPY/JQfLbz0pWpCSCVSKMGxsBmo0eIcP5Vsicc+H0lQGb KLtt8Gv0oOf+6D2Uyf6BNEFloXp39ME1evth5Rn9iVqfP5WLaY5M/KdMY19F5YcvSO3+ xQSQ== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr18091208oei.71.1332584335298; Sat, 24 Mar 2012 03:18:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Sat, 24 Mar 2012 03:18:55 -0700 (PDT) In-Reply-To: <4F5E58EF.2000908@ieca.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> Date: Sat, 24 Mar 2012 06:18:55 -0400 X-Google-Sender-Auth: htPhatHma9vNlND--eh7NnviaF0 Message-ID: From: Christopher Morrow To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 10:18:56 -0000 Hey folk, Is this draft stating something obvious and doesn't need to be documented? or are we in need of this doc to keep us all on the same page (us =3D=3D ops + vendors) as to getting a cert created and installed on our lovely devices? If people could take a few minutes to read the 4 pages (minus boilerplate) and think/comment that would be nice. (for the record, it seems like documenting this is a good thing, from my perspective.) -chris On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: > Well I'd like to see it adopted and I promise to work on it ;) > > spt > > > On 3/7/12 6:07 PM, Murphy, Sandra wrote: >> >> An alert eye pointed out that the URL below is incorrect. =A0The correct >> pointer is >> >> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >> >> --Sandy, speaking as clumsy wg co-chair >> >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, >> Sandra [Sandra.Murphy@sparta.com] >> Sent: Wednesday, March 07, 2012 5:40 PM >> To: sidr@ietf.org >> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.t= xt >> >> The following request has been made for wg adoption of >> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >> >> The draft is available at >> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >> >> Please respond to the list to say whether you accept this draft as a >> working group draft and are willing to work on it. Remember that you do = not >> need to accept all content in a draft to adopt, as draft editors are >> required to reflect the consensus of the working group. >> >> This call will end 21 Mar 2012. >> >> --Sandy, speaking as wg co-chair >> >> >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy >> Bush [randy@psg.com] >> Sent: Monday, March 05, 2012 8:54 PM >> To: sidr wg list >> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >> >> chairs, please consider as a wg work item. =A0thanks. >> >> randy >> >> --- >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >> draft-ymbk-bgpsec-rtr-rekeying-00.txt >> >> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >> succes=3D >> sfully submitted by Sean Turner and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0 =A0draft-ymbk-bgpsec-rtr-rekeying >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 Router Keying for BGPsec >> Creation date: =A0 2012-03-05 >> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 7 >> >> Abstract: >> =A0 =A0BGPsec-speaking routers must be provisioned with private keys and= the >> =A0 =A0corresponding public key must be published in the global Resource >> =A0 =A0PKI. =A0This document describes two ways of doing so, router-driv= en and >> =A0 =A0operator-driven. >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 From sra@hactrn.net Sat Mar 24 05:33:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784F821F86C4 for ; Sat, 24 Mar 2012 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BU0UaOyfiTF for ; Sat, 24 Mar 2012 05:33:56 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25D21F86B9 for ; Sat, 24 Mar 2012 05:33:56 -0700 (PDT) Received: from minas-ithil.hactrn.net (unknown [74.125.57.242]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id DA00D28465 for ; Sat, 24 Mar 2012 12:33:53 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 6A05E6E06DE for ; Sat, 24 Mar 2012 13:33:52 +0100 (CET) Date: Sat, 24 Mar 2012 13:33:52 +0100 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.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: <20120324123352.6A05E6E06DE@minas-ithil.hactrn.net> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:33:57 -0000 Have read and support adoption. From mlepinski@bbn.com Sat Mar 24 05:52:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BCE21F86C4 for ; Sat, 24 Mar 2012 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrRP4l4850E3 for ; Sat, 24 Mar 2012 05:52:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B039721F855B for ; Sat, 24 Mar 2012 05:52:28 -0700 (PDT) Received: from [128.89.254.144] (port=49522) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SBQS6-0000DD-GF for sidr@ietf.org; Sat, 24 Mar 2012 08:52:14 -0400 Message-ID: <4F6DC38A.3080707@bbn.com> Date: Sat, 24 Mar 2012 08:52:26 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:52:29 -0000 I have read now this document. The issues discussed in this document are issues should be documented somewhere. (It is possible that this could be rolled into another document, since its short, but this stuff definitely should be documented in some product of the SIDR working group) I really appreciate that the authors took the time to document these issues. On 3/24/2012 6:18 AM, Christopher Morrow wrote: > > Hey folk, > Is this draft stating something obvious and doesn't need to be > documented? or are we in need of this doc to keep us all on the same > page (us == ops + vendors) as to getting a cert created and installed > on our lovely devices? > > If people could take a few minutes to read the 4 pages (minus > boilerplate) and think/comment that would be nice. > > (for the record, it seems like documenting this is a good thing, from > my perspective.) > > -chris > > On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: >> Well I'd like to see it adopted and I promise to work on it ;) >> >> spt >> >> >> On 3/7/12 6:07 PM, Murphy, Sandra wrote: >>> An alert eye pointed out that the URL below is incorrect. The correct >>> pointer is >>> >>> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >>> >>> --Sandy, speaking as clumsy wg co-chair >>> >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, >>> Sandra [Sandra.Murphy@sparta.com] >>> Sent: Wednesday, March 07, 2012 5:40 PM >>> To: sidr@ietf.org >>> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt >>> >>> The following request has been made for wg adoption of >>> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >>> >>> The draft is available at >>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >>> >>> Please respond to the list to say whether you accept this draft as a >>> working group draft and are willing to work on it. Remember that you do not >>> need to accept all content in a draft to adopt, as draft editors are >>> required to reflect the consensus of the working group. >>> >>> This call will end 21 Mar 2012. >>> >>> --Sandy, speaking as wg co-chair >>> >>> >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy >>> Bush [randy@psg.com] >>> Sent: Monday, March 05, 2012 8:54 PM >>> To: sidr wg list >>> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >>> >>> chairs, please consider as a wg work item. thanks. >>> >>> randy >>> >>> --- >>> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>> >>> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >>> succes= >>> sfully submitted by Sean Turner and posted to the IETF repository. >>> >>> Filename: draft-ymbk-bgpsec-rtr-rekeying >>> Revision: 00 >>> Title: Router Keying for BGPsec >>> Creation date: 2012-03-05 >>> WG ID: Individual Submission >>> Number of pages: 7 >>> >>> Abstract: >>> BGPsec-speaking routers must be provisioned with private keys and the >>> corresponding public key must be published in the global Resource >>> PKI. This document describes two ways of doing so, router-driven and >>> operator-driven. >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> 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 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From wesley.george@twcable.com Sat Mar 24 06:33:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21A821F86C4 for ; Sat, 24 Mar 2012 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFae+Frf-OAR for ; Sat, 24 Mar 2012 06:33:41 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 148E121F870F for ; Sat, 24 Mar 2012 06:33:41 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,641,1325480400"; d="scan'208";a="341982577" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 09:33:07 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Sat, 24 Mar 2012 09:33:40 -0400 From: "George, Wes" To: Christopher Morrow , Sean Turner Date: Sat, 24 Mar 2012 09:33:38 -0400 Thread-Topic: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt Thread-Index: Ac0Jp4goa8lK1p19QsGN6KUHtJFQlQAGqVJA Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 13:33:42 -0000 Yes, support. Anything that teaches router jockeys how to wrangle keys and = not compromise the security of the system in the process is a good thing IM= O. Though I'm wondering if perhaps this doc and bgpsec-rollover should be inte= grated Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Saturday, March 24, 2012 6:19 AM > To: Sean Turner > Cc: Murphy, Sandra; sidr@ietf.org > Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-0= 0.txt > > > Hey folk, > Is this draft stating something obvious and doesn't need to be > documented? or are we in need of this doc to keep us all on the same > page (us =3D=3D ops + vendors) as to getting a cert created and installed > on our lovely devices? > > If people could take a few minutes to read the 4 pages (minus > boilerplate) and think/comment that would be nice. > > (for the record, it seems like documenting this is a good thing, from > my perspective.) > > -chris > > On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: > > Well I'd like to see it adopted and I promise to work on it ;) > > > > spt > > > > > > On 3/7/12 6:07 PM, Murphy, Sandra wrote: > >> > >> An alert eye pointed out that the URL below is incorrect. The correct > >> pointer is > >> > >> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 > >> > >> --Sandy, speaking as clumsy wg co-chair > >> > >> ________________________________________ > >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murph= y, > >> Sandra [Sandra.Murphy@sparta.com] > >> Sent: Wednesday, March 07, 2012 5:40 PM > >> To: sidr@ietf.org > >> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00= .txt > >> > >> The following request has been made for wg adoption of > >> draft-ymbk-bgpsec-rtr-rekeying-00.txt. > >> > >> The draft is available at > >> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. > >> > >> Please respond to the list to say whether you accept this draft as a > >> working group draft and are willing to work on it. Remember that you d= o not > >> need to accept all content in a draft to adopt, as draft editors are > >> required to reflect the consensus of the working group. > >> > >> This call will end 21 Mar 2012. > >> > >> --Sandy, speaking as wg co-chair > >> > >> > >> ________________________________________ > >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy > >> Bush [randy@psg.com] > >> Sent: Monday, March 05, 2012 8:54 PM > >> To: sidr wg list > >> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt > >> > >> chairs, please consider as a wg work item. thanks. > >> > >> randy > >> > >> --- > >> > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for > >> draft-ymbk-bgpsec-rtr-rekeying-00.txt > >> > >> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been > >> succes=3D > >> sfully submitted by Sean Turner and posted to the IETF repository. > >> > >> Filename: draft-ymbk-bgpsec-rtr-rekeying > >> Revision: 00 > >> Title: Router Keying for BGPsec > >> Creation date: 2012-03-05 > >> WG ID: Individual Submission > >> Number of pages: 7 > >> > >> Abstract: > >> BGPsec-speaking routers must be provisioned with private keys and t= he > >> corresponding public key must be published in the global Resource > >> PKI. This document describes two ways of doing so, router-driven a= nd > >> operator-driven. > >> _______________________________________________ > >> 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 > >> _______________________________________________ > >> 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 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Sat Mar 24 06:42:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8BE21F8711 for ; Sat, 24 Mar 2012 06:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg6iEWIG2BZe for ; Sat, 24 Mar 2012 06:42:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9921F870F for ; Sat, 24 Mar 2012 06:42:16 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3906465obb.31 for ; Sat, 24 Mar 2012 06:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fY1SzvIAmQ+LzBY5rn6U8GUEeIHL8PkCOoOQ6n9JYgM=; b=rGjURjx0ZLlNXpJEa+FTcSeVsz0HCrEi+7tG3xaaYHcaVlEuY+acZIlUil7c4Q64Ru zlTyBi2Y981D+iZim/HgBSW3uFQFNB5tT5gFc63wlem5Hv7MF2/mREFaDXHsmiu66rTa kOau8reE88Ic2FRwSHmHCAZHE3gRcXwNS7qR3xds3Q+1UlPg9D/O51xObGeOhEGO5nVm I633mvC8l57kF17RIuVhQN01dV73+hibyup7qP2w7DDIqMMjddZN4d/9vKenrG7OLprY fgT2LAAei31z+sgqx68oHjz8scpjny2ohA+GrXvsAoY2+r79wkuox+H/ymUAJPOOY0V7 f9yA== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr19280645obb.71.1332596536444; Sat, 24 Mar 2012 06:42:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Sat, 24 Mar 2012 06:42:16 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> Date: Sat, 24 Mar 2012 09:42:16 -0400 X-Google-Sender-Auth: feiLbQcZIR7EvG9823K0XKHyloY Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 13:42:18 -0000 On Sat, Mar 24, 2012 at 9:33 AM, George, Wes wr= ote: > Yes, support. Anything that teaches router jockeys how to wrangle keys an= d not compromise the security of the system in the process is a good thing = IMO. > > Though I'm wondering if perhaps this doc and bgpsec-rollover should be in= tegrated interesting... so you mean: or something else? I think a doc just talking about 'network equipment handling of certs' is good, mingling in with 'if I want to roll the key on my CA, I do ...' seems like hiding the sausage in the wrong place. (or maybe not the wrong place, but not the right one either....) Sure, the 2 items are potentially linked, but... the CA bits cover a lot more ground, so I would say more chance for confusion and mistakes due to complexity. -chris >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >> Christopher Morrow >> Sent: Saturday, March 24, 2012 6:19 AM >> To: Sean Turner >> Cc: Murphy, Sandra; sidr@ietf.org >> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-= 00.txt >> >> >> Hey folk, >> Is this draft stating something obvious and doesn't need to be >> documented? or are we in need of this doc to keep us all on the same >> page (us =3D=3D ops + vendors) as to getting a cert created and installe= d >> on our lovely devices? >> >> If people could take a few minutes to read the 4 pages (minus >> boilerplate) and think/comment that would be nice. >> >> (for the record, it seems like documenting this is a good thing, from >> my perspective.) >> >> -chris >> >> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: >> > Well I'd like to see it adopted and I promise to work on it ;) >> > >> > spt >> > >> > >> > On 3/7/12 6:07 PM, Murphy, Sandra wrote: >> >> >> >> An alert eye pointed out that the URL below is incorrect. =A0The corr= ect >> >> pointer is >> >> >> >> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >> >> >> >> --Sandy, speaking as clumsy wg co-chair >> >> >> >> ________________________________________ >> >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murp= hy, >> >> Sandra [Sandra.Murphy@sparta.com] >> >> Sent: Wednesday, March 07, 2012 5:40 PM >> >> To: sidr@ietf.org >> >> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-0= 0.txt >> >> >> >> The following request has been made for wg adoption of >> >> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >> >> >> >> The draft is available at >> >> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >> >> >> >> Please respond to the list to say whether you accept this draft as a >> >> working group draft and are willing to work on it. Remember that you = do not >> >> need to accept all content in a draft to adopt, as draft editors are >> >> required to reflect the consensus of the working group. >> >> >> >> This call will end 21 Mar 2012. >> >> >> >> --Sandy, speaking as wg co-chair >> >> >> >> >> >> ________________________________________ >> >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Rand= y >> >> Bush [randy@psg.com] >> >> Sent: Monday, March 05, 2012 8:54 PM >> >> To: sidr wg list >> >> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >> >> >> >> chairs, please consider as a wg work item. =A0thanks. >> >> >> >> randy >> >> >> >> --- >> >> >> >> From: internet-drafts@ietf.org >> >> Subject: New Version Notification for >> >> draft-ymbk-bgpsec-rtr-rekeying-00.txt >> >> >> >> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >> >> succes=3D >> >> sfully submitted by Sean Turner and posted to the IETF repository. >> >> >> >> Filename: =A0 =A0 =A0 =A0draft-ymbk-bgpsec-rtr-rekeying >> >> Revision: =A0 =A0 =A0 =A000 >> >> Title: =A0 =A0 =A0 =A0 =A0 Router Keying for BGPsec >> >> Creation date: =A0 2012-03-05 >> >> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >> >> Number of pages: 7 >> >> >> >> Abstract: >> >> =A0 =A0BGPsec-speaking routers must be provisioned with private keys = and the >> >> =A0 =A0corresponding public key must be published in the global Resou= rce >> >> =A0 =A0PKI. =A0This document describes two ways of doing so, router-d= riven and >> >> =A0 =A0operator-driven. >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> >> 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 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > 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. From mlepinski@bbn.com Sat Mar 24 07:02:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C421F86FC for ; Sat, 24 Mar 2012 07:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STW6fc5rkMfG for ; Sat, 24 Mar 2012 07:02:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A5BAE21F86F7 for ; Sat, 24 Mar 2012 07:02:12 -0700 (PDT) Received: from [128.89.254.144] (port=49614) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SBRXb-0000jV-EE for sidr@ietf.org; Sat, 24 Mar 2012 10:01:59 -0400 Message-ID: <4F6DD3E3.4090501@bbn.com> Date: Sat, 24 Mar 2012 10:02:11 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:02:13 -0000 Chris, No, I believe Wes is talking about: http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00 - Matt Lepinski On 3/24/2012 9:42 AM, Christopher Morrow wrote: > On Sat, Mar 24, 2012 at 9:33 AM, George, Wes wrote: >> Yes, support. Anything that teaches router jockeys how to wrangle keys and not compromise the security of the system in the process is a good thing IMO. >> >> Though I'm wondering if perhaps this doc and bgpsec-rollover should be integrated > interesting... so you mean: > > > or something else? I think a doc just talking about 'network equipment > handling of certs' is good, mingling in with 'if I want to roll the > key on my CA, I do ...' seems like hiding the sausage in the wrong > place. (or maybe not the wrong place, but not the right one > either....) Sure, the 2 items are potentially linked, but... the CA > bits cover a lot more ground, so I would say more chance for confusion > and mistakes due to complexity. > > -chris > >>> -----Original Message----- >>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >>> Christopher Morrow >>> Sent: Saturday, March 24, 2012 6:19 AM >>> To: Sean Turner >>> Cc: Murphy, Sandra; sidr@ietf.org >>> Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt >>> >>> >>> Hey folk, >>> Is this draft stating something obvious and doesn't need to be >>> documented? or are we in need of this doc to keep us all on the same >>> page (us == ops + vendors) as to getting a cert created and installed >>> on our lovely devices? >>> >>> If people could take a few minutes to read the 4 pages (minus >>> boilerplate) and think/comment that would be nice. >>> >>> (for the record, it seems like documenting this is a good thing, from >>> my perspective.) >>> >>> -chris >>> >>> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: >>>> Well I'd like to see it adopted and I promise to work on it ;) >>>> >>>> spt >>>> >>>> >>>> On 3/7/12 6:07 PM, Murphy, Sandra wrote: >>>>> An alert eye pointed out that the URL below is incorrect. The correct >>>>> pointer is >>>>> >>>>> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >>>>> >>>>> --Sandy, speaking as clumsy wg co-chair >>>>> >>>>> ________________________________________ >>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, >>>>> Sandra [Sandra.Murphy@sparta.com] >>>>> Sent: Wednesday, March 07, 2012 5:40 PM >>>>> To: sidr@ietf.org >>>>> Subject: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>> >>>>> The following request has been made for wg adoption of >>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >>>>> >>>>> The draft is available at >>>>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >>>>> >>>>> Please respond to the list to say whether you accept this draft as a >>>>> working group draft and are willing to work on it. Remember that you do not >>>>> need to accept all content in a draft to adopt, as draft editors are >>>>> required to reflect the consensus of the working group. >>>>> >>>>> This call will end 21 Mar 2012. >>>>> >>>>> --Sandy, speaking as wg co-chair >>>>> >>>>> >>>>> ________________________________________ >>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy >>>>> Bush [randy@psg.com] >>>>> Sent: Monday, March 05, 2012 8:54 PM >>>>> To: sidr wg list >>>>> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>> >>>>> chairs, please consider as a wg work item. thanks. >>>>> >>>>> randy >>>>> >>>>> --- >>>>> >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for >>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>> >>>>> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >>>>> succes= >>>>> sfully submitted by Sean Turner and posted to the IETF repository. >>>>> >>>>> Filename: draft-ymbk-bgpsec-rtr-rekeying >>>>> Revision: 00 >>>>> Title: Router Keying for BGPsec >>>>> Creation date: 2012-03-05 >>>>> WG ID: Individual Submission >>>>> Number of pages: 7 >>>>> >>>>> Abstract: >>>>> BGPsec-speaking routers must be provisioned with private keys and the >>>>> corresponding public key must be published in the global Resource >>>>> PKI. This document describes two ways of doing so, router-driven and >>>>> operator-driven. >>>>> _______________________________________________ >>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> 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 From christopher.morrow@gmail.com Sat Mar 24 07:05:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD921F871D for ; Sat, 24 Mar 2012 07:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfrDD6CzZ-xn for ; Sat, 24 Mar 2012 07:05:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5D2A21F871C for ; Sat, 24 Mar 2012 07:05:38 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3925434obb.31 for ; Sat, 24 Mar 2012 07:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PHmZPQHOujvvEoB2nIIwinu0MghHYLe2cQ4uCLw3EKM=; b=js0jzwxkM7pZ0Emh8DYlfxO03bqmxJ7PTahRPK5SqKYj/9Z+eQN5zo8Hh7GTOI7EUW GQYw6cdfpK4VSQn1WRXU/NMz/2TfHMJafmALR41/4LmoH8yZl6lWII0MUAgq4tqS6nIX IbzoOXHJFLUBSzpkvNbAkhuit+H/jPTU62mw0ZAbOeJZ6Le8JHr6XoSuvO/g96XBqSp9 0XT3zw+z/C6l3I/mG92kocfueZpBQBwfrA0IiCGcvw09g7e48Uz8SHRrGXX3HBa3ypdC kPvZJNaJ0BRnAqUbjSa9dx7sObEKlkID4Xz4IbPShKVoyxIJx2j3ubUGGr/BmjLOqe4g GsGA== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr19384848obb.71.1332597938555; Sat, 24 Mar 2012 07:05:38 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Sat, 24 Mar 2012 07:05:38 -0700 (PDT) In-Reply-To: <4F6DD3E3.4090501@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> <4F6DD3E3.4090501@bbn.com> Date: Sat, 24 Mar 2012 10:05:38 -0400 X-Google-Sender-Auth: taKH8nkQOjoU36GqjWxCBDB3UOc Message-ID: From: Christopher Morrow To: Matt Lepinski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:05:40 -0000 On Sat, Mar 24, 2012 at 10:02 AM, Matt Lepinski wrote: > Chris, > > No, I believe Wes is talking about: > http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00 oh :) burried further down the list :( Sorry, that seems to make a clearer link to why combination would be good. thanks! -chris > - Matt Lepinski > > > On 3/24/2012 9:42 AM, Christopher Morrow wrote: >> >> On Sat, Mar 24, 2012 at 9:33 AM, George, Wes >> =A0wrote: >>> >>> Yes, support. Anything that teaches router jockeys how to wrangle keys >>> and not compromise the security of the system in the process is a good = thing >>> IMO. >>> >>> Though I'm wondering if perhaps this doc and bgpsec-rollover should be >>> integrated >> >> interesting... so you mean: >> >> >> or something else? I think a doc just talking about 'network equipment >> handling of certs' is good, mingling in with 'if I want to roll the >> key on my CA, I do ...' seems like hiding the sausage in the wrong >> place. (or maybe not the wrong place, but not the right one >> either....) Sure, the 2 items are potentially linked, but... the CA >> bits cover a lot more ground, so I would say more chance for confusion >> and mistakes due to complexity. >> >> -chris >> >>>> -----Original Message----- >>>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf O= f >>>> Christopher Morrow >>>> Sent: Saturday, March 24, 2012 6:19 AM >>>> To: Sean Turner >>>> Cc: Murphy, Sandra; sidr@ietf.org >>>> Subject: Re: [sidr] wg adoption call for >>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>> >>>> >>>> Hey folk, >>>> Is this draft stating something obvious and doesn't need to be >>>> documented? or are we in need of this doc to keep us all on the same >>>> page (us =3D=3D ops + vendors) as to getting a cert created and instal= led >>>> on our lovely devices? >>>> >>>> If people could take a few minutes to read the 4 pages (minus >>>> boilerplate) and think/comment that would be nice. >>>> >>>> (for the record, it seems like documenting this is a good thing, from >>>> my perspective.) >>>> >>>> -chris >>>> >>>> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner =A0wrot= e: >>>>> >>>>> Well I'd like to see it adopted and I promise to work on it ;) >>>>> >>>>> spt >>>>> >>>>> >>>>> On 3/7/12 6:07 PM, Murphy, Sandra wrote: >>>>>> >>>>>> An alert eye pointed out that the URL below is incorrect. =A0The cor= rect >>>>>> pointer is >>>>>> >>>>>> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >>>>>> >>>>>> --Sandy, speaking as clumsy wg co-chair >>>>>> >>>>>> ________________________________________ >>>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of >>>>>> Murphy, >>>>>> Sandra [Sandra.Murphy@sparta.com] >>>>>> Sent: Wednesday, March 07, 2012 5:40 PM >>>>>> To: sidr@ietf.org >>>>>> Subject: [sidr] wg adoption call for >>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>> >>>>>> The following request has been made for wg adoption of >>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >>>>>> >>>>>> The draft is available at >>>>>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >>>>>> >>>>>> Please respond to the list to say whether you accept this draft as a >>>>>> working group draft and are willing to work on it. Remember that you >>>>>> do not >>>>>> need to accept all content in a draft to adopt, as draft editors are >>>>>> required to reflect the consensus of the working group. >>>>>> >>>>>> This call will end 21 Mar 2012. >>>>>> >>>>>> --Sandy, speaking as wg co-chair >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Ran= dy >>>>>> Bush [randy@psg.com] >>>>>> Sent: Monday, March 05, 2012 8:54 PM >>>>>> To: sidr wg list >>>>>> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>> >>>>>> chairs, please consider as a wg work item. =A0thanks. >>>>>> >>>>>> randy >>>>>> >>>>>> --- >>>>>> >>>>>> From: internet-drafts@ietf.org >>>>>> Subject: New Version Notification for >>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>> >>>>>> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >>>>>> succes=3D >>>>>> sfully submitted by Sean Turner and posted to the IETF repository. >>>>>> >>>>>> Filename: =A0 =A0 =A0 =A0draft-ymbk-bgpsec-rtr-rekeying >>>>>> Revision: =A0 =A0 =A0 =A000 >>>>>> Title: =A0 =A0 =A0 =A0 =A0 Router Keying for BGPsec >>>>>> Creation date: =A0 2012-03-05 >>>>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >>>>>> Number of pages: 7 >>>>>> >>>>>> Abstract: >>>>>> =A0 =A0BGPsec-speaking routers must be provisioned with private keys= and >>>>>> the >>>>>> =A0 =A0corresponding public key must be published in the global Reso= urce >>>>>> =A0 =A0PKI. =A0This document describes two ways of doing so, router-= driven >>>>>> and >>>>>> =A0 =A0operator-driven. >>>>>> _______________________________________________ >>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> 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 solel= y for >>> the use of the individual or entity to which it is addressed. If you ar= e 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 m= ay 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 From christopher.morrow@gmail.com Sat Mar 24 07:09:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D687A21F8726 for ; Sat, 24 Mar 2012 07:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41fm-8LzOM-h for ; Sat, 24 Mar 2012 07:09:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C173F21F86DD for ; Sat, 24 Mar 2012 07:09:25 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3927754obb.31 for ; Sat, 24 Mar 2012 07:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EEUqhF5aFgBzPgwlKeSYwRuDnAljEpaJAMH5Iors6uw=; b=D+vYujrz56zd54GxhDiRy7Tx4nPioQmuZAPTOpEY/xfVLbgNTE+ts94/kzLwFF7tfA jNZoF0Hnqafe3N/Ipna4Gs/aYuQAEQ/+EUdhtRB0L13SJJ0IZI6DLRx3S82BoOrwONOf aChUw6If4MNl+DQtnosvSH3XFi7pFBgXnQsH4WQzrXszLHaTvVjV3E8Vcum6oWN2obXp BXX2CDXIvDa+stRAUsURpHDbSWG20gFF+sU274Jj9lTlFFGkKRdXxOTW0DFcGyLKkgK3 /0g96nVjSS1Awbgf42fsvY9xHregawulmfIa4Ris69OrK1Ck2yfA8G8ffcbRmJYMFd7s qrsw== MIME-Version: 1.0 Received: by 10.60.24.164 with SMTP id v4mr15925453oef.51.1332598165381; Sat, 24 Mar 2012 07:09:25 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Sat, 24 Mar 2012 07:09:25 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> <4F6DD3E3.4090501@bbn.com> Date: Sat, 24 Mar 2012 10:09:25 -0400 X-Google-Sender-Auth: wSmLHTt_OBSLHnikmJL8zhpqY-A Message-ID: From: Christopher Morrow To: Matt Lepinski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:09:27 -0000 On Sat, Mar 24, 2012 at 10:05 AM, Christopher Morrow wrote: > On Sat, Mar 24, 2012 at 10:02 AM, Matt Lepinski wrote= : >> Chris, >> >> No, I believe Wes is talking about: >> http://tools.ietf.org/html/draft-rogaglia-sidr-bgpsec-rollover-00 > > oh :) burried further down the list :( Sorry, that seems to make a > clearer link to why combination would be good. oh, except that the -rollover doc says: "The BGPSEC key roll-over process should be very tighten to the key provisioning mechanisms that would be in place. The key provisioning mechanisms for BGPSEC are not yet documented. We will assume that such an automatic provisioning mechanism will be in place (a possible provisioning mechanism when the private key lives only inside the BGP speaker is the Enrollment over Secure Transport (EST). This protocol will allow BGPSEC code to include automatic re-keying scripts with minimum development cost." in the second sentence it's asking for this doc... (the first sentence seems to have some missing words though) > thanks! > -chris > >> - Matt Lepinski >> >> >> On 3/24/2012 9:42 AM, Christopher Morrow wrote: >>> >>> On Sat, Mar 24, 2012 at 9:33 AM, George, Wes >>> =A0wrote: >>>> >>>> Yes, support. Anything that teaches router jockeys how to wrangle keys >>>> and not compromise the security of the system in the process is a good= thing >>>> IMO. >>>> >>>> Though I'm wondering if perhaps this doc and bgpsec-rollover should be >>>> integrated >>> >>> interesting... so you mean: >>> >>> >>> or something else? I think a doc just talking about 'network equipment >>> handling of certs' is good, mingling in with 'if I want to roll the >>> key on my CA, I do ...' seems like hiding the sausage in the wrong >>> place. (or maybe not the wrong place, but not the right one >>> either....) Sure, the 2 items are potentially linked, but... the CA >>> bits cover a lot more ground, so I would say more chance for confusion >>> and mistakes due to complexity. >>> >>> -chris >>> >>>>> -----Original Message----- >>>>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >>>>> Christopher Morrow >>>>> Sent: Saturday, March 24, 2012 6:19 AM >>>>> To: Sean Turner >>>>> Cc: Murphy, Sandra; sidr@ietf.org >>>>> Subject: Re: [sidr] wg adoption call for >>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>> >>>>> >>>>> Hey folk, >>>>> Is this draft stating something obvious and doesn't need to be >>>>> documented? or are we in need of this doc to keep us all on the same >>>>> page (us =3D=3D ops + vendors) as to getting a cert created and insta= lled >>>>> on our lovely devices? >>>>> >>>>> If people could take a few minutes to read the 4 pages (minus >>>>> boilerplate) and think/comment that would be nice. >>>>> >>>>> (for the record, it seems like documenting this is a good thing, from >>>>> my perspective.) >>>>> >>>>> -chris >>>>> >>>>> On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner =A0wro= te: >>>>>> >>>>>> Well I'd like to see it adopted and I promise to work on it ;) >>>>>> >>>>>> spt >>>>>> >>>>>> >>>>>> On 3/7/12 6:07 PM, Murphy, Sandra wrote: >>>>>>> >>>>>>> An alert eye pointed out that the URL below is incorrect. =A0The co= rrect >>>>>>> pointer is >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >>>>>>> >>>>>>> --Sandy, speaking as clumsy wg co-chair >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of >>>>>>> Murphy, >>>>>>> Sandra [Sandra.Murphy@sparta.com] >>>>>>> Sent: Wednesday, March 07, 2012 5:40 PM >>>>>>> To: sidr@ietf.org >>>>>>> Subject: [sidr] wg adoption call for >>>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>>> >>>>>>> The following request has been made for wg adoption of >>>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >>>>>>> >>>>>>> The draft is available at >>>>>>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >>>>>>> >>>>>>> Please respond to the list to say whether you accept this draft as = a >>>>>>> working group draft and are willing to work on it. Remember that yo= u >>>>>>> do not >>>>>>> need to accept all content in a draft to adopt, as draft editors ar= e >>>>>>> required to reflect the consensus of the working group. >>>>>>> >>>>>>> This call will end 21 Mar 2012. >>>>>>> >>>>>>> --Sandy, speaking as wg co-chair >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Ra= ndy >>>>>>> Bush [randy@psg.com] >>>>>>> Sent: Monday, March 05, 2012 8:54 PM >>>>>>> To: sidr wg list >>>>>>> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>>> >>>>>>> chairs, please consider as a wg work item. =A0thanks. >>>>>>> >>>>>>> randy >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> From: internet-drafts@ietf.org >>>>>>> Subject: New Version Notification for >>>>>>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>>>>> >>>>>>> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has bee= n >>>>>>> succes=3D >>>>>>> sfully submitted by Sean Turner and posted to the IETF repository. >>>>>>> >>>>>>> Filename: =A0 =A0 =A0 =A0draft-ymbk-bgpsec-rtr-rekeying >>>>>>> Revision: =A0 =A0 =A0 =A000 >>>>>>> Title: =A0 =A0 =A0 =A0 =A0 Router Keying for BGPsec >>>>>>> Creation date: =A0 2012-03-05 >>>>>>> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission >>>>>>> Number of pages: 7 >>>>>>> >>>>>>> Abstract: >>>>>>> =A0 =A0BGPsec-speaking routers must be provisioned with private key= s and >>>>>>> the >>>>>>> =A0 =A0corresponding public key must be published in the global Res= ource >>>>>>> =A0 =A0PKI. =A0This document describes two ways of doing so, router= -driven >>>>>>> and >>>>>>> =A0 =A0operator-driven. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>> >>>> 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 sole= ly 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 an= y >>>> dissemination, distribution, copying, or action taken in relation to t= he >>>> 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 From stbryant@cisco.com Sat Mar 24 07:40:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0D621F86A5 for ; Sat, 24 Mar 2012 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZy7alMTJxHp for ; Sat, 24 Mar 2012 07:40:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 441C721F869C for ; Sat, 24 Mar 2012 07:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4358; q=dns/txt; s=iport; t=1332600002; x=1333809602; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=7FQpuKj6lZZAHdv8JRuGK8mxhlhY8qLH0OvSuGLGK5s=; b=Rph92GwbfYnp7G7xCM0HHQm9EVg4hFbP5vweRpm4sJ0bqL+ihsX+UeCz BO22fcJZrOJooRfQB0mryWEzssIOhG+EFGz126bf2hKTG1JJezhlu98qn adkb62ATZDkdXsaTa+gu02oHXtNx/iB7zQsJDA20Rj3IA5zrLLSigE73W 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC7cbU+Q/khR/2dsb2JhbABDhT+yYYEHggkBAQEEEgECDlUBDAQPDQMBAgoWCwICCQMCAQIBOwIIBg0BBQIBAR6HaJlqgzwQiTyEA41HkBCBGASVYI5FgQJmgmc X-IronPort-AV: E=Sophos;i="4.73,641,1325462400"; d="scan'208,217";a="133249601" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 24 Mar 2012 14:40:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2OEe0TB019825; Sat, 24 Mar 2012 14:40:01 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q2OEdrNW011375; Sat, 24 Mar 2012 14:39:54 GMT Message-ID: <4F6DDCB9.3020406@cisco.com> Date: Sat, 24 Mar 2012 14:39:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sidr wg list References: <20120324101622.11901.52174.idtracker@ietfa.amsl.com> In-Reply-To: <20120324101622.11901.52174.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120324101622.11901.52174.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060604090405050004020201" Cc: "sidr-chairs@tools.ietf.org" Subject: [sidr] Fwd: sidr - Requested sessions have been scheduled for IETF 83 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:40:03 -0000 This is a multi-part message in MIME format. --------------060604090405050004020201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The requested additional SIDR session has been secheduled Stewart -------- Original Message -------- Subject: sidr - Requested sessions have been scheduled for IETF 83 Date: Sat, 24 Mar 2012 03:16:22 -0700 From: "IETF Secretariat" To: murphy@tis.com CC: sidr-ads@tools.ietf.org, Sandra.Murphy@sparta.com, morrowc@ops-netman.net, wlo@amsl.com Dear Sandra Murphy, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sidr Session 1 (2:30:00) Wednesday, Morning Session I 0900-1130 Room Name: 241 --------------------------------------------- sidr Session 2 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: 241 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tls pkix opsec mpls isis ipsecme idr grow emu bfd abfab Second Priority: rtgwg Special Requests: --------------------------------------------------------- --------------060604090405050004020201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
    The requested additional SIDR session has been secheduled

    Stewart


    -------- Original Message --------
    Subject: sidr - Requested sessions have been scheduled for IETF 83
    Date: Sat, 24 Mar 2012 03:16:22 -0700
    From: "IETF Secretariat" <agenda@ietf.org>
    To: murphy@tis.com
    CC: sidr-ads@tools.ietf.org, Sandra.Murphy@sparta.com, morrowc@ops-netman.net, wlo@amsl.com 


    Dear Sandra Murphy,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

sidr Session 1 (2:30:00)
    Wednesday, Morning Session I 0900-1130
    Room Name: 241
    ---------------------------------------------
    sidr Session 2 (2:00:00)
    Monday, Afternoon Session I 1300-1500
    Room Name: 241
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: 
Area Name: 
Session Requester: 

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 2 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: tls pkix opsec mpls isis ipsecme idr grow emu bfd abfab
 Second Priority: rtgwg



Special Requests:
  
---------------------------------------------------------
    --------------060604090405050004020201-- From warren@kumari.net Sat Mar 24 08:19:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF8C21F857D for ; Sat, 24 Mar 2012 08:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp3bYtclYyTO for ; Sat, 24 Mar 2012 08:19:11 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6521F8549 for ; Sat, 24 Mar 2012 08:19:10 -0700 (PDT) Received: from [172.28.226.85] (unknown [74.125.57.241]) by vimes.kumari.net (Postfix) with ESMTPSA id 5FCD21B40EF6; Sat, 24 Mar 2012 11:19:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Sat, 24 Mar 2012 16:19:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 15:19:11 -0000 Read and support=85 Sorry, there are so many drafts, I can never keep clear which ones I = have already supported=85 W On Mar 24, 2012, at 11:18 AM, Christopher Morrow wrote: > > Hey folk, > Is this draft stating something obvious and doesn't need to be > documented? or are we in need of this doc to keep us all on the same > page (us =3D=3D ops + vendors) as to getting a cert created and = installed > on our lovely devices? >=20 > If people could take a few minutes to read the 4 pages (minus > boilerplate) and think/comment that would be nice. >=20 > (for the record, it seems like documenting this is a good thing, from > my perspective.) >=20 > -chris >=20 > On Mon, Mar 12, 2012 at 4:13 PM, Sean Turner wrote: >> Well I'd like to see it adopted and I promise to work on it ;) >>=20 >> spt >>=20 >>=20 >> On 3/7/12 6:07 PM, Murphy, Sandra wrote: >>>=20 >>> An alert eye pointed out that the URL below is incorrect. The = correct >>> pointer is >>>=20 >>> http://tools.ietf.org/html/draft-ymbk-bgpsec-rtr-rekeying-00 >>>=20 >>> --Sandy, speaking as clumsy wg co-chair >>>=20 >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, >>> Sandra [Sandra.Murphy@sparta.com] >>> Sent: Wednesday, March 07, 2012 5:40 PM >>> To: sidr@ietf.org >>> Subject: [sidr] wg adoption call for = draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>=20 >>> The following request has been made for wg adoption of >>> draft-ymbk-bgpsec-rtr-rekeying-00.txt. >>>=20 >>> The draft is available at >>> http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl-01. >>>=20 >>> Please respond to the list to say whether you accept this draft as a >>> working group draft and are willing to work on it. Remember that you = do not >>> need to accept all content in a draft to adopt, as draft editors are >>> required to reflect the consensus of the working group. >>>=20 >>> This call will end 21 Mar 2012. >>>=20 >>> --Sandy, speaking as wg co-chair >>>=20 >>>=20 >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Randy >>> Bush [randy@psg.com] >>> Sent: Monday, March 05, 2012 8:54 PM >>> To: sidr wg list >>> Subject: [sidr] draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>=20 >>> chairs, please consider as a wg work item. thanks. >>>=20 >>> randy >>>=20 >>> --- >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-ymbk-bgpsec-rtr-rekeying-00.txt >>>=20 >>> A new version of I-D, draft-ymbk-bgpsec-rtr-rekeying-00.txt has been >>> succes=3D >>> sfully submitted by Sean Turner and posted to the IETF repository. >>>=20 >>> Filename: draft-ymbk-bgpsec-rtr-rekeying >>> Revision: 00 >>> Title: Router Keying for BGPsec >>> Creation date: 2012-03-05 >>> WG ID: Individual Submission >>> Number of pages: 7 >>>=20 >>> Abstract: >>> BGPsec-speaking routers must be provisioned with private keys and = the >>> corresponding public key must be published in the global Resource >>> PKI. This document describes two ways of doing so, router-driven = and >>> operator-driven. >>> _______________________________________________ >>> 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 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >> _______________________________________________ >> 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 >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From jakob.heitz@ericsson.com Sat Mar 24 13:34:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B58C21F8484 for ; Sat, 24 Mar 2012 13:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TaiCQUlcTqz for ; Sat, 24 Mar 2012 13:34:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8121F8483 for ; Sat, 24 Mar 2012 13:34:38 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2OKYbiT000764 for ; Sat, 24 Mar 2012 15:34:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.157]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 24 Mar 2012 16:34:31 -0400 From: Jakob Heitz To: "sidr@ietf.org list" Date: Sat, 24 Mar 2012 16:34:29 -0400 Thread-Topic: sidr drafts link broken Thread-Index: Ac0J/YMjXL+iw6tHTDOdUiVjO4glXg== Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950EUSAACMS0701e_" MIME-Version: 1.0 Subject: [sidr] sidr drafts link broken X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:34:39 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/meeting/83/agenda/sidr-drafts.pdf link on agenda page is broken -- Jakob Heitz. --_000_7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    link on agenda page is broken
     
    --
    Jakob Heitz.
     
     
     --_000_7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950EUSAACMS0701e_-- From wesley.george@twcable.com Sat Mar 24 13:37:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C025021F8484 for ; Sat, 24 Mar 2012 13:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKiQzYotWKE5 for ; Sat, 24 Mar 2012 13:37:23 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAD721F8483 for ; Sat, 24 Mar 2012 13:37:22 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,643,1325480400"; d="scan'208";a="358511199" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 16:36:31 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sat, 24 Mar 2012 16:37:22 -0400 From: "George, Wes" To: Christopher Morrow , Matt Lepinski Date: Sat, 24 Mar 2012 16:37:20 -0400 Thread-Topic: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt Thread-Index: Ac0Jx7wu/FgwIfZiR42oq99zZ07L8AANSpfw Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> <4F6DD3E3.4090501@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:37:23 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Saturday, March 24, 2012 10:09 AM > To: Matt Lepinski > Cc: sidr@ietf.org > Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-0= 0.txt > > oh, except that the -rollover doc says: > "The BGPSEC key roll-over process should be very tighten to the key > provisioning mechanisms that would be in place. The key provisioning > mechanisms for BGPSEC are not yet documented. We will assume that > such an automatic provisioning mechanism will be in place (a possible > provisioning mechanism when the private key lives only inside the BGP > speaker is the Enrollment over Secure Transport (EST). This protocol > will allow BGPSEC code to include automatic re-keying scripts with > minimum development cost." > > in the second sentence it's asking for this doc... (the first sentence > seems to have some missing words though) > > > thanks! > > -chris > > [WEG] the cited text can be changed, especially now that the referenced doc= umentation exists. :-) My point was not that all of the information isn't important, but rather th= at this occupies similar space and I don't know that it needs to be separat= ed, other than as a separate section in one document. This WG generates a l= ot of documents that are logically separated by subject matter, but by nece= ssity very intertwined, which sometimes makes it hard for those not intimat= ely involved in writing/reviewing the drafts to keep track of what informat= ion is discussed where, and requires a fair amount of cross-referencing to = truly understand the implementation. I'm thinking that if there are obvious= places to consolidate, we should do so. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From achi@bbn.com Sun Mar 25 11:43:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5855A21E8011 for ; Sun, 25 Mar 2012 11:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDULHlneDDa9 for ; Sun, 25 Mar 2012 11:43:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC15421E800C for ; Sun, 25 Mar 2012 11:43:26 -0700 (PDT) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:52823 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SBsPJ-000CO0-3J for sidr@ietf.org; Sun, 25 Mar 2012 14:43:13 -0400 Message-ID: <4F6F674B.8060509@bbn.com> Date: Sun, 25 Mar 2012 14:43:23 -0400 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr wg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] RPKI validator implementer meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 18:43:27 -0000 A few of the usual suspects (i.e. RPKI implementers) are meeting informally tomorrow morning to talk through some conformance details and gray areas. We might do some software testing as well, depending on the topics that come up. And as usual, anyone with the same masochistic bent is welcome to join us :-) Place: "terminal room" at IETF Time: 3/26 morning, first session (though may not start right at 9) Tim and Miklos (RIPE), Rob, and I will be there. Randy suggested summarizing our discussion for the Wednesday sidr session -- we'll do that if it there turns out to be relevant content and room in the schedule. -Andrew From wwwrun@rfc-editor.org Sun Mar 25 12:07:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3690821E8013 for ; Sun, 25 Mar 2012 12:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYGmpEQD5Q8C for ; Sun, 25 Mar 2012 12:07:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BC67621E800E for ; Sun, 25 Mar 2012 12:07:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0D2B5B1E002; Sun, 25 Mar 2012 12:06:25 -0700 (PDT) To: mlepinski@bbn.com, skent@bbn.com, dkong@bbn.com, stbryant@cisco.com, adrian@olddog.co.uk, Sandra.Murphy@sparta.com, morrowc@ops-netman.net From: RFC Errata System Message-Id: <20120325190625.0D2B5B1E002@rfc-editor.org> Date: Sun, 25 Mar 2012 12:06:25 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, sidr@ietf.org Subject: [sidr] [Editorial Errata Reported] RFC6482 (3166) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 19:07:40 -0000 The following errata report has been submitted for RFC6482, "A Profile for Route Origin Authorizations (ROAs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6482&eid=3166 -------------------------------------- Type: Editorial Reported by: Andrew Chi Section: 4 Original Text ------------- ...EE certificate's IP address delegation extension. Corrected Text -------------- ...EE certificate's IP address delegation extension. The EE certificate MUST NOT use "inherit" elements as described in [RFC3779]. Notes ----- Having spoken to the authors, the authors' intent was to disallow "inherit" in ROA EE certificates in order to simplify validation of ROAs. Implementers agree, and as of March 2012, the three public validator implementations already enforce this. This erratum simply states it explicitly, whereas the original text might be misread as leaving room for indirectly-specified resources via "inherit". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6482 (draft-ietf-sidr-roa-format-12) -------------------------------------- Title : A Profile for Route Origin Authorizations (ROAs) Publication Date : February 2012 Author(s) : M. Lepinski, S. Kent, D. Kong Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From Sandra.Murphy@sparta.com Sun Mar 25 19:15:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8821E8019 for ; Sun, 25 Mar 2012 19:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftycJVLaX7jM for ; Sun, 25 Mar 2012 19:15:27 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE821E8050 for ; Sun, 25 Mar 2012 19:15:26 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2Q2FPrI001239 for ; Sun, 25 Mar 2012 21:15:25 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2Q2FPFW030273 for ; Sun, 25 Mar 2012 21:15:25 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 22:15:25 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda for Monday Thread-Index: Ac0K7d71JRFc3nzJSgOkglUNmLlZBw== Date: Mon, 26 Mar 2012 02:15:24 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CA45F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] agenda for Monday X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 02:15:27 -0000 =0A= I uploaded a new agenda that covers both days.=0A= =0A= On Monday, we will have Brian Dickson talking about route leaks first. Bri= an will be remote from six hours before us, so be extra attentive.=0A= =0A= Sriram will go next as his presentation got shortened last time (by extensi= ve route leaks discussion, ironically).=0A= =0A= Randy will talk about route validation and Rob will talk about rpki perform= ance and experiments.=0A= =0A= And Chris will talk about interim meetings.=0A= =0A= --Sandy, speaking as co-chair=0A= From Sandra.Murphy@sparta.com Sun Mar 25 22:04:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0291C21F853C for ; Sun, 25 Mar 2012 22:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtWlQMM5k7H1 for ; Sun, 25 Mar 2012 22:04:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAD621F853D for ; Sun, 25 Mar 2012 22:04:04 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2Q5433Z001891 for ; Mon, 26 Mar 2012 00:04:03 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2Q543Xp001985 for ; Mon, 26 Mar 2012 00:04:03 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 01:04:03 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WebEx info for the meeting today Thread-Index: Ac0LDdx43MuuYeWdRjyG8NsCAc7BUg== Date: Mon, 26 Mar 2012 05:04:02 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CA4F3@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WebEx info for the meeting today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 05:04:11 -0000 Here is the info for the WebEx session for today's wg meeting.=0A= =0A= This was set up for Brian to use in a remote presentation but anyone can jo= in who needs to.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= =0A= Hello SIDR Working Group,=0A= =0A= Secure Inter-Domain Routing Working Group invites you to attend a Web semin= ar using WebEx.=0A= =0A= Topic: SIDR wg meeting=0A= Host: Secure Inter-Domain Routing Working Group=0A= Date and Time:=0A= Monday, March 26, 2012 12:00 pm, GMT Summer Time (London, GMT+01:00)=0A= Monday, March 26, 2012 1:00 pm, Europe Summer Time (Paris, GMT+02:00)=0A= Event number: 646 894 577=0A= Event password: Mondaywgmeeting=0A= =0A= -------------------------------------------------------=0A= To join the online event=0A= -------------------------------------------------------=0A= 1. Click here to join the online event.=0A= Or copy and paste the following link to a browser:=0A= https://ietf.webex.com/ietf/onstage/g.php?d=3D646894577&t=3Da&EA=3Dsandra.m= urphy%40sparta.com&ET=3Dc4a3db425ffa0693c700b6e768e53946&ETR=3D473957d80ee2= 71117dd0b2f222acd566&RT=3DMiMyMQ=3D=3D&p=0A= 2. Click "Join Now".=0A= =0A= =0A= -------------------------------------------------------=0A= To join the teleconference only=0A= -------------------------------------------------------=0A= Call-in toll number (US/Canada): +1-408-600-3600=0A= Access code: 646 894 577=0A= =0A= -------------------------------------------------------=0A= For assistance=0A= -------------------------------------------------------=0A= You can contact Secure Inter-Domain Routing Working Group at:=0A= sidr-chairs@tools.ietf.org=0A= =0A= The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://ietf.webex.com/ietf/onstage/systemdiagnosis.php=0A= From henk@uijterwaal.nl Sun Mar 25 23:16:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250FC21F8569 for ; Sun, 25 Mar 2012 23:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.517 X-Spam-Level: X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6MHmUR3isSo for ; Sun, 25 Mar 2012 23:16:55 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by ietfa.amsl.com (Postfix) with ESMTP id DA4E121F8562 for ; Sun, 25 Mar 2012 23:16:52 -0700 (PDT) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id q2Q6GKJn079636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 08:16:21 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4F7009B3.5030201@uijterwaal.nl> Date: Mon, 26 Mar 2012 08:16:19 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "George, Wes" References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C91C2@Hermes.columbia.ads.sparta.com> <4F6C741F.3020309@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "sidr@ietf.org" Subject: Re: [sidr] additional interim meetings X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:16:56 -0000 On 23/03/2012 16:08, George, Wes wrote: > [WEG] One point to make here... I think you're overselling the difficulty of > requesting and receiving additional slots when they are all requested at the > same time, rather than retroactively as was done this time. Yes by strict > math you're correct, but rarely do all of the WGs meet. For Paris, the agenda was overloaded and all WG chairs were specifically asked to review the agenda for their WG, check if the discussions they had planned for the meeting needed face-2-face discussion and return the slot if not. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From kent@bbn.com Mon Mar 26 01:20:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3989E21F852E for ; Mon, 26 Mar 2012 01:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57nRwt1Yxy6z for ; Mon, 26 Mar 2012 01:20:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 40DEA21F84AA for ; Mon, 26 Mar 2012 01:20:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:59862 helo=[10.108.71.115]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC5AF-000Hge-HR; Mon, 26 Mar 2012 04:20:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0EFE@Hermes.columbia.ads.sparta.com> <4F5E58EF.2000908@ieca.com> Date: Mon, 26 Mar 2012 03:58:25 -0400 To: Christopher Morrow From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:20:49 -0000 At 6:18 AM -0400 3/24/12, Christopher Morrow wrote: > >Hey folk, >Is this draft stating something obvious and doesn't need to be >documented? or are we in need of this doc to keep us all on the same >page (us == ops + vendors) as to getting a cert created and installed >on our lovely devices? > >If people could take a few minutes to read the 4 pages (minus >boilerplate) and think/comment that would be nice. > >(for the record, it seems like documenting this is a good thing, from >my perspective.) > >-chris I think these issues need to be documented somewhere. It's helpful to note motivations for central key generation (e.g., quick restoral of service when a router fails and hardware is replaced), which might otherwise be lost. Finally, we're working on a new cert provisioning protocol in PKIX and this provides a basis for making sure this capability is part of that protocol. That said, it might make sense to combine this doc and the key rollover doc that is another individual submission, of we want to reduce the number of distinct SIDR docs. Steve From internet-drafts@ietf.org Mon Mar 26 04:46:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D9321F866E; Mon, 26 Mar 2012 04:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOXPj5WdL8jC; Mon, 26 Mar 2012 04:46:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F96021F869E; Mon, 26 Mar 2012 04:46:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326114639.4910.42737.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 04:46:39 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:46:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-00.txt Pages : 23 Date : 2012-03-26 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-protocol-mib-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-protocol-mib-00= .txt From randy@psg.com Mon Mar 26 05:09:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6021F86BA for ; Mon, 26 Mar 2012 05:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vhtD+SxMlc9 for ; Mon, 26 Mar 2012 05:09:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 344D221F86AF for ; Mon, 26 Mar 2012 05:09:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC8jh-000Csy-Ie for sidr@ietf.org; Mon, 26 Mar 2012 12:09:21 +0000 Date: Mon, 26 Mar 2012 14:09:20 +0200 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (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 Subject: [sidr] draft-dickson-sidr-route-leak-solns-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:09:22 -0000 [ let me save mic time and just say what i said to the idr list ] i do not think this will fly in the long run, but let my try to at least get it in the best light. o it could and should be said in a page or so in order that people can get it and think it is simple and not imposing o it assumes gao-rexford, which we know is an unsafe assumption, but wtf, it's good in enough cases that we can let it go for the moment o the relationship has to be per prefix not per link, as prefixes with different business models are often sent over the same link o the mark should be determined by the sender, and need not agree with the receiver's perception of the relationship o if the receiver does not like it they can call the sender on the phone, drop the announcement, whatever o this is a significant change to bgp, so idr should be asked to say it's cool before sidr tries to protect it by signing over it o if it is agreed by idr and it is well defined, we know how to sign it in bgpsec, it's like a few more bits on each hop in the as path o as with origin validation and path validation, the router should not do anything on its own, but rather should provide the operator the tools needed to apply policy based on the data o therefore, to use it, the router will have to give the operator some sort of expression over the catenation of the per-as policy markings o but what should an operator do when they see a 'violation' six hops away? randy From dougm.tlist@gmail.com Mon Mar 26 05:37:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778D021F84DE for ; Mon, 26 Mar 2012 05:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNTJtb1M0ipq for ; Mon, 26 Mar 2012 05:37:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7821E808E for ; Mon, 26 Mar 2012 05:37:01 -0700 (PDT) Received: by yenm5 with SMTP id m5so4124647yen.31 for ; Mon, 26 Mar 2012 05:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=K7+tu4+cW/ijhDMaTT22XthRRXfuktde3Z/cy2qTZnY=; b=AGYLgzHigtAfV7xmAi+eaG1Yov6o/Wt+EmOmOmH/4hD3yRBI2G3v/W8/VsJsuSJ8tw qhllAA2fyyUaqpt2jUY5Jz5D/MpMeWvurXO60CE5xDvB0p0g+ivvL5wKoEAGnHoD34+Y JkNUb8eZch7/GfHjM53Am//PHgSwKaMrN2srz8988cv9F5QZHy4yXOiQ8k02ksHSTtEg xJqZl1WEur5w9U6P8sTZkJa2LMA8LqENh4s94bjCxQ5/+02zpzelAV0Dlzy6xbuIUpaT LY/40ofDTxrmvc28k01eTrfuzV29pnYad1khDVm1TEFlLm9pDFbB/XmJsREJ37G1XnBS 7iEQ== Received: by 10.68.212.35 with SMTP id nh3mr30398696pbc.84.1332765420364; Mon, 26 Mar 2012 05:37:00 -0700 (PDT) Received: from [130.129.87.191] (dhcp-57bf.meeting.ietf.org. [130.129.87.191]) by mx.google.com with ESMTPS id k2sm12457327pba.28.2012.03.26.05.36.58 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 05:36:59 -0700 (PDT) Message-ID: <4F7062EA.5050307@gmail.com> Date: Mon, 26 Mar 2012 08:36:58 -0400 From: DougM lists User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050502090404060604070304" Subject: Re: [sidr] draft-dickson-sidr-route-leak-solns-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:37:06 -0000 This is a multi-part message in MIME format. --------------050502090404060604070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As noted a while back (http://www.ietf.org/mail-archive/web/sidr/current/msg03797.html ) we have been trying to add this to BGP for over 20 years (see RFC1105 - this was in BGP design at one point). What always sends this straight into a rat hole are the exceptions cases. In particular: 1. If the granularity of the labeling is the peering session, you will find that there are situations in which some routes need to be labeled differently than the rest. * If you label individual updates, you at least have the flexibility to have exceptions per-peering session. 2. If you label updates - there will always be situations where someone does not want to reveal that relationship. * The encoding must permit some updates to be unlabeled (or marked "undisclosed"). 3. If you mandate the policy that MUST be enforced w/ these markings (e.g., valley free, no multi-hop plateaus, etc) there will always be exceptions. * If you make the labeling of hops simply an input to local policy, receivers can decide what policies to implement with respect to the "shape" of the path. If we avoid these rat holes, one could include such a feature w/ bounded risk, time would tell how the mechanism is put to use in practice. dougm On 3/26/2012 8:09 AM, Randy Bush wrote: > [ let me save mic time and just say what i said to the idr list ] > > i do not think this will fly in the long run, but let my try to at least > get it in the best light. > > o it could and should be said in a page or so in order that people can > get it and think it is simple and not imposing > > o it assumes gao-rexford, which we know is an unsafe assumption, but > wtf, it's good in enough cases that we can let it go for the moment > > o the relationship has to be per prefix not per link, as prefixes with > different business models are often sent over the same link > > o the mark should be determined by the sender, and need not agree with > the receiver's perception of the relationship > > o if the receiver does not like it they can call the sender on the > phone, drop the announcement, whatever > > o this is a significant change to bgp, so idr should be asked to say > it's cool before sidr tries to protect it by signing over it > > o if it is agreed by idr and it is well defined, we know how to sign > it in bgpsec, it's like a few more bits on each hop in the as path > > o as with origin validation and path validation, the router should not > do anything on its own, but rather should provide the operator the > tools needed to apply policy based on the data > > o therefore, to use it, the router will have to give the operator some > sort of expression over the catenation of the per-as policy markings > > o but what should an operator do when they see a 'violation' six hops > away? > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------050502090404060604070304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As noted a while back (http://www.ietf.org/mail-archive/web/sidr/current/msg03797.html)  we have been trying to add this to BGP for over 20 years (see RFC1105 - this was in BGP design at one point).   What always sends this straight into a rat hole are the exceptions cases.

    In particular:

    1. If the granularity of the labeling is the peering session, you will find that there are situations in which some routes need to be labeled differently than the rest.

    * If you label individual updates, you at least have the flexibility to have exceptions per-peering session.

    2. If you label updates - there will always be situations where someone does not want to reveal that relationship. 

    * The encoding must permit some updates to be unlabeled (or marked "undisclosed").

    3. If you mandate the policy that MUST be enforced w/ these markings (e.g., valley free, no multi-hop plateaus, etc) there will always be exceptions.

    * If you make the labeling of hops simply an input to local policy, receivers can decide what policies to implement with respect to the "shape" of the path.

    If we avoid these rat holes, one could include such a feature w/ bounded risk,  time would tell how the mechanism is put to use in practice. 

    dougm

    On 3/26/2012 8:09 AM, Randy Bush wrote: 
    [ let me save mic time and just say what i said to the idr list ]

i do not think this will fly in the long run, but let my try to at least
get it in the best light.

  o it could and should be said in a page or so in order that people can
    get it and think it is simple and not imposing

  o it assumes gao-rexford, which we know is an unsafe assumption, but
    wtf, it's good in enough cases that we can let it go for the moment

  o the relationship has to be per prefix not per link, as prefixes with
    different business models are often sent over the same link

  o the mark should be determined by the sender, and need not agree with
    the receiver's perception of the relationship

  o if the receiver does not like it they can call the sender on the
    phone, drop the announcement, whatever

  o this is a significant change to bgp, so idr should be asked to say
    it's cool before sidr tries to protect it by signing over it

  o if it is agreed by idr and it is well defined, we know how to sign
    it in bgpsec, it's like a few more bits on each hop in the as path

  o as with origin validation and path validation, the router should not
    do anything on its own, but rather should provide the operator the
    tools needed to apply policy based on the data

  o therefore, to use it, the router will have to give the operator some
    sort of expression over the catenation of the per-as policy markings

  o but what should an operator do when they see a 'violation' six hops
    away?

randy

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

    --------------050502090404060604070304-- From randy@psg.com Mon Mar 26 07:12:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D521F8510 for ; Mon, 26 Mar 2012 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEMsWVK2ZY8t for ; Mon, 26 Mar 2012 07:12:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFDF21F83EF for ; Mon, 26 Mar 2012 07:12:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCAeU-000DAp-NT for sidr@ietf.org; Mon, 26 Mar 2012 14:12:06 +0000 Date: Mon, 26 Mar 2012 16:12:05 +0200 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (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=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:12:17 -0000 at this afternoon's sidr ssion, i presented two open issue with draft-ietf-sidr-pfx-validate-04.txt 1 - Should updates learned via iBGP be marked? 2 - Should updates injected into BGP on this router be marked? i think yes because: o i want support of incremental deployment o i do not want to find out I am announcing garbage when my neighbor=E2= =80=99s NOC calls, mis-originations should be stopped at the source there was fear that, if used at other than edge routers, this allowed creation of loops, as setting local pref etc, do. i think there was general agreement that this was ok on edge routers and the point of injection, as that is logically an edge router. would like to see convergence on this thanks randy From christopher.morrow@gmail.com Mon Mar 26 07:43:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB6C21E80BD; Mon, 26 Mar 2012 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw3Tz6vOAVRL; Mon, 26 Mar 2012 07:43:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3A21E80BC; Mon, 26 Mar 2012 07:43:34 -0700 (PDT) Received: by yhkk25 with SMTP id k25so4242485yhk.31 for ; Mon, 26 Mar 2012 07:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uhGDdnuk7OdyNQf1UHuhTXK7P/Supx6vLzFIZzp2vFs=; b=sVqLTND8OOfOcrMgl3/NiuLjJj+76pwc1ioxzsjFch3m81OOG6LkgWero/mWOWif2Y gMvTRTAAY/ufW1ffn3xq9wyOnvr830Qqz3rukr8MmWWqxyJGtprRcgEe6h17kwwpWh/q 1rEKau56ebLAWF9zKrXVPPef0oBZzTmCB1PSXZkGPzqotfDoujfO2rI5EJQPxgvh5UVb uw7af9ZA6hB/fEktaSq6+k3M8zNZuJCfZROQyufIlSvrCdmRF6LQXpTv9xVHV4s+JMO+ CANMahYq+UbKj9owtYVtvxdR9XIT2yH4+4vFKfiGA1AlM4Nue0STKA7H0VCQ9PAH4Fxh PuEg== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr26716331oea.61.1332773013670; Mon, 26 Mar 2012 07:43:33 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Mon, 26 Mar 2012 07:43:33 -0700 (PDT) Date: Mon, 26 Mar 2012 10:43:33 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:43:34 -0000 So, as stated in the meeting today, and in these slides: There is a proposal to schedule 5 future Interim Face to Face (+virtual) meetings. The dates/locations are: Mon Apr 30 - after ARIN (IAD) Wed Jun 6 - NANOG (YVR) Fri Jun 29 - (BWI/IAD) Fri Jul 27 - prior to IETF84 (YVR) Sun Sep 23 - prior to RIPE (AMS) The hope is that: 1) WG folks interested in the forward progress of the WG work can attend (either physically or virtually) 2) WG folk interested see this number of meetings (about 1/month for the next 6 months) as appropriate 3) the overlap/adjacency with existing operations meetings will help travel problems AND bring in some ops focus/requirements as well to the work. Please have a discussion on the applicability of the meetings (number and attendance capabilities) and let's close that discussion out ~Mar 29, 2012 23:59 Paris Local Time (CEST?). -Chris (Note: the deadline is to avoid scheduling/process deadlines in getting the first meeting note out via IETF/IESG-secretary) From randy@psg.com Mon Mar 26 07:45:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B721E80BE for ; Mon, 26 Mar 2012 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR0St15AzaMs for ; Mon, 26 Mar 2012 07:45:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA4721E80BC for ; Mon, 26 Mar 2012 07:45:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCBAm-000DHf-P0; Mon, 26 Mar 2012 14:45:29 +0000 Date: Mon, 26 Mar 2012 16:45:27 +0200 Message-ID: From: Randy Bush To: Christopher Morrow 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:45:30 -0000 > Mon Apr 30 - after ARIN (IAD) > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) i will try to attend in person randy From weiler@watson.org Mon Mar 26 08:15:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4D921E80A9; Mon, 26 Mar 2012 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lemLAB0OHEez; Mon, 26 Mar 2012 08:15:01 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id CF6BE21E80A8; Mon, 26 Mar 2012 08:14:53 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2QFEoLt015904; Mon, 26 Mar 2012 11:14:50 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2QFEo0b015901; Mon, 26 Mar 2012 11:14:50 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 26 Mar 2012 11:14:50 -0400 (EDT) From: Samuel Weiler To: Christopher Morrow In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 26 Mar 2012 11:14:50 -0400 (EDT) Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:15:03 -0000 I am content to have interim meetings iff the WG commits to improving the technical facilities for remote participants. That was fumbled badly at the San Diego interim meeting and moderately badly today. We need to do better. To encourage us to do better, I suggest that the first of these interims (on whatever date; see below) be virtual-only. If we continue to have technical foibles, I suggest that the remaining interims be cancelled entirely. On Mon, 26 Mar 2012, Christopher Morrow wrote: > Mon Apr 30 - after ARIN (IAD) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) Neither of these Fridays work for me (June 29th at all, July 27th in person) due to prior commitments, and the Monday is dicey. My general preference would be to have these meetings midweek (Tues/Wed/Thurs), thereby avoiding weekend-impinging travel. > Wed Jun 6 - NANOG (YVR) But that's World IPv6 Launch Day! (No real objection.) From aservin@lacnic.net Mon Mar 26 09:03:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73ED21E80ED; Mon, 26 Mar 2012 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqyvQPR75oDK; Mon, 26 Mar 2012 09:03:46 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8421E80A3; Mon, 26 Mar 2012 09:03:46 -0700 (PDT) Received: from dhcp-1390.meeting.ietf.org (dhcp-1390.meeting.ietf.org [130.129.19.144]) by mail.lacnic.net.uy (Postfix) with ESMTP id 07D6D30846E; Mon, 26 Mar 2012 13:03:39 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_437625B2-6D63-4B0B-A73B-767263EC1F5D" From: Arturo Servin In-Reply-To: Date: Mon, 26 Mar 2012 18:03:36 +0200 Message-Id: <8E71D989-231C-46F4-A3B6-C5957F94E8B9@lacnic.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:03:47 -0000 --Apple-Mail=_437625B2-6D63-4B0B-A73B-767263EC1F5D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I think that you silently discarded my email: http://www.ietf.org/mail-archive/web/sidr/current/msg04215.html Anyhow I wasn't expecting too much, but I least I tried. Regards, .as On 26 Mar 2012, at 16:43, Christopher Morrow wrote: > So, as stated in the meeting today, and in these slides: > > > There is a proposal to schedule 5 future Interim Face to Face > (+virtual) meetings. The dates/locations are: > > Mon Apr 30 - after ARIN (IAD) > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) > > The hope is that: > 1) WG folks interested in the forward progress of the WG work can > attend (either physically or virtually) > 2) WG folk interested see this number of meetings (about 1/month for > the next 6 months) as appropriate > 3) the overlap/adjacency with existing operations meetings will help > travel problems AND bring in some ops focus/requirements as well to > the work. > > Please have a discussion on the applicability of the meetings (number > and attendance capabilities) and let's close that discussion out ~Mar > 29, 2012 23:59 Paris Local Time (CEST?). > > -Chris > > (Note: the deadline is to avoid scheduling/process deadlines in > getting the first meeting note out via IETF/IESG-secretary) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_437625B2-6D63-4B0B-A73B-767263EC1F5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii     I think that you silently = discarded my email:


    Anyhow I wasn't expecting too = much, but I least I = tried.

    Regards,
    .as

    = On 26 Mar 2012, at 16:43, Christopher Morrow wrote:

    So, = as stated in the meeting today, and in these slides:
     <ht= tp://www.ietf.org/proceedings/83/slides/slides-83-sidr-8.pdf>
    There is a proposal to schedule 5 future Interim Face to = Face
    (+virtual) meetings. The dates/locations are:

    Mon Apr 30 = - after ARIN (IAD)
    Wed Jun 6 - NANOG (YVR)
    Fri Jun 29 - = (BWI/IAD)
    Fri Jul 27 - prior to IETF84 (YVR)
    Sun Sep 23 - prior to = RIPE (AMS)

    The hope is that:
     1) WG folks interested in = the forward progress of the WG work can
    attend (either physically or = virtually)
     2) WG folk interested see this number of meetings = (about 1/month for
    the next 6 months) as appropriate
     3) the = overlap/adjacency with existing operations meetings will help
    travel = problems AND bring in some ops focus/requirements as well to
    the = work.

    Please have a discussion on the applicability of the = meetings (number
    and attendance capabilities) and let's close that = discussion out ~Mar
    29, 2012 23:59 Paris Local Time = (CEST?).

    -Chris
    <co-chair>
    (Note: the deadline is to = avoid scheduling/process deadlines in
    getting the first meeting note = out via = IETF/IESG-secretary)
    _______________________________________________sidr mailing list
    sidr@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/sidr

    = --Apple-Mail=_437625B2-6D63-4B0B-A73B-767263EC1F5D-- From christopher.morrow@gmail.com Mon Mar 26 09:14:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4026221E80E0; Mon, 26 Mar 2012 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-O8I2aRtrGh; Mon, 26 Mar 2012 09:13:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC921E8097; Mon, 26 Mar 2012 09:13:59 -0700 (PDT) Received: by yenm5 with SMTP id m5so4380527yen.31 for ; Mon, 26 Mar 2012 09:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xFqo7dek3uz1rZUUJVbZG9PpDR9k0B7+HaLSU27Ek3I=; b=XefU2MhREPtChLWWl8YOubBW27rBvna2HqdD2uESI1hhmISnvDU+r7Bms521YLKCss Td5lX9uLIJU3URkqOq4WzWpEw2CAREOoJzE5UrHhQwYJ5fzzKHf5SeHTLCj9Aag31zGQ 7tpb73lnAmjvp8Lp8b2SeR6F82tOeiv/IVZdoYiYLkHMQcp3Dv3D0Y42Quz7gssbFB9C uBfOTfXwUw+PN8Ilyzg7QMI9I+J0nZdMYfWkkPHzJsGbVxvnEWtD5fgERIyzLx8tN5FK eEz7Aa72Fm1y3jCi+DuQQzdkTwvTUgU63FYtoCMfTRNPKwS3JbuhN8H3FUBElhz8+piv 5X0A== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr28093356obb.71.1332778438808; Mon, 26 Mar 2012 09:13:58 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Mon, 26 Mar 2012 09:13:58 -0700 (PDT) In-Reply-To: <8E71D989-231C-46F4-A3B6-C5957F94E8B9@lacnic.net> References: <8E71D989-231C-46F4-A3B6-C5957F94E8B9@lacnic.net> Date: Mon, 26 Mar 2012 12:13:58 -0400 Message-ID: From: Christopher Morrow To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:14:00 -0000 On Mon, Mar 26, 2012 at 12:03 PM, Arturo Servin wrote: > > I think that you silently discarded my email: I didn't, I may not have read it ;( > http://www.ietf.org/mail-archive/web/sidr/current/msg04215.html > > Anyhow I wasn't expecting too much, but I least I tried. The October date may work out... would be good to discuss that though after this set is settled/scheduled. -chris > Regards, > .as > > On 26 Mar 2012, at 16:43, Christopher Morrow wrote: > > So, as stated in the meeting today, and in these slides: > =A0 > > There is a proposal to schedule 5 future Interim Face to Face > (+virtual) meetings. The dates/locations are: > > Mon Apr 30 - after ARIN (IAD) > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) > > The hope is that: > =A01) WG folks interested in the forward progress of the WG work can > attend (either physically or virtually) > =A02) WG folk interested see this number of meetings (about 1/month for > the next 6 months) as appropriate > =A03) the overlap/adjacency with existing operations meetings will help > travel problems AND bring in some ops focus/requirements as well to > the work. > > Please have a discussion on the applicability of the meetings (number > and attendance capabilities) and let's close that discussion out ~Mar > 29, 2012 23:59 Paris Local Time (CEST?). > > -Chris > > (Note: the deadline is to avoid scheduling/process deadlines in > getting the first meeting note out via IETF/IESG-secretary) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From aservin@lacnic.net Mon Mar 26 09:27:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A743121E8044; Mon, 26 Mar 2012 09:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU4Mxq29xUJs; Mon, 26 Mar 2012 09:27:44 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4C121E80CA; Mon, 26 Mar 2012 09:27:44 -0700 (PDT) Received: from dhcp-1390.meeting.ietf.org (dhcp-1390.meeting.ietf.org [130.129.19.144]) by mail.lacnic.net.uy (Postfix) with ESMTP id 64DA3308424; Mon, 26 Mar 2012 13:27:40 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Arturo Servin In-Reply-To: Date: Mon, 26 Mar 2012 18:27:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <8E71D989-231C-46F4-A3B6-C5957F94E8B9@lacnic.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:27:45 -0000 No worries. Thanks, .as On 26 Mar 2012, at 18:13, Christopher Morrow wrote: > On Mon, Mar 26, 2012 at 12:03 PM, Arturo Servin wrote: >> >> I think that you silently discarded my email: > > I didn't, I may not have read it ;( > >> http://www.ietf.org/mail-archive/web/sidr/current/msg04215.html >> >> Anyhow I wasn't expecting too much, but I least I tried. > > The October date may work out... would be good to discuss that though > after this set is settled/scheduled. > > -chris > >> Regards, >> .as >> >> On 26 Mar 2012, at 16:43, Christopher Morrow wrote: >> >> So, as stated in the meeting today, and in these slides: >> >> >> There is a proposal to schedule 5 future Interim Face to Face >> (+virtual) meetings. The dates/locations are: >> >> Mon Apr 30 - after ARIN (IAD) >> Wed Jun 6 - NANOG (YVR) >> Fri Jun 29 - (BWI/IAD) >> Fri Jul 27 - prior to IETF84 (YVR) >> Sun Sep 23 - prior to RIPE (AMS) >> >> The hope is that: >> 1) WG folks interested in the forward progress of the WG work can >> attend (either physically or virtually) >> 2) WG folk interested see this number of meetings (about 1/month for >> the next 6 months) as appropriate >> 3) the overlap/adjacency with existing operations meetings will help >> travel problems AND bring in some ops focus/requirements as well to >> the work. >> >> Please have a discussion on the applicability of the meetings (number >> and attendance capabilities) and let's close that discussion out ~Mar >> 29, 2012 23:59 Paris Local Time (CEST?). >> >> -Chris >> >> (Note: the deadline is to avoid scheduling/process deadlines in >> getting the first meeting note out via IETF/IESG-secretary) >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> >> From turners@ieca.com Mon Mar 26 09:45:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C605F21E80EF for ; Mon, 26 Mar 2012 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvAFkqw4oHh6 for ; Mon, 26 Mar 2012 09:45:46 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.179.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C321F8607 for ; Mon, 26 Mar 2012 09:45:46 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 047201C9D0224; Mon, 26 Mar 2012 11:45:46 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id E982B1C9D01E9 for ; Mon, 26 Mar 2012 11:45:45 -0500 (CDT) Received: from [130.129.37.148] (port=51379 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SCD3B-0004WA-21; Mon, 26 Mar 2012 11:45:45 -0500 Message-ID: <4F709D37.7030802@ieca.com> Date: Mon, 26 Mar 2012 18:45:43 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-2594.meeting.ietf.org [130.129.37.148]:51379 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:45:46 -0000 On #3, I really like the idea of having interim meetings close to events that are essentially operator-centric meetings. If this WG is in fact going to have protocols/boxes deployed/run by operator folk, it'd be really good to make it easy as possible for them to attend. I know some attend the IETF, but it always good to be as inclusive as possible. On #2, (I'll state the obvious) once a month meetings could be appropriate; however, the agendas will need to be posted early enough for folks to determine whether they want to go in person or be remote. As to the meeting date (and assuming the agendas are out early): Can attend remotely or in person. > Mon Apr 30 - after ARIN (IAD) I work to try to attend in person, but could definitely do it remotely. > Wed Jun 6 - NANOG (YVR) Can attend remotely or in person. > Fri Jun 29 - (BWI/IAD) Can attend remotely or in person. > Fri Jul 27 - prior to IETF84 (YVR) Not sure I can make this one in person, but could definitely do it remotely. > Sun Sep 23 - prior to RIPE (AMS) spt From sra@hactrn.net Mon Mar 26 10:33:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FCD21E80E5 for ; Mon, 26 Mar 2012 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+uKoYK+Ybgx for ; Mon, 26 Mar 2012 10:33:11 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 85ABA21F8569 for ; Mon, 26 Mar 2012 10:33:09 -0700 (PDT) Received: from minas-ithil.hactrn.net (dhcp-521d.meeting.ietf.org [130.129.82.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 127C428465 for ; Mon, 26 Mar 2012 17:33:07 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D1CB96E71B3 for ; Mon, 26 Mar 2012 19:33:05 +0200 (CEST) Date: Mon, 26 Mar 2012 19:33:05 +0200 From: Rob Austein To: sidr@ietf.org 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: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> Subject: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:33:12 -0000 For those who didn't get to see the end of the "RPKI Over BitTorrent" presentation in today's SIDR meeting, the full slide deck is available at http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf and should be relatively self-explanatory. From jayb@braeburn.org Mon Mar 26 11:16:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3E21E810F for ; Mon, 26 Mar 2012 11:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0LP8DT64IyR for ; Mon, 26 Mar 2012 11:16:11 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id EE36721E80CE for ; Mon, 26 Mar 2012 11:16:10 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id a62b07f4.0.362912.00-474.1005127.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 26 Mar 2012 18:16:10 +0000 (UTC) X-MXL-Hash: 4f70b26a65e18265-ea645b966501f1644802ae04ca83e60a91a60d90 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2QIGA7x002961 for ; Mon, 26 Mar 2012 14:16:10 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2QIG0Kn002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 14:16:03 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Mon, 26 Mar 2012 14:15:32 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2QIFWuj013125 for ; Mon, 26 Mar 2012 14:15:32 -0400 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2QIFRPM012935 for ; Mon, 26 Mar 2012 14:15:28 -0400 Received: by oz.mt.att.com (Postfix, from userid 500) id 8F99B2BF2C; Mon, 26 Mar 2012 14:15:27 -0400 (EDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 Message-ID: <20336.45627.147578.984228@oz.mt.att.com> Date: Mon, 26 Mar 2012 14:15:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: 7bit From: Jay Borkenhagen To: sidr wg list In-Reply-To: References: X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:16:12 -0000 Randy Bush writes: > at this afternoon's sidr ssion, i presented two open issue with > draft-ietf-sidr-pfx-validate-04.txt > > 1 - Should updates learned via iBGP be marked? > > 2 - Should updates injected into BGP on this router be marked? > > i think yes because: > o i want support of incremental deployment > o i do not want to find out I am announcing garbage when my neighbor$,1ry(Bs > NOC calls, mis-originations should be stopped at the source > > there was fear that, if used at other than edge routers, this allowed > creation of loops, as setting local pref etc, do. > > i think there was general agreement that this was ok on edge routers > and the point of injection, as that is logically an edge router. > > would like to see convergence on this I could not hear the discussion in the room today because the utter webex fail prevented my remote participation. So let me ask about today's discussion. Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just at ingress edge routers, and if the policy is broken it can result in loops. It's something to watch out for when designing a policy, but I am thankful that this kind of flexibility exists, because not all policies that manipulate attributes other than at ingress edges are broken. Regarding pfx-validate: I hope the agreement in the room was that a sane network design would probably involve setting a local 'origin has been checked' community on the first router inside the AS where that check occurred. I hope the agreement was _not_ that pfx-validate implementations should be hard-coded to assess validation state only at the ingress edge router. From wwwrun@rfc-editor.org Mon Mar 26 13:42:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A713F21E8116 for ; Mon, 26 Mar 2012 13:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hMiP9C2HtsA for ; Mon, 26 Mar 2012 13:42:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 385D521E8101 for ; Mon, 26 Mar 2012 13:42:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31F0BB1E003; Mon, 26 Mar 2012 13:41:37 -0700 (PDT) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, stbryant@cisco.com, adrian@olddog.co.uk, Sandra.Murphy@sparta.com, morrowc@ops-netman.net From: RFC Errata System Message-Id: <20120326204137.31F0BB1E003@rfc-editor.org> Date: Mon, 26 Mar 2012 13:41:37 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, sidr@ietf.org Subject: [sidr] [Technical Errata Reported] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 20:42:56 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168 -------------------------------------- Type: Technical Reported by: David Mandelberg Section: 4.8 Original Text ------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280]. Corrected Text -------------- or non-critical. A certificate-using system MUST reject the certificate if it encounters an extension not explicitly mentioned in this document. This is in contrast to RFC 5280 which allows non-critical extensions to be ignored. Notes ----- Other sections of the same document contradict the original section 4.8: Section 1: Any extensions not explicitly mentioned MUST be absent. The same applies to the CRLs used in the RPKI, that are also profiled in this document. Section 8: Certificate Extensions: This profile does not permit the use of any other critical or non-critical extensions. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From robertl@apnic.net Mon Mar 26 15:59:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54221F8575 for ; Mon, 26 Mar 2012 15:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP6PvRrFHKgT for ; Mon, 26 Mar 2012 15:59:05 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3F70221F8573 for ; Mon, 26 Mar 2012 15:59:04 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:6c83:8760:30d3:5600] (unknown [IPv6:2001:dc0:a000:4:6c83:8760:30d3:5600]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0F577B66CC; Tue, 27 Mar 2012 08:59:03 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_CE8E8A12-C808-423E-B9EE-395F17C97AC8"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robert Loomans In-Reply-To: <20120326204137.31F0BB1E003@rfc-editor.org> Date: Tue, 27 Mar 2012 08:59:02 +1000 Message-Id: References: <20120326204137.31F0BB1E003@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1257) Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, ggm@apnic.net Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 22:59:06 -0000 --Apple-Mail=_CE8E8A12-C808-423E-B9EE-395F17C97AC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe this errata is accurate: the intention was to limit extensions = to only those mentioned in RFC. Rob On 27/03/2012, at 06:41, RFC Errata System wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D3168 >=20 > -------------------------------------- > Type: Technical > Reported by: David Mandelberg >=20 > Section: 4.8 >=20 > Original Text > ------------- > or non-critical. A certificate-using system MUST reject the > certificate if it encounters a critical extension it does not > recognize; however, a non-critical extension MAY be ignored if it is > not recognized [RFC5280]. >=20 > Corrected Text > -------------- > or non-critical. A certificate-using system MUST reject the > certificate if it encounters an extension not explicitly mentioned > in this document. This is in contrast to RFC 5280 which allows > non-critical extensions to be ignored. >=20 > Notes > ----- > Other sections of the same document contradict the original section = 4.8: >=20 > Section 1: >=20 > Any extensions not explicitly mentioned MUST be absent. The same > applies to the CRLs used in the RPKI, that are also profiled in this > document. >=20 > Section 8: >=20 > Certificate Extensions: > This profile does not permit the use of any other critical or > non-critical extensions. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG --=20 Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 --Apple-Mail=_CE8E8A12-C808-423E-B9EE-395F17C97AC8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH2zCCA8ow ggKyoAMCAQICCD2r7AwmaYdlMA0GCSqGSIb3DQEBBQUAMHIxEDAOBgNVBAMMB3Jvb3QtY2ExEjAQ BgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwIQnJpc2Jh bmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUwHhcNMTAwNTExMDQyODAzWhcNMTUw NTExMDQyODAzWjBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYD VQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNh MQswCQYDVQQGEwJBVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDIhBZoGNolhTjw o5Gkb9BX9OnqIE4xhbUKT8k1dA83q5DRutJbLDfzOiKN81FnbeuJijKwHo8QMAM4+hJW/fjGLXMe G25PD06aAX7kuyF/n4SJZ1YnZOp4wriYYDvEtp5WHtxSaJWBrRgzoQYo8fCRFC3QF+TPDtijQO36 AEmy0Y1hOokR6ps9s97VT8e/bGfrE3kXRzWLLGupM0++Px2A3GCmvnxI4keslVp5lZI8ULddVX0s GXqbjlcdHipQF3MklYO7glX3/lpAJupo3yk+xOCJu+g/GVkUAEl86VTQPKR7zUnRukuzCJ70h6Zj QTwYE2lVtfMir69Mx8a30r8CAwEAAaNjMGEwHQYDVR0OBBYEFOA9t5Jb7i6jsj5520WrMEIvAUus MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUbtpM6r1cZ29SwAakpWJiv0BBFTIwDgYDVR0P AQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQCgXALZN+XpsFl3TYi4l8UbwSvGMrQg7/6SYilO rm59coWoz1bfWV6sYGNRnLn7GQSVaBttk25FqHd/mQJNrphK+c6ajcEYCSBLp+1S+k+Zul3biwhr X5kFmt6KDN/JLmpCN8lUjcXUzsbBNeDQB66/z4Q5oEEw6znDMd7xgQgFqSw1fzrvM/3hVBkeiqa/ zrY6P3gb2yxmDlM5fET9ebwo+EHrMfyM15XwxFz2bUHXI2o4asIkxgVfNlBSB2n7MBaF/piXrEB/ eH1fq+JmZsBfqxEMr0yamcz1QpLIZrDcNVaW5dWgeSVpoPmqnmB2tqwQ6/5yN93CBj4Iid+14Owc MIIECTCCAvGgAwIBAgIIW5bkBlIxeZYwDQYJKoZIhvcNAQEFBQAwczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUwHhcNMTEwNjE2MDMwODQx WhcNMTIwNjE1MDMwODQxWjCBlTEXMBUGCgmSJomT8ixkAQEMB3JvYmVydGwxFzAVBgNVBAMMDlJv YmVydCBMb29tYW5zMQ8wDQYDVQQqDAZSb2JlcnQxEDAOBgNVBAQMB0xvb21hbnMxDzANBgNVBAsM BlBlb3BsZTEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDEVMBMGCgmSJomT8ixkARkWBXN0YWZmMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9B1yJxAdw5+8RL+HbUoRvEKWze7JRB7SSqn3 3+8Nd+XCvLaSeG2ix7CJkTFndUtvqkCC88j7eACtwvUhoknqGo/Gx4k6b7oEnBDCPyHldT+U+6kr C2ThnNMeiJrDxHn4C38wr3wrNpjGdEtK/27tjIugiwDHWQ4XXQzmqKGIq6f5KWB7HaRuBD0On0wv 9squhD5rxG3M3L426QsvTDQ8zP5ba8lTHNNcf3Qg512sH0R9Zml1lg3OQfnHwjzrtxNl27qnF9aw vLRvJ/zrTuZEncwsDL/XzTCqlwtLlCFFCIe8BMG9GKwJLOMRF4X9/xpBTXK5UKC82UQ1smN0MqcW DQIDAQABo34wfDAdBgNVHQ4EFgQUHoUAgpOpvzPZJI+Q5L7qD8p2N9swDAYDVR0TAQH/BAIwADAf BgNVHSMEGDAWgBTgPbeSW+4uo7I+edtFqzBCLwFLrDAOBgNVHQ8BAf8EBAMCAfIwHAYDVR0RBBUw E4ERcm9iZXJ0bEBhcG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBABbJc7+7y0TU47TnleC6u3HF cMwBW+vbIo7Ed481tDiyJo/HfABNxE63mJuNCGS3l7qa5PMWyYVbvVWVEQV2mvIF/G/W5alCh0Pj OAQolPHp5ezeAXK6+JECzzV1iho/4vvSPD5iv2dZYumgGe84gqBhVijlVI23hpANM2vhf2rITfYo PcT5nv9fCBRlDZJnCiSSfcpZksjVQ/ULn5MLvnOnIImkVYcmtPIc2rSqq5Be9q+nfCHMkw62s6TA gH3lqwKRsbeHqReFADZxheg11pvdhHEGT0cvCpcBo33bBHPTZckZWnWs/t61ge6iHr2aviO5gXWx JD7G0jWdzxHPcKExggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlU ZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYK CZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVAghbluQGUjF5ljAJBgUrDgMCGgUAoIIBgzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAzMjYyMjU5MDJaMCMGCSqG SIb3DQEJBDEWBBQf9sCftAKtAYmb0jktuXwa5/0kpjCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8G A1UEAwwIc3RhZmYtY2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0 ZDERMA8GA1UEBwwIQnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCFuW 5AZSMXmWMIGRBgsqhkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQL DAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIw EAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVAghbluQGUjF5ljANBgkqhkiG9w0BAQEFAASC AQDnfcBaKD9mdPqZwKbgzm4KsgQvEUyQfzfPZXLPBHgCp6mIxnDPreAdtSMvW6yOIXEhz2mJzmTO H8OInOcH8L3WD0WzYDJrWR1gvfK2F2GA1Q2ls3PlDMQGih7aGdDXqBvBH8GKBWy9gAenKp1kcwLu eTqfCqLW7Tf6aHzh3ADKgEvvs6qdRNA553DDt9/EwqXLuLTga+cgsrRTl5bUtEQ02d7u0gdk9iTf xh9ipi1+Hknx1hVUsTV10Z+IFp6L86TRKmhFHjCHMfVgCXtnAtZNtPIlJbGNxuFItsTIBfnTthZ2 CDMMgRo5rUE0fShVmbH4DpykX+1C44Sb16VYf+KcAAAAAAAA --Apple-Mail=_CE8E8A12-C808-423E-B9EE-395F17C97AC8-- From gih@apnic.net Mon Mar 26 20:33:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA321E8055 for ; Mon, 26 Mar 2012 20:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfZMWuMNW8DR for ; Mon, 26 Mar 2012 20:33:20 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id CACB021E8050 for ; Mon, 26 Mar 2012 20:33:19 -0700 (PDT) Received: from dynamic141.apnic.net (dynamic141.apnic.net [203.119.42.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id EB691B67D6; Tue, 27 Mar 2012 13:33:13 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <20120326204137.31F0BB1E003@rfc-editor.org> Date: Tue, 27 Mar 2012 14:33:07 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <20120326204137.31F0BB1E003@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1257) Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, ggm@apnic.net Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 03:33:21 -0000 > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. verified. Geoff On 27/03/2012, at 7:41 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168 > > -------------------------------------- > Type: Technical > Reported by: David Mandelberg > > Section: 4.8 > > Original Text > ------------- > or non-critical. A certificate-using system MUST reject the > certificate if it encounters a critical extension it does not > recognize; however, a non-critical extension MAY be ignored if it is > not recognized [RFC5280]. > > Corrected Text > -------------- > or non-critical. A certificate-using system MUST reject the > certificate if it encounters an extension not explicitly mentioned > in this document. This is in contrast to RFC 5280 which allows > non-critical extensions to be ignored. > > Notes > ----- > Other sections of the same document contradict the original section 4.8: > > Section 1: > > Any extensions not explicitly mentioned MUST be absent. The same > applies to the CRLs used in the RPKI, that are also profiled in this > document. > > Section 8: > > Certificate Extensions: > This profile does not permit the use of any other critical or > non-critical extensions. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From Sandra.Murphy@sparta.com Mon Mar 26 23:38:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ECA21F8771 for ; Mon, 26 Mar 2012 23:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0DIBhMNoXz0 for ; Mon, 26 Mar 2012 23:38:29 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5ED21F8454 for ; Mon, 26 Mar 2012 23:38:29 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2R6cJTw012914; Tue, 27 Mar 2012 01:38:19 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2R6cIYL002437; Tue, 27 Mar 2012 01:38:18 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 02:38:18 -0400 From: "Murphy, Sandra" To: Geoff Huston , RFC Errata System Thread-Topic: [Technical Errata Reported] RFC6487 (3168) Thread-Index: AQHNC5EHeM1SdhjBTEK0yND38V+CWpZ9wJKA///toZE= Date: Tue, 27 Mar 2012 06:38:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CA9D7@Hermes.columbia.ads.sparta.com> References: <20120326204137.31F0BB1E003@rfc-editor.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "morrowc@ops-netman.net" , "sidr@ietf.org" , "ggm@apnic.net" Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 06:38:30 -0000 Thank you, Geoff. I agree.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Geoff Huston [gih@apnic.net]=0A= Sent: Monday, March 26, 2012 11:33 PM=0A= To: RFC Errata System=0A= Cc: ggm@apnic.net; robertl@apnic.net; stbryant@cisco.com; adrian@olddog.co.= uk; Murphy, Sandra; morrowc@ops-netman.net; dmandelb@bbn.com; sidr@ietf.org= =0A= Subject: Re: [Technical Errata Reported] RFC6487 (3168)=0A= =0A= > This errata is currently posted as "Reported". If necessary, please=0A= > use "Reply All" to discuss whether it should be verified or=0A= > rejected. When a decision is reached, the verifying party (IESG)=0A= > can log in to change the status and edit the report, if necessary.=0A= =0A= =0A= verified.=0A= =0A= Geoff=0A= =0A= =0A= On 27/03/2012, at 7:41 AM, RFC Errata System wrote:=0A= =0A= >=0A= > The following errata report has been submitted for RFC6487,=0A= > "A Profile for X.509 PKIX Resource Certificates".=0A= >=0A= > --------------------------------------=0A= > You may review the report below and at:=0A= > http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D3168=0A= >=0A= > --------------------------------------=0A= > Type: Technical=0A= > Reported by: David Mandelberg =0A= >=0A= > Section: 4.8=0A= >=0A= > Original Text=0A= > -------------=0A= > or non-critical. A certificate-using system MUST reject the=0A= > certificate if it encounters a critical extension it does not=0A= > recognize; however, a non-critical extension MAY be ignored if it is=0A= > not recognized [RFC5280].=0A= >=0A= > Corrected Text=0A= > --------------=0A= > or non-critical. A certificate-using system MUST reject the=0A= > certificate if it encounters an extension not explicitly mentioned=0A= > in this document. This is in contrast to RFC 5280 which allows=0A= > non-critical extensions to be ignored.=0A= >=0A= > Notes=0A= > -----=0A= > Other sections of the same document contradict the original section 4.8:= =0A= >=0A= > Section 1:=0A= >=0A= > Any extensions not explicitly mentioned MUST be absent. The same=0A= > applies to the CRLs used in the RPKI, that are also profiled in this=0A= > document.=0A= >=0A= > Section 8:=0A= >=0A= > Certificate Extensions:=0A= > This profile does not permit the use of any other critical or=0A= > non-critical extensions.=0A= >=0A= > Instructions:=0A= > -------------=0A= > This errata is currently posted as "Reported". If necessary, please=0A= > use "Reply All" to discuss whether it should be verified or=0A= > rejected. When a decision is reached, the verifying party (IESG)=0A= > can log in to change the status and edit the report, if necessary.=0A= >=0A= > --------------------------------------=0A= > RFC6487 (draft-ietf-sidr-res-certs-22)=0A= > --------------------------------------=0A= > Title : A Profile for X.509 PKIX Resource Certificates=0A= > Publication Date : February 2012=0A= > Author(s) : G. Huston, G. Michaelson, R. Loomans=0A= > Category : PROPOSED STANDARD=0A= > Source : Secure Inter-Domain Routing=0A= > Area : Routing=0A= > Stream : IETF=0A= > Verifying Party : IESG=0A= =0A= --=0A= =0A= Geoff Huston=0A= Chief Scientist, APNIC=0A= =0A= +61 7 3858 3100=0A= gih@apnic.net=0A= =0A= =0A= =0A= =0A= From Sandra.Murphy@sparta.com Mon Mar 26 23:42:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3131D21F8425 for ; Mon, 26 Mar 2012 23:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPO5FH1H-6IH for ; Mon, 26 Mar 2012 23:42:37 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4197C21F8413 for ; Mon, 26 Mar 2012 23:42:37 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2R6gSjZ012941; Tue, 27 Mar 2012 01:42:28 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2R6gREF002467; Tue, 27 Mar 2012 01:42:28 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 02:42:27 -0400 From: "Murphy, Sandra" To: Geoff Huston , RFC Errata System Thread-Topic: [Technical Errata Reported] RFC6487 (3168) Thread-Index: AQHNC5EHeM1SdhjBTEK0yND38V+CWpZ9wJKA///xhi8= Date: Tue, 27 Mar 2012 06:42:26 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CA9F2@Hermes.columbia.ads.sparta.com> References: <20120326204137.31F0BB1E003@rfc-editor.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "morrowc@ops-netman.net" , "sidr@ietf.org" , "ggm@apnic.net" Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3168) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 06:42:38 -0000 Thank you, Geoff. I agree.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Geoff Huston [gih@apnic.net]=0A= Sent: Monday, March 26, 2012 11:33 PM=0A= To: RFC Errata System=0A= Cc: ggm@apnic.net; robertl@apnic.net; stbryant@cisco.com; adrian@olddog.co.= uk; Murphy, Sandra; morrowc@ops-netman.net; dmandelb@bbn.com; sidr@ietf.org= =0A= Subject: Re: [Technical Errata Reported] RFC6487 (3168)=0A= =0A= > This errata is currently posted as "Reported". If necessary, please=0A= > use "Reply All" to discuss whether it should be verified or=0A= > rejected. When a decision is reached, the verifying party (IESG)=0A= > can log in to change the status and edit the report, if necessary.=0A= =0A= =0A= verified.=0A= =0A= Geoff=0A= =0A= =0A= On 27/03/2012, at 7:41 AM, RFC Errata System wrote:=0A= =0A= >=0A= > The following errata report has been submitted for RFC6487,=0A= > "A Profile for X.509 PKIX Resource Certificates".=0A= >=0A= > --------------------------------------=0A= > You may review the report below and at:=0A= > http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D3168=0A= >=0A= > --------------------------------------=0A= > Type: Technical=0A= > Reported by: David Mandelberg =0A= >=0A= > Section: 4.8=0A= >=0A= > Original Text=0A= > -------------=0A= > or non-critical. A certificate-using system MUST reject the=0A= > certificate if it encounters a critical extension it does not=0A= > recognize; however, a non-critical extension MAY be ignored if it is=0A= > not recognized [RFC5280].=0A= >=0A= > Corrected Text=0A= > --------------=0A= > or non-critical. A certificate-using system MUST reject the=0A= > certificate if it encounters an extension not explicitly mentioned=0A= > in this document. This is in contrast to RFC 5280 which allows=0A= > non-critical extensions to be ignored.=0A= >=0A= > Notes=0A= > -----=0A= > Other sections of the same document contradict the original section 4.8:= =0A= >=0A= > Section 1:=0A= >=0A= > Any extensions not explicitly mentioned MUST be absent. The same=0A= > applies to the CRLs used in the RPKI, that are also profiled in this=0A= > document.=0A= >=0A= > Section 8:=0A= >=0A= > Certificate Extensions:=0A= > This profile does not permit the use of any other critical or=0A= > non-critical extensions.=0A= >=0A= > Instructions:=0A= > -------------=0A= > This errata is currently posted as "Reported". If necessary, please=0A= > use "Reply All" to discuss whether it should be verified or=0A= > rejected. When a decision is reached, the verifying party (IESG)=0A= > can log in to change the status and edit the report, if necessary.=0A= >=0A= > --------------------------------------=0A= > RFC6487 (draft-ietf-sidr-res-certs-22)=0A= > --------------------------------------=0A= > Title : A Profile for X.509 PKIX Resource Certificates=0A= > Publication Date : February 2012=0A= > Author(s) : G. Huston, G. Michaelson, R. Loomans=0A= > Category : PROPOSED STANDARD=0A= > Source : Secure Inter-Domain Routing=0A= > Area : Routing=0A= > Stream : IETF=0A= > Verifying Party : IESG=0A= =0A= --=0A= =0A= Geoff Huston=0A= Chief Scientist, APNIC=0A= =0A= +61 7 3858 3100=0A= gih@apnic.net=0A= =0A= =0A= =0A= =0A= From Sandra.Murphy@sparta.com Tue Mar 27 01:32:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD7D21F87E4; Tue, 27 Mar 2012 01:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAwyjIOGpy53; Tue, 27 Mar 2012 01:32:53 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB121F8875; Tue, 27 Mar 2012 01:32:53 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2R8WnCR013358; Tue, 27 Mar 2012 03:32:50 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2R8WnD6004503; Tue, 27 Mar 2012 03:32:49 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 04:32:49 -0400 From: "Murphy, Sandra" To: Samuel Weiler , Christopher Morrow Thread-Topic: [sidr] Interim Meeting Dates/Locations (Proposed) Thread-Index: AQHNC17VnjKW5ZyGPEeJcvfuAwayupZ88rAAgADbEcA= Date: Tue, 27 Mar 2012 08:32:48 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CAA88@Hermes.columbia.ads.sparta.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:32:54 -0000 Moderate badness in the Monday meeting was due to my laptop communication p= roblems. Suggestions welcome as how to handle such a situation better. Pk= t loss for me varied 0-33-50-100%. Help desk and NOC were unable to diagno= se. =0A= =0A= On hotel wireless, I see congestion (judged by ping latencies) and slowness= from time to time, but nothing as debilitating as in the conference center= . It was not only in the room, it was everywhere. More diagnosis attempts= with help desk today, else I will have to find alternate platform for Wed = meeting.=0A= =0A= Chris and I have equal access to meeting materials, webex codes, etc. so we= have backup in case one laptop fails. Which was the only way we were able= to progress this time.=0A= =0A= I should have printed everything. People snicker at those who carry paper,= but paper doesn't have pkt loss, or congestion, or blue screen, etc.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Samuel Wei= ler [weiler@watson.org]=0A= Sent: Monday, March 26, 2012 11:14 AM=0A= To: Christopher Morrow=0A= Cc: sidr-chairs@ietf.org; sidr@ietf.org=0A= Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed)=0A= =0A= I am content to have interim meetings iff the WG commits to improving=0A= the technical facilities for remote participants. That was fumbled=0A= badly at the San Diego interim meeting and moderately badly today.=0A= We need to do better.=0A= =0A= To encourage us to do better, I suggest that the first of these=0A= interims (on whatever date; see below) be virtual-only. If we=0A= continue to have technical foibles, I suggest that the remaining=0A= interims be cancelled entirely.=0A= =0A= On Mon, 26 Mar 2012, Christopher Morrow wrote:=0A= =0A= > Mon Apr 30 - after ARIN (IAD)=0A= > Fri Jun 29 - (BWI/IAD)=0A= > Fri Jul 27 - prior to IETF84 (YVR)=0A= =0A= Neither of these Fridays work for me (June 29th at all, July 27th in=0A= person) due to prior commitments, and the Monday is dicey. My general=0A= preference would be to have these meetings midweek (Tues/Wed/Thurs),=0A= thereby avoiding weekend-impinging travel.=0A= =0A= > Wed Jun 6 - NANOG (YVR)=0A= =0A= But that's World IPv6 Launch Day! (No real objection.)=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From tim@ripe.net Tue Mar 27 01:45:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D493721F893B; Tue, 27 Mar 2012 01:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe8z4B8KvGso; Tue, 27 Mar 2012 01:45:29 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id A862521E8063; Tue, 27 Mar 2012 01:45:21 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SCS1n-0000sd-Cl; Tue, 27 Mar 2012 10:45:20 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SCS1n-0003mK-7E; Tue, 27 Mar 2012 10:45:19 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Tue, 27 Mar 2012 10:45:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AE49CA5-A647-41B2-9E10-D2CDAA399AE1@ripe.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1084) 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: 784d7acfe6559f2a0b602ec6519a07194e04f5cfa1d7e7dbc1b9475514a27919 Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:45:32 -0000 On 26 Mar 2012, at 16:43, Christopher Morrow wrote: > So, as stated in the meeting today, and in these slides: > >=20 > There is a proposal to schedule 5 future Interim Face to Face > (+virtual) meetings. The dates/locations are: >=20 > Mon Apr 30 - after ARIN (IAD) Can not attend. > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) Can attend remotely depending on agenda. > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) >=20 Can attend in person. > The hope is that: > 1) WG folks interested in the forward progress of the WG work can > attend (either physically or virtually) > 2) WG folk interested see this number of meetings (about 1/month for > the next 6 months) as appropriate > 3) the overlap/adjacency with existing operations meetings will help > travel problems AND bring in some ops focus/requirements as well to > the work. >=20 > Please have a discussion on the applicability of the meetings (number > and attendance capabilities) and let's close that discussion out ~Mar > 29, 2012 23:59 Paris Local Time (CEST?). >=20 As I stated before I prefer to have the extra time during, or next to, = an IETF -- I already planned to attend those. So the extra meeting in = Vancouver works for me. I understand that a higher frequency is good for = momentum but extra travel is not possible for me and remote attendance = is not ideal. > -Chris > > (Note: the deadline is to avoid scheduling/process deadlines in > getting the first meeting note out via IETF/IESG-secretary) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Tue Mar 27 02:08:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC95321F886E; Tue, 27 Mar 2012 02:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-Dot9tvdcnb; Tue, 27 Mar 2012 02:08:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4483121F886B; Tue, 27 Mar 2012 02:08:53 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7408567obb.31 for ; Tue, 27 Mar 2012 02:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aBYWt2kGp9QmCmHOofdkhsyCzG/Syh+5hVKLurJdCEY=; b=MtcEnEz8e5l+TbmjsWktGKEI+GMYn4jXXY3Z3VeBIVjW2+UQSzF5jFsLocOjX7rcE3 qip+BvMBPee9tWxazMnjKawlPc+X1zcriUd4UD6mC8xtiQb5qx1dym8YBx9zJgg3ei1y y7aa0u9mKWDaYXRGYfdv5+ivbDivpM0fk1ZZxZueLUAUomciYRLGwkKPZxoX2ShgGEmN lSdSwSRlFgE0koEsCs2xEvvcxNqMjl2FHmGa0RI8SIewcElnOz1BlQ0IuumVLmBLr+QR yAvNMmCPJn3pWQyfboQmRZi2NBuI4kvIglwMUyl4sE7gti+tvqP9XdXvesm1l4KR4qXR 1muA== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr31016010oei.71.1332839332784; Tue, 27 Mar 2012 02:08:52 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Tue, 27 Mar 2012 02:08:52 -0700 (PDT) In-Reply-To: <3AE49CA5-A647-41B2-9E10-D2CDAA399AE1@ripe.net> References: <3AE49CA5-A647-41B2-9E10-D2CDAA399AE1@ripe.net> Date: Tue, 27 Mar 2012 05:08:52 -0400 Message-ID: From: Christopher Morrow To: Tim Bruijnzeels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:08:54 -0000 On Tue, Mar 27, 2012 at 4:45 AM, Tim Bruijnzeels wrote: > As I stated before I prefer to have the extra time during, or next to, an= IETF -- I already planned to attend those. So the extra meeting in Vancouv= er works for me. I understand that a higher frequency is good for momentum = but extra travel is not possible for me and remote attendance is not ideal. > summarizing a constant thrum.... "Yes, not everyone can make every interim proposed. Yes not everyone can make the virtual version of same. That is ok..." Thanks for the info though! -chris From kent@bbn.com Tue Mar 27 03:23:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3D521F89CB; Tue, 27 Mar 2012 03:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.393 X-Spam-Level: X-Spam-Status: No, score=-106.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7C9qygSrRJg; Tue, 27 Mar 2012 03:23:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BD21F89CA; Tue, 27 Mar 2012 03:23:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58738 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCTYk-000HOm-Hm; Tue, 27 Mar 2012 06:23:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 27 Mar 2012 06:23:36 -0400 To: Christopher Morrow From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:23:41 -0000 At 10:43 AM -0400 3/26/12, Christopher Morrow wrote: >So, as stated in the meeting today, and in these slides: > > >There is a proposal to schedule 5 future Interim Face to Face >(+virtual) meetings. The dates/locations are: > >Mon Apr 30 - after ARIN (IAD) can't make it >Wed Jun 6 - NANOG (YVR) ditto >Fri Jun 29 - (BWI/IAD) possible >Fri Jul 27 - prior to IETF84 (YVR) I'll be there. >Sun Sep 23 - prior to RIPE (AMS) I can try to be there. Adjacent to IETF is always viable for me. NANOG and ARIN meetings not likely. RIPE meetings maybe. Steve From mlepinski@bbn.com Tue Mar 27 05:13:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBE21F893F for ; Tue, 27 Mar 2012 05:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56r-fHaGiQyr for ; Tue, 27 Mar 2012 05:13:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A2FC821F893E for ; Tue, 27 Mar 2012 05:13:16 -0700 (PDT) Received: from [128.89.254.178] (port=49976) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCVGo-000Izi-PD for sidr@ietf.org; Tue, 27 Mar 2012 08:13:02 -0400 Message-ID: <4F71AEDA.6010609@bbn.com> Date: Tue, 27 Mar 2012 08:13:14 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:13:18 -0000 I support the idea of rapid progress through frequent interim meetings. However, in order to make this work, we really need to make virtual participation more successful than we did at the May meeting in San Diego. On 3/26/2012 10:43 AM, Christopher Morrow wrote: > Mon Apr 30 - after ARIN (IAD) > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) > I can make all of these meetings virtually. I will attempt to make the meetings in person. - Matt Lepinski From internet-drafts@ietf.org Tue Mar 27 06:03:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63621F8917; Tue, 27 Mar 2012 06:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9OsXi4QoT2p; Tue, 27 Mar 2012 06:03:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A946F21E81E9; Tue, 27 Mar 2012 06:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327130356.19485.75055.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 06:03:56 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-impl-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:03:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI Router Implementation Report Author(s) : Randy Bush Rob Austein Keyur Patel Hannes Gredler Matthias Waehlisch Filename : draft-ietf-sidr-rpki-rtr-impl-00.txt Pages : 11 Date : 2012-03-26 This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-impl-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-impl-00.txt From Sandra.Murphy@sparta.com Tue Mar 27 06:55:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9621F8A2B for ; Tue, 27 Mar 2012 06:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrWMLe8iAqcI for ; Tue, 27 Mar 2012 06:55:13 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E10CC21E81CE for ; Tue, 27 Mar 2012 06:55:12 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2RDtCtF015227 for ; Tue, 27 Mar 2012 08:55:12 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2RDtB2u011780 for ; Tue, 27 Mar 2012 08:55:11 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 09:55:11 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: jabber scribe and minute taker volunteers Thread-Index: Ac0MITnv/V4dT/yrS9eUsyzgQp+maw== Date: Tue, 27 Mar 2012 13:55:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CAC93@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] jabber scribe and minute taker volunteers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:55:14 -0000 We need jabber scribe and minute taker volunteers for the Wed 9am meeting.= =0A= =0A= Please volunteer. It is a unwelcome delay to get a volunteer during meetin= g time.=0A= =0A= --Sandy, co-chair=0A= =0A= From terry.manderson@icann.org Tue Mar 27 13:22:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0ED921F8593; Tue, 27 Mar 2012 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4KWJFVempQq; Tue, 27 Mar 2012 13:22:11 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4661C21F8653; Tue, 27 Mar 2012 13:22:11 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 27 Mar 2012 13:22:10 -0700 From: Terry Manderson To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" Date: Tue, 27 Mar 2012 13:22:08 -0700 Thread-Topic: [sidr] Interim Meeting Dates/Locations (Proposed) Thread-Index: Ac0LXuQExR1WRumXQyKDkBCVMo2CSAA+GRjn Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415760528_9828932" MIME-Version: 1.0 Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:22:12 -0000 --B_3415760528_9828932 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 27/03/12 12:43 AM, "Christopher Morrow" wrote: > So, as stated in the meeting today, and in these slides: > > > There is a proposal to schedule 5 future Interim Face to Face > (+virtual) meetings. The dates/locations are: > > Mon Apr 30 - after ARIN (IAD) > Wed Jun 6 - NANOG (YVR) > Fri Jun 29 - (BWI/IAD) > Fri Jul 27 - prior to IETF84 (YVR) > Sun Sep 23 - prior to RIPE (AMS) > > The hope is that: > 1) WG folks interested in the forward progress of the WG work can > attend (either physically or virtually) > 2) WG folk interested see this number of meetings (about 1/month for > the next 6 months) as appropriate > 3) the overlap/adjacency with existing operations meetings will help > travel problems AND bring in some ops focus/requirements as well to > the work. > > Please have a discussion on the applicability of the meetings (number > and attendance capabilities) and let's close that discussion out ~Mar > 29, 2012 23:59 Paris Local Time (CEST?). > I feel like the Monday meeting was a bit of a lost opportunity. I appreciate that the presenters made effort in presenting, and making slides and presenting ideas. However I feel like the "RPKI over Bittorrent" really needed focused discussion on what the problem is, and a resulting definition of what RPKI needs in a requirements spec to address the problems that were alluded (and BTW I am more than happy to help form that set of requirements). Equally I appreciate the time taken in predicting the signing impact on router CPU, but without some more concrete lab work I felt a little lost as being able to take anything away from it at this stage. So I'm not intending to enter into a discussion on those topics here (but will commit to posting on both those items on list), but for me I think this speaks to the applicability of the interim meetings, so I humbly ask the chairs to keep the agenda tightly focused. The reason is that I have every intention of attending these meetings virtually, and will further try to make it in person (budget pending) - but for both of these to get most value, I would appreciate that it syncs up with documents in play. Cheers Terry --B_3415760528_9828932 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUA7OBze0mr/gxaHPZ/zW4jzLGFPAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMzI3MjAyMjA4WjANBgkqhkiG 9w0BAQEFAASCAQBbWPEQTslddidKB7S9SrjXHC4Q1HovhnFGcYC/FcWwoQSVV6fjhbW4aHGn ELlKC7/t3i1HXlQdoyZvaMhtfkGx1kyDmMTFBFNHN4SNgxv8KkazQWtkE7tIL5GY+0z5vngA vodZa+NqF4Pq4+o9V01keJikNEm5qSg+af0SsSREEdNB8zv7Fe2spcmbEF0PQwsHFrQ/r5jx Zv8utM1ziQFQZVe3MxT2wM0yn/L5+2yYKoppUiMBUMYwAhn8jN3YScsJXvjAOEbZDNe6W8tc 9bOqjWg+NukUTCzes3Wrv65K5XQbH2N+/HoIAjten+uZw9y+S5uT4ygebep+dsAlG5tN --B_3415760528_9828932-- From weiler@watson.org Tue Mar 27 14:52:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0960D21F8680; Tue, 27 Mar 2012 14:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDnrK3Sguv8R; Tue, 27 Mar 2012 14:52:46 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4682621F867E; Tue, 27 Mar 2012 14:52:46 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2RLqgjM085172; Tue, 27 Mar 2012 17:52:42 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2RLqg7S085169; Tue, 27 Mar 2012 17:52:42 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 27 Mar 2012 17:52:42 -0400 (EDT) From: Samuel Weiler To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CAA88@Hermes.columbia.ads.sparta.com> Message-ID: References: , <24B20D14B2CD29478C8D5D6E9CBB29F60F6CAA88@Hermes.columbia.ads.sparta.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 27 Mar 2012 17:52:42 -0400 (EDT) Cc: Christopher Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:52:47 -0000 On Tue, 27 Mar 2012, Murphy, Sandra wrote: > Moderate badness in the Monday meeting was due to my laptop > communication problems. Suggestions welcome as how to handle such a > situation better. Thank you for asking. 1) First and foremost, delegate the tech issues to two or more persons who do not have responsibilities to chair, present, scribe, or jabber scribe. Ideally, find people who are unlikely to be active participants in the meeting. It's fine to bring in outside help. 2) Have spares for all key hardware. This includes laptops, audio gear, network gear, network connections, and phone connections. Cables and power supplies need spares, also -- a dead power supply can mean a dead laptop. Based on experience in San Diego I suggest having at least three pieces of all key gear. Have fallbacks in case a service provider fails: if you're planning to use Meetecho, ALSO have a WebEx session and a PSTN bridge set up and ready to go. 3) Test both primary and spare hardware and service providers in multiple combinations prior to the meeting. The more testing you do, the more you can get away with only a single spare. Testing needs to happen in the real meeting environment using the same phone lines, net connections, and audio hardware that will be available during the meeting. The more removed your testing environment is from the real meeting environment, the more you need that second spare. 4) When a relatively large number of participants will be in a single space, provide high-quality microphones. The average Polycom microphone still sounds like a speakerphone, and listening to people talking through one all day gives remote participants a clearly second-class experience. If possible, give every participant his own microphone (with mute switch!). At the very least, provide a floor or wireless handheld microphone as we have at the regular IETF meetings and make sure people use it. Yes, this is a lot to do. Yes, I'm saying to have three net connections[1]. Remember, you're not doing this yourself (at least, not if you're following suggestion #1). In fact, no one person is stuck with all of this. And "spares" don't have to be sitting-in-a-box-and-hauled-around-the-world-the-to-be-a-spare: they can be a meeting participant's personal power brick, so long as you're sure there's going to be that spare in the room and the person is willing to part with it should the need arise. -- Sam [1] This is based on the San Diego experience where the hotel net connection was terrible and the backup net was a 4G hotspot. While both could move some packets, they were not enough to handle both remote participation and the normal packet-pushing desires of those in the room. A 3G or 4G device could easily be the backup net, so long as 1) there is actually service in the meeting space and 2) the device gives priority to the remote participation traffic and avoids getting bogged down by routine email checking and web browsing. From mlepinski@bbn.com Tue Mar 27 15:05:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0021E8133 for ; Tue, 27 Mar 2012 15:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+LuYupAXCcQ for ; Tue, 27 Mar 2012 15:05:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E85FC21E8126 for ; Tue, 27 Mar 2012 15:05:41 -0700 (PDT) Received: from [128.89.255.2] (port=49699) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCeW5-000ALT-Ti for sidr@ietf.org; Tue, 27 Mar 2012 18:05:27 -0400 Message-ID: <4F7239B0.6000107@bbn.com> Date: Tue, 27 Mar 2012 18:05:36 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: , <24B20D14B2CD29478C8D5D6E9CBB29F60F6CAA88@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:05:42 -0000 On a related note: At some point we could also try a virtual (remote-only) interim meeting. I realize that there is value in having a critical mass of people in one room interacting directly. However, in cases where there is not a co-located event that is likely to draw a critical mass of people, perhaps a virtual interim makes sense. Note: I have been involved in other working groups that have successfully pulled off virtual interims (so there are worked examples of this happening successfully). Also, most of the problems in San Diego were in trying to combine a large number of physical participants with a large number of remote participants, so it is possible that a completely virtual interim would run into fewer potential stumbling blocks. Just my 2 cents, - Matt Lepinski On 3/27/2012 5:52 PM, Samuel Weiler wrote: > On Tue, 27 Mar 2012, Murphy, Sandra wrote: > >> Moderate badness in the Monday meeting was due to my laptop >> communication problems. Suggestions welcome as how to handle such a >> situation better. > > Thank you for asking. > > 1) First and foremost, delegate the tech issues to two or more persons > who do not have responsibilities to chair, present, scribe, or jabber > scribe. Ideally, find people who are unlikely to be active > participants in the meeting. It's fine to bring in outside help. > > 2) Have spares for all key hardware. This includes laptops, audio > gear, network gear, network connections, and phone connections. Cables > and power supplies need spares, also -- a dead power supply can mean a > dead laptop. Based on experience in San Diego I suggest having at > least three pieces of all key gear. Have fallbacks in case a service > provider fails: if you're planning to use Meetecho, ALSO have a WebEx > session and a PSTN bridge set up and ready to go. > > 3) Test both primary and spare hardware and service providers in > multiple combinations prior to the meeting. The more testing you do, > the more you can get away with only a single spare. Testing needs to > happen in the real meeting environment using the same phone lines, net > connections, and audio hardware that will be available during the > meeting. The more removed your testing environment is from the real > meeting environment, the more you need that second spare. > > 4) When a relatively large number of participants will be in a single > space, provide high-quality microphones. The average Polycom > microphone still sounds like a speakerphone, and listening to people > talking through one all day gives remote participants a clearly > second-class experience. If possible, give every participant his own > microphone (with mute switch!). At the very least, provide a floor or > wireless handheld microphone as we have at the regular IETF meetings > and make sure people use it. > > > Yes, this is a lot to do. Yes, I'm saying to have three net > connections[1]. Remember, you're not doing this yourself (at least, > not if you're following suggestion #1). In fact, no one person is > stuck with all of this. And "spares" don't have to be > sitting-in-a-box-and-hauled-around-the-world-the-to-be-a-spare: they > can be a meeting participant's personal power brick, so long as you're > sure there's going to be that spare in the room and the person is > willing to part with it should the need arise. > > -- Sam > > > [1] This is based on the San Diego experience where the hotel net > connection was terrible and the backup net was a 4G hotspot. While > both could move some packets, they were not enough to handle both > remote participation and the normal packet-pushing desires of those in > the room. A 3G or 4G device could easily be the backup net, so long > as 1) there is actually service in the meeting space and 2) the device > gives priority to the remote participation traffic and avoids getting > bogged down by routine email checking and web browsing. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From mlepinski@bbn.com Tue Mar 27 15:20:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A389121E8085 for ; Tue, 27 Mar 2012 15:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39n47m8S1eyy for ; Tue, 27 Mar 2012 15:20:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2283621E8011 for ; Tue, 27 Mar 2012 15:20:30 -0700 (PDT) Received: from [128.89.255.2] (port=49717) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCekS-000Ads-G8 for sidr@ietf.org; Tue, 27 Mar 2012 18:20:16 -0400 Message-ID: <4F723D2A.6080007@bbn.com> Date: Tue, 27 Mar 2012 18:20:26 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:20:31 -0000 Terry, On 3/27/2012 4:22 PM, Terry Manderson wrote: > I feel like the Monday meeting was a bit of a lost opportunity. I appreciate > that the presenters made effort in presenting, and making slides and > presenting ideas. However I feel like the "RPKI over Bittorrent" really > needed focused discussion on what the problem is, and a resulting definition > of what RPKI needs in a requirements spec to address the problems that were > alluded (and BTW I am more than happy to help form that set of > requirements). > I see your point here. However, I am personally very grateful to Rob for his BitTorrent experiment. I believe that the choke point of the global RIR repositories is a vital challenge in RPKI deployment. I think the working group would benefit from spending significant bandwidth thinking about this challenge and I see Rob's presentation as a very reasonable way to get the ball rolling. That is, this particular topic has been completely dormant on the mailing list in the past months. Therefore, doing any kind of concrete experiment and presenting it to the working group as a possible approach for getting around the global-repository choke-point seems like a valuable way to spur work/discussion on this topic. - Matt Lepinski From jakob.heitz@ericsson.com Tue Mar 27 16:22:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0AD21F8510; Tue, 27 Mar 2012 16:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zm8RwEPcjw2; Tue, 27 Mar 2012 16:22:15 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 12ED921F8503; Tue, 27 Mar 2012 16:22:12 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2RNMBnw032726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Mar 2012 18:22:11 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 27 Mar 2012 19:22:11 -0400 From: Jakob Heitz To: "robert@raszuk.net" , Tony Li Date: Tue, 27 Mar 2012 19:22:09 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0MXEbFY14+6gYCQQ+FbKUYTl2BlAAD8zSg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> In-Reply-To: <4F7229A0.1070109@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 23:22:16 -0000 SIDR wise, to aggregate routes, you would have to aggregate signatures. That means to put both signatures into the aggregate and sign across the pair of them at each subsequent hop. yuck. Alternatively, send both routes and let the end user decide to use them in a multipath. Can you say ebgp add-path? -- Jakob Heitz. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Tuesday, March 27, 2012 1:57 PM To: Tony Li Cc: idr@ietf.org List Subject: Re: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Hi Tony, >> * Propose an alternative encoding to address this case specifically >> for multipath use cases, but till this is deployed continue use >> AS_SET > > Another option might be to simply concatenate AS_PATHs. Yes, this > would lose policy information and mis-represent AS topology to > management stations and the like, but it would not create any risk of > looping and would not require us to reinstitute AS_SET. Very true. However I am not sure how that would be effectively that much=20 different SIDR wise from issue with AS_SET ;) Said this are there any other issues with AS_SET then SIDR ? R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From terry.manderson@icann.org Tue Mar 27 23:22:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E3921F86F3 for ; Tue, 27 Mar 2012 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNvoui4Z7sxN for ; Tue, 27 Mar 2012 23:22:33 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1514821F86DD for ; Tue, 27 Mar 2012 23:22:33 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 27 Mar 2012 23:22:31 -0700 From: Terry Manderson To: Matt Lepinski , "sidr@ietf.org" Date: Tue, 27 Mar 2012 23:22:30 -0700 Thread-Topic: RPKI Repo concerns WAS Re: [sidr] Interim Meeting Dates/Locations (Proposed) Thread-Index: Ac0MZ+COw2NxfUU7Q1iC63zkT2zavAAQ0ajH Message-ID: In-Reply-To: <4F723D2A.6080007@bbn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415796550_10091091" MIME-Version: 1.0 Subject: [sidr] RPKI Repo concerns WAS Re: Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:22:33 -0000 --B_3415796550_10091091 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Matt, On 28/03/12 8:20 AM, "Matt Lepinski" wrote: > > I see your point here. However, I am personally very grateful to Rob for > his BitTorrent experiment. I believe that the choke point of the global > RIR repositories is a vital challenge in RPKI deployment. Excellent - so we have a defined, and succinct problem statement. "The choke point of the global RIR repositories is a vital challenge in RPKI deployment." > I think the > working group would benefit from spending significant bandwidth thinking > about this challenge and I see Rob's presentation as a very reasonable > way to get the ball rolling. It's a thought process. And I don't mind seeing the idea thrown "out there" with a speculative solution. My comments were in parallel with the time / form / agenda of the proposed interim meetings, and the idea that some (many?) will be churning additional resources from their own companies to participate and in that participate remotely with all the obvious foibles that brings. > > That is, this particular topic has been completely dormant on the Sorry, has this been previously raised on the ML? I couldn't find anything in a quick scan of the archives. Do you have a pointer? > mailing list in the past months. Therefore, doing any kind of concrete > experiment and presenting it to the working group as a possible approach > for getting around the global-repository choke-point seems like a > valuable way to spur work/discussion on this topic. > I appreciate experimentation as a valuable precursor to discussion, but more than anything I would love to see some requirements fleshed out in working group form first. Cheers Terry --B_3415796550_10091091 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUVipuBYVpdX+BS2xuZlelou8u1EkwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMzI4MDYyMjMwWjANBgkqhkiG 9w0BAQEFAASCAQCCFtgvCLKrmq1keNfrModDwjm5mkiWrrhuC2hVShC69Rac+YqD+kFs+SeB 9+syOaTP3i/ke6XD7dl+Vci9txFP6BTCYK9cGmhNoa98OAwi6n7wPIZnGRh86R3Q4MTuga2f z0ZYfGW82xGDKUiSjj2WPO74mnwyyiuCTLH5GiZkKsAmFr7BsHmH9Ot1RFsusQ2QVh+QhICZ 8OFAa4roU6Nrkdd5ZBGXyEl5mepMO6EXr0ZZ/QhLlnDAGXIDVNcO7a3D+gs/aKzFU40/Gsca kDj76MfK/hsQ5DW7TGRnsar0FBghpzZ0s9s2grlmT6GvaL1sNYn8WrC/IANwJKAr8id8 --B_3415796550_10091091-- From mlepinski@bbn.com Tue Mar 27 23:59:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9EF21E8154 for ; Tue, 27 Mar 2012 23:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNTXdfvcD6w1 for ; Tue, 27 Mar 2012 23:59:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C214221E80F2 for ; Tue, 27 Mar 2012 23:59:39 -0700 (PDT) Received: from [128.89.254.239] (port=49281) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCmqr-000F03-GO; Wed, 28 Mar 2012 02:59:25 -0400 Message-ID: <4F72B6D8.3070900@bbn.com> Date: Wed, 28 Mar 2012 02:59:36 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] RPKI Repo concerns WAS Re: Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:59:40 -0000 Terry, On 3/28/2012 2:22 AM, Terry Manderson wrote: >> That is, this particular topic has been completely dormant on the > Sorry, has this been previously raised on the ML? I couldn't find anything > in a quick scan of the archives. Do you have a pointer? > My apologies. When I wrote my message, I had thought that this came up on the list briefly during spring of 2011 during the (first?) WGLC of the repository-structure document. However, at the moment, I can't find the message reference at the moment, so it is quite possible that I am mis-remembering. - Matt Lepinski From christopher.morrow@gmail.com Wed Mar 28 00:17:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585DB21F84E7 for ; Wed, 28 Mar 2012 00:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2emuxH-pTgp6 for ; Wed, 28 Mar 2012 00:17:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82C0121F84DF for ; Wed, 28 Mar 2012 00:17:34 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1103696obb.31 for ; Wed, 28 Mar 2012 00:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HkPBdxAXFB5/9C/zVEP1gF8BCKaCYkS8wxhkCj3VEfY=; b=vbmkCDEDapZwkWwVHagcr3kXTJflMxlIY99pdqTRmy47L9lY/vFUh8EYbBv4rh9Fce 0VLuo228jy9Onm+9m6blHLFwLm/q7g2dvP5OvYULhOO2A2iROVJXCH9Kz2bG6a683uF1 hqbZyAlQA7gh93hsmFICr13g7ZfPhdy4oBw/v+WtHgMizmew/YS/tJ3vcxj0n6NHazNb 83GVyVuAb57pebXINhBWwpA43kDukdtm6aAKZUkq18tMiLSXfoRYcRRfKA/K8ItEOefl IMO4ilBaiQDF7M/I6+oPbDZ8dw3hmdhNeQXGeIHBxkw81oq2kmh/tzl/AfnU6OwiMQva a6uA== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr35860737oei.71.1332919053989; Wed, 28 Mar 2012 00:17:33 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 00:17:33 -0700 (PDT) Date: Wed, 28 Mar 2012 03:17:33 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] webex for today's meeting (INPROGRESS NOW) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:17:35 -0000 details for the webex: Topic: IETF83 SIDR wg meeting Date and Time: Wednesday, March 28, 2012 9:00 am, Europe Summer Time (Paris, GMT+02:00) Event number: 646 631 463 Event password: wgmeeting Event address for attendees: https://ietf.webex.com/ietf/onstage/g.php?d=646631463&t=a -chris From jhaas@slice.pfrc.org Wed Mar 28 00:35:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6DF21F876A for ; Wed, 28 Mar 2012 00:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4PBz2b6snsg for ; Wed, 28 Mar 2012 00:35:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0152F21F863D for ; Wed, 28 Mar 2012 00:35:11 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8095A170410; Wed, 28 Mar 2012 03:35:11 -0400 (EDT) Date: Wed, 28 Mar 2012 03:35:11 -0400 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20120328073511.GA17790@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [sidr] Proposed -03 signature block format, reserved field X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:35:12 -0000 Per mic comment: The slides propose a 8 octet "reserved field". Instead, consider making it a container for TLVs. Length field of 2 octets. Consider immediately specifying TLVs in it: 1 (or 2?) octet code point, 2 octet lengths. Immediately request a registry for this reserved section with first come-first served/experimental code points. One example would be to embed secured community values. Note that this would be distinct from flagging that we'd want to note that we should sign the community path attribute. The problem with signing the community attribute is that there is a strong expectation in that path attribute that it may be modified on a hop-by-hop basis. -- Jeff From christopher.morrow@gmail.com Wed Mar 28 01:05:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CC821F88DA for ; Wed, 28 Mar 2012 01:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uugsh7miRn+a for ; Wed, 28 Mar 2012 01:05:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3064D21F8961 for ; Wed, 28 Mar 2012 01:05:06 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1168221obb.31 for ; Wed, 28 Mar 2012 01:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nxnsZYUrE91lAncI+L8vPfxXZJka0UR7iv4K3xWmYqM=; b=cYI4SK9CQPOYBQKcu5iXgbAuviEDJoLfRzhuO6/aOkgLpADAiuiBpSBxq6ER1ocM86 xboVm3YQ7wg7nuG5lYObSKtqyZqr82w8WPjGav5TpJy3KyYOqbBtgWEjvkP3Gb6zSYig 2LUEgXGZRRzTMDJHExlZdE5Sn7zgdBG7HOScuhXOiGqDfHcfnMsASertiYWDut120SHQ tEPY7VLhOossc69ppIAXnQvIy0YB6vmTkDGcq6D/6cUp+iPt9PA6bnkYFIx9B+tQgO7j MLKQnyIAXGOyh3GhzGJovk4EVrmR8Nl2lNGMNHrVGJAmk37rVk099Wxs9itX2Eyo8HxA ozlg== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr35992467obb.61.1332921905716; Wed, 28 Mar 2012 01:05:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 01:05:05 -0700 (PDT) In-Reply-To: <4F723D2A.6080007@bbn.com> References: <4F723D2A.6080007@bbn.com> Date: Wed, 28 Mar 2012 04:05:05 -0400 X-Google-Sender-Auth: GJLVPgYIOGFNh74kYgwbzgx3Rz8 Message-ID: From: Christopher Morrow To: Matt Lepinski Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:05:07 -0000 On Tue, Mar 27, 2012 at 6:20 PM, Matt Lepinski wrote: > Terry, > > > On 3/27/2012 4:22 PM, Terry Manderson wrote: >> >> I feel like the Monday meeting was a bit of a lost opportunity. I >> appreciate see previous gzip compression message :( I think we tried to stuff 8hrs of content into ~2hrs. I think we ought to revisit the content at the next opportunity, which is probably ~4/30/2012-ish. >> that the presenters made effort in presenting, and making slides and >> presenting ideas. However I feel like the "RPKI over Bittorrent" really >> needed focused discussion on what the problem is, and a resulting >> definition >> of what RPKI needs in a requirements spec to address the problems that >> were >> alluded (and BTW I am more than happy to help form that set of >> requirements). >> > > I see your point here. However, I am personally very grateful to Rob for his > BitTorrent experiment. I believe that the choke point of the global RIR i'd like to see a conversation about how this method worked/s and what impacts other transport mechanisms may have on the distribution of the data we care about. I think there's room for alternates, the bittorrent experiment seems to show that... so do comments at the mic by martin levy and others. > repositories is a vital challenge in RPKI deployment. I think the working > group would benefit from spending significant bandwidth thinking about this > challenge and I see Rob's presentation as a very reasonable way to get the > ball rolling. sure. probably also writing down the 'what are we trying to solve' with this distribution system would be good to document (terry's call for requirements). -chris From terry.manderson@icann.org Wed Mar 28 01:09:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1421F88FF for ; Wed, 28 Mar 2012 01:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxPzINB3XFSB for ; Wed, 28 Mar 2012 01:09:40 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 67DCC21F88EC for ; Wed, 28 Mar 2012 01:09:40 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Mar 2012 01:09:39 -0700 From: Terry Manderson To: Christopher Morrow , Matt Lepinski Date: Wed, 28 Mar 2012 01:09:37 -0700 Thread-Topic: [sidr] Interim Meeting Dates/Locations (Proposed) Thread-Index: Ac0MuY0THaQG0S+lTFaBWKCc35KkCgAAJDkx Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415802977_10464898" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:09:41 -0000 --B_3415802977_10464898 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 28/03/12 6:05 PM, "Christopher Morrow" wrote: > > sure. probably also writing down the 'what are we trying to solve' > with this distribution system would be good to document (terry's call > for requirements). > Happy to start documenting such if people want to throw their _requirements_ at me. naturally I have my own. But I am but one lens of the issue. Cheers Terry --B_3415802977_10464898 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUZloXDtgSjQAolmmKRgGcv2Dxrp8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMzI4MDgwOTM3WjANBgkqhkiG 9w0BAQEFAASCAQA3R6ityofs5t+dfvG1NYFbzI2K7qiSZ0xIMRW14US6zUHdOm+daO0qf6BI O+iLyBDwgkHVl2tKo6+K/KF9PM3cATXAmDWZJl8SY62zoqQzyw0Pjae6S3t9TL463Hi+VaUY 5dd0WwiZHtGIvfLxG7ccKFFMr9YdmgisWMXgjULgkeM+ziaOQNrQUUXohcWuiK9TbCcZQ5f8 Qi/Q3ex4ih/aRCccWxDhm03qo5ZYg+mwlsg6EJnKbrtp+iDDxyzj7k5IUbhqMnUPcCRv+pkc ji45eZBTHwi6V9UXahpHTAb8iY3sE/QN6DQND6fTrxShBne2LefvobLGBZl1Y0euLUfi --B_3415802977_10464898-- From aservin@lacnic.net Wed Mar 28 01:13:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B69621F88F5 for ; Wed, 28 Mar 2012 01:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH9svPDya5xz for ; Wed, 28 Mar 2012 01:13:00 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7021F87C4 for ; Wed, 28 Mar 2012 01:12:57 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id E2BEF308424; Wed, 28 Mar 2012 05:12:48 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Wed, 28 Mar 2012 10:12:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67DB773C-ED27-4281-BE61-558D19A1CF32@lacnic.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:13:00 -0000 We operate a repository and we are using the others repositories = for our origin-validation tool. So, I would be happy to help documenting = our experience and some ideas to improve. Regards, as On 28 Mar 2012, at 10:09, Terry Manderson wrote: >=20 > On 28/03/12 6:05 PM, "Christopher Morrow" = wrote: >=20 >>=20 >> sure. probably also writing down the 'what are we trying to solve' >> with this distribution system would be good to document (terry's call >> for requirements). >>=20 >=20 > Happy to start documenting such if people want to throw their = _requirements_ > at me. naturally I have my own. But I am but one lens of the issue. >=20 > Cheers > Terry > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 01:15:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8421F8975; Wed, 28 Mar 2012 01:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XylZpo2h2i1k; Wed, 28 Mar 2012 01:15:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E953D21F8973; Wed, 28 Mar 2012 01:15:18 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1182088obb.31 for ; Wed, 28 Mar 2012 01:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TRKvps7olmW3IeltjjP2BAzj4aSCktz5u+FHe256g8g=; b=TpkKFLO/OrVeksGVnvyUVaA8k6sA6FQjnz/243IZsjktWCo5d1a2E/3Mlp9Wxw8PK6 aw18IR7kpvyP74h++/kPP7WpHuee6F7hcPguAVzKFcp+Wv3SLWEyhtDrcfAobpS1/ZpK i1bjFnK03POiAgzLrPW6r0kjoc/EgLCh1t8qXgdx3ivgoHRpX5w70gf3Hly1bUragakz YCaNVddw3lOymaN6iLHbi8KbZRNjL0ugCxcpxQ9odXz3pQ2iKBFSHJLQQc97AROI87gE O3UmrwzG65nFoy4wkPg8Hp486jeGchC7RWAbLLkrbLrV61Jz8XEuRyXWih6aFyNA7+Ap zgaQ== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr36594442obb.71.1332922518482; Wed, 28 Mar 2012 01:15:18 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 01:15:18 -0700 (PDT) In-Reply-To: References: <3AE49CA5-A647-41B2-9E10-D2CDAA399AE1@ripe.net> Date: Wed, 28 Mar 2012 04:15:18 -0400 Message-ID: From: Christopher Morrow To: Tim Bruijnzeels Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:15:23 -0000 On Tue, Mar 27, 2012 at 5:08 AM, Christopher Morrow wrote: > On Tue, Mar 27, 2012 at 4:45 AM, Tim Bruijnzeels wrote: > >> As I stated before I prefer to have the extra time during, or next to, a= n IETF -- I already planned to attend those. So the extra meeting in Vancou= ver works for me. I understand that a higher frequency is good for momentum= but extra travel is not possible for me and remote attendance is not ideal= . >> > > summarizing a constant thrum.... > "Yes, not everyone can make every interim proposed. Yes not everyone > can make the virtual version of same. That is ok..." being slightly less flip (I didn't actually mean to be flip): The 2 questions here are: 1) are more meetings required/helpful 2) would having these coincident with existing events and ~1/month be acceptable to the majority we (everyone involved) do know that not everyone can make every meeting... aiming for best participation level is the goal. -chris > Thanks for the info though! > -chris > From jhaas@slice.pfrc.org Wed Mar 28 01:19:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8163A21F88EB for ; Wed, 28 Mar 2012 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms+AZAGsXNOp for ; Wed, 28 Mar 2012 01:19:40 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D991621F88E6 for ; Wed, 28 Mar 2012 01:19:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8C9241703C8; Wed, 28 Mar 2012 04:19:39 -0400 (EDT) Date: Wed, 28 Mar 2012 04:19:39 -0400 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20120328081939.GA19843@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:19:40 -0000 Per my mic comment at IETF 83: During the San Diego interim session we had discussed potentially signaling in BGP the idea that a given AS may have fresher data available in its repository. My original thought had been something along the lines of a new AFI/SAFI that contains this data. Matt L., in discussing this point at the mic with me, suggested something that has resemblence to the serial number field in DNS. For example, this field could go into the "reserved" field that a route originator puts into the signature. If the serial number increases, this could suggest that fresher information is present in that originator's repository. Discussion around this mechanism: - If this is part of a given route's signature block, the issue is that a given origin may be seen with a number of serial numbers depending on propagation of BGP routes. - Such a serial number is important not only for the originator of a route, but also all parties participating in the signature. This particular details suggests to me that such signaling probably should be separate from the signatures. - By being part of the signature, we get some level of freshness in things in a route-by-route basis and less likely that a completely separate "route" that is repository freshness is dropped. -- Jeff From terry.manderson@icann.org Wed Mar 28 01:30:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8DB21F8899 for ; Wed, 28 Mar 2012 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ovyLudoQ54v for ; Wed, 28 Mar 2012 01:30:09 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 355A821F8890 for ; Wed, 28 Mar 2012 01:30:06 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Mar 2012 01:30:05 -0700 From: Terry Manderson To: Jeffrey Haas , "sidr@ietf.org" Date: Wed, 28 Mar 2012 01:30:03 -0700 Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP Thread-Index: Ac0Mu5MAdvpX0+KIQjuOtxoyEGbdHQAAWW6c Message-ID: In-Reply-To: <20120328081939.GA19843@slice> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3415804203_10487216" MIME-Version: 1.0 Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:30:16 -0000 --B_3415804203_10487216 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Jeff, On 28/03/12 6:19 PM, "Jeffrey Haas" wrote: > Per my mic comment at IETF 83: > During the San Diego interim session we had discussed potentially signaling > in BGP the idea that a given AS may have fresher data available in its > repository. > > My original thought had been something along the lines of a new AFI/SAFI > that contains this data. Matt L., in discussing this point at the mic with > me, suggested something that has resemblence to the serial number field in > DNS. For example, this field could go into the "reserved" field that a > route originator puts into the signature. If the serial number increases, > this could suggest that fresher information is present in that originator's > repository. I think this is interesting. I think I would further like an assessment/disussion of this "serial number" being consistent between the BGP information, the RPKI repository, and this through the validated cache and presented to the router via rpki-rtr. It may well present far too many error situations by doing that, but may also provide a brilliant statement of a consistent view matching origination intent in a time and space perspective. 0.02c > > Discussion around this mechanism: > - If this is part of a given route's signature block, the issue is that a > given origin may be seen with a number of serial numbers depending on > propagation of BGP routes. > - Such a serial number is important not only for the originator of a route, > but also all parties participating in the signature. > This particular details suggests to me that such signaling probably should > be separate from the signatures. > - By being part of the signature, we get some level of freshness in things > in a route-by-route basis and less likely that a completely separate > "route" that is repository freshness is dropped. > --B_3415804203_10487216 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU0jvoMEtNSMXZckEdmi8vZ+GUXhswGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMzI4MDgzMDAzWjANBgkqhkiG 9w0BAQEFAASCAQAEEB7r1LfmZK9I5kUL++0ESkK8+DF0NW70jwYFESpEE6tZub+scCQJLGBw NH4zYMlwVQyeco8WICFXCEHTU7quHwWfutbuVI4BWbANfRjpAOUV+9fiWdaBg22xSHHCV7/J q0wqDSO9x1q9dJvKLE/kf6NCjpXwJ35CvBsqottXry71o7NKiFaov8vl08cVlcp0x6aCYtwY MG8aX+1ofDwdrJu2UrQOTxE3rdkxB3ogEeg+YYIagfxumOtFfELGzXVcws5+96UX7/ZwCwM8 AnnGmkDJcZwbB0vrhRY8dydiPD8rss1Oi0MpOflKHkW1wOtmEgu4T0/iKAMcFHBG8ah+ --B_3415804203_10487216-- From dougm.tlist@gmail.com Wed Mar 28 01:54:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DECE21F8959 for ; Wed, 28 Mar 2012 01:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB4nOSfB1lFO for ; Wed, 28 Mar 2012 01:54:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C29AD21F88C6 for ; Wed, 28 Mar 2012 01:54:19 -0700 (PDT) Received: by bkuw5 with SMTP id w5so730105bku.31 for ; Wed, 28 Mar 2012 01:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a49S4zZ8/U1A3hir/t8c9Gi2Um5OKQn5XsUUbys6UYM=; b=QCOCxwZ262AeNCAbg2c9mbjVjZ/Lmgzd2+uyxLrfiVFUmYqrCek3ff0qeGvr11Q0xx p+PrCRhIqzY8gXG8luIrR4OC5LHM3jobQftJ2SxUlfPrOJZBkqEyhC3L98zqfm+HMkPp ixononAA/yujysrWRH9A/W6W+QhAEeGi047EpyJGphRkpDQcDQgVkhvhAOMV63lun2Sa iOHdQYpakqIMbKdtCaa+RYQN0W4F/ods8wu8T6FrWAUHzTwK37fRiVcC2S4epT3spf06 DARduFxXfVXHCi+ZvLcUsh+oMw6FmlO6vhdHLzLaH7F61vr+PsIp/2e6MzypJ6p1h9qA gOiA== Received: by 10.205.135.132 with SMTP id ig4mr11765130bkc.20.1332924854234; Wed, 28 Mar 2012 01:54:14 -0700 (PDT) Received: from [130.129.87.191] (dhcp-57bf.meeting.ietf.org. [130.129.87.191]) by mx.google.com with ESMTPS id r14sm4806003bkv.11.2012.03.28.01.54.12 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 01:54:13 -0700 (PDT) Message-ID: <4F72D1B3.3010603@gmail.com> Date: Wed, 28 Mar 2012 04:54:11 -0400 From: DougM lists User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20120328081939.GA19843@slice> In-Reply-To: <20120328081939.GA19843@slice> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Freshness belt and suspenders .... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:54:21 -0000 I thought John Scudder's belt and suspenders comment was a good one. We have looked at some level of detail at both explicit expire times in updates and key roll techniques to manage freshness of BGP updates. Neither approach is a silver bullet and both have the potential to swamp the system with either updates or updates and RPKI data. Ideas discussed to date of bounding the potential load imposed by either single mechanism are imperfect. Without bounds, either mechanism could be abused at the expense of the entire net. Sandy has called previously for a discussion of the general requirements for "the freshness/replay problem". Assuming we don't want to leave the problem half solved (e.g., deal with withdraw suppression as well as explicit replay and peering topology changes), the idea of combining mechanisms seems to offer an opportunity. Combining John and Randy's comments during the discussion ..... Assume we bound the units of expire time to days (for example, choose your acceptable background granularity) past epoc. Assume we express bounds that components MUST support at least two pre-published keys per router/AS. Emergency or topology driven key roll at the router, works at speed of BGP convergence. Day based expire times catch those freshness problems that can't be addressed by router key roll. Some bounds are necessary to prevent / discourage me from pre-publishing vast number of router keys signed with very short lived certificates ..... i.e., I can churn the system just as bad with frequent key rolls on routers. Anyway, combining the two mechanisms would give us a reactive system (router key roll) along with a background system that covers the rest of the threat space. I think that was John's point. dougm From jhaas@slice.pfrc.org Wed Mar 28 01:57:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397F21F899B for ; Wed, 28 Mar 2012 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bumkkzPC7uIi for ; Wed, 28 Mar 2012 01:57:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7111E21F8946 for ; Wed, 28 Mar 2012 01:57:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 35077170414; Wed, 28 Mar 2012 04:57:03 -0400 (EDT) Date: Wed, 28 Mar 2012 04:57:03 -0400 From: Jeffrey Haas To: Terry Manderson Message-ID: <20120328085703.GA21657@slice> References: <20120328081939.GA19843@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:57:04 -0000 On Wed, Mar 28, 2012 at 01:30:03AM -0700, Terry Manderson wrote: > I think this is interesting. I think I would further like an > assessment/disussion of this "serial number" being consistent between the > BGP information, the RPKI repository, and this through the validated cache > and presented to the router via rpki-rtr. Would it be sufficient to put have the latest manifestNumber (from RFC 6486) be distributed as a single "route" signed using the normal BGPSEC procedures? With my usual apologies, I'm less clear on whether it's likely there will be more than one manifest on a per AS basis. -- Jeff From weiler@watson.org Wed Mar 28 02:05:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9409D21F89C8 for ; Wed, 28 Mar 2012 02:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc1-MVdrALeI for ; Wed, 28 Mar 2012 02:05:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id D8A8421F89C2 for ; Wed, 28 Mar 2012 02:05:44 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q2S95hpY030498 for ; Wed, 28 Mar 2012 05:05:43 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q2S95hJ5030494 for ; Wed, 28 Mar 2012 05:05:43 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 28 Mar 2012 05:05:43 -0400 (EDT) From: Samuel Weiler To: "sidr@ietf.org" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C0E99@Hermes.columbia.ads.sparta.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 28 Mar 2012 05:05:43 -0400 (EDT) Subject: Re: [sidr] wg adoption call for draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:05:45 -0000 Have read and support adoption. I like the general idea. I don't have comments on the particular wrappings chosen. Minor comments: It might be better to not specify the cryptosuite(s) in use -- aren't those documented in draft-ietf-sidr-bgpsec-algs? (ECDSA is named in sections 1 and 4.) The current security considerations section seems applicable only to the operator-generated model. You might want to say something about the other model. And for the operator-generated model, you may want to add a (flip) comment about transport security being "keep your hand on the USB key". This almost looks like a use for Resurrecting Duckling keying methods. -- Sam From tim@ripe.net Wed Mar 28 02:09:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2272B21F8983 for ; Wed, 28 Mar 2012 02:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so26clTDQB-b for ; Wed, 28 Mar 2012 02:09:52 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B04CD21F896E for ; Wed, 28 Mar 2012 02:09:51 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SCot1-0006oa-W8; Wed, 28 Mar 2012 11:09:49 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SCot1-0000Rx-OQ; Wed, 28 Mar 2012 11:09:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-283785468 From: Tim Bruijnzeels In-Reply-To: <67DB773C-ED27-4281-BE61-558D19A1CF32@lacnic.net> Date: Wed, 28 Mar 2012 11:09:47 +0200 Message-Id: <8EB45C66-5DCF-406F-AD02-381782892CB0@ripe.net> References: <67DB773C-ED27-4281-BE61-558D19A1CF32@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) 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] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d2c9176025dd4ee51f67e8b085d0aa34 Cc: "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:09:53 -0000 --Apple-Mail-2-283785468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi.. The validator implementers have also discussed some of the common = problems that we see now, and other ways to distribute the rpki data = over the past days. We have some more thoughts on this, but I am not = sure that we agree yet. I would like to talk between us a tiny bit more = to avoid mistakes that would make it impossible, and sending an idea to = this list that is shot down immediately and wasting everyone's time ;) Tim On 28 Mar 2012, at 10:12, Arturo Servin wrote: >=20 > We operate a repository and we are using the others repositories = for our origin-validation tool. So, I would be happy to help documenting = our experience and some ideas to improve. >=20 > Regards, > as >=20 > On 28 Mar 2012, at 10:09, Terry Manderson wrote: >=20 >>=20 >> On 28/03/12 6:05 PM, "Christopher Morrow" = wrote: >>=20 >>>=20 >>> sure. probably also writing down the 'what are we trying to solve' >>> with this distribution system would be good to document (terry's = call >>> for requirements). >>>=20 >>=20 >> Happy to start documenting such if people want to throw their = _requirements_ >> at me. naturally I have my own. But I am but one lens of the issue. >>=20 >> Cheers >> Terry >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr Tim Bruijnzeels Senior Software Engineer RIPE NCC e: tim@ripe.net p: +31 20 5354309 --Apple-Mail-2-283785468 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

    We operate a repository and we = are using the others repositories for our origin-validation tool. So, I = would be happy to help documenting our experience and some ideas to = improve.

    Regards,
    as

    On 28 Mar 2012, at 10:09, Terry = Manderson wrote:


    On 28/03/12 = 6:05 PM, "Christopher Morrow" <morrowc.lists@gmail.com> = wrote:


    sure. probably also writing down = the 'what are we trying to = solve'
    with this distribution system would be good to document = (terry's call
    for = requirements).


    Happy to start = documenting such if people want to throw their = _requirements_
    at me. = naturally I have my own. But I am but one lens of the = issue.

    Cheers
    Terry
    _______________________________________________
    sidr mailing = list
    sidr@ietf.org
    https://www.ietf.org/m= ailman/listinfo/sidr

    _____________________________= __________________
    sidr mailing list
    sidr@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/sidr

    Tim = Bruijnzeels
    Senior Software Engineer
    RIPE NCC

    e: tim@ripe.net
    p: +31 20 = 5354309

    = --Apple-Mail-2-283785468-- From christopher.morrow@gmail.com Wed Mar 28 05:23:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A121F8846; Wed, 28 Mar 2012 05:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vg27JEnQIxe; Wed, 28 Mar 2012 05:23:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9A821F883A; Wed, 28 Mar 2012 05:23:21 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1509750obb.31 for ; Wed, 28 Mar 2012 05:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7hismlIfR0gM9bdZE94pI+FdR2nUYeg7BqiXFmTIui8=; b=WissBjJ9xH9uZi2pRCBCOvg8Jan/fGRmFQhomqcoYfGlToGcHa/g9IvBjz72Mumd9x 8jjaPESibvzOY77FCma40+WJQuUOzOeuumRMNd9AIHlti8g3e/s1J8LF3XZm03UWeSnJ j94RPtMO/R40kg6uPQto5c+s1nRKpnQfiDGQQfdmFQIKxO84LLNkKArD0l19054g9SKY TreRitjDs2Bm6Sww8GBiHBIrbCf0zm07dJ2X4AlkwEL+HYq6zj0nrVCJONwGCK1EvMWg tDvQdPn3M39LNqbjuLByMR1eiFyakNp2bgj5L2V8WxMEnm96VN8RzW0fi/iVrul0qV0X Dx5Q== MIME-Version: 1.0 Received: by 10.60.9.38 with SMTP id w6mr36596279oea.41.1332937399794; Wed, 28 Mar 2012 05:23:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:23:19 -0700 (PDT) In-Reply-To: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> References: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:23:19 -0400 X-Google-Sender-Auth: ghtELu_m1sQ5crGu68ipcm0pSmI Message-ID: From: Christopher Morrow To: sidr-chairs@ietf.org, sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:23:22 -0000 Sean, This document seems settled, should we WGLC this in the near future? -chris On Mon, Dec 5, 2011 at 1:21 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Secure Inter-Domain Routing Working= Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : BGP Algorithms, Key Formats, &= Signature Formats > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Sean Turner > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-algs-01.t= xt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-05 > > =A0 This document specifies the algorithms, algorithms' parameters, > =A0 asymmetric key formats, asymmetric key size and signature format used > =A0 in BGPSEC (Border Gateway Protocol Security). =A0This document update= s > =A0 the Profile for Algorithms and Key Sizes for use in the Resource > =A0 Public Key Infrastructure (draft-ietf-sidr-rpki-algs). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-01.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 05:25:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE121E8196; Wed, 28 Mar 2012 05:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQDvGL9vRHpY; Wed, 28 Mar 2012 05:25:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 116B421E80B2; Wed, 28 Mar 2012 05:25:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1512299obb.31 for ; Wed, 28 Mar 2012 05:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nrFrqI+EtmS02mEglNav1dLk9vjvaW4VHWPaMV+seK0=; b=EHxhocWTwQCtRWHbrmUzcl7oMZGVwd8mv4lB2ac5o51a4xxZJ04RwxutMtKvdY/BOt YkkiHvJ8yxx7LanSGJwMXybv54tDB2ngHF49ssjcpp6iqNwQJmK3WYHTV9XsrL/l36MY XrcQ/HKYekgTmgBF0Swxv0Cs/rHe1jwwSaiSopJmPRUZdU1e25jrmnhP4P0FE5BhIEPK kKuujHQk4Fe5qSnxkvCMoYaA0oInVdoNwY/D4JtWLluQBBrGqijfgUJahOd7IKwlAviZ ZW4rcjEDjtkfCQ8rhjWtjrGQlUn7QMfC8uqJPMSlzz0REjI/bczH/WW9nFSXuo/vOxKu hK3A== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr37123172obb.61.1332937522361; Wed, 28 Mar 2012 05:25:22 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:25:22 -0700 (PDT) Date: Wed, 28 Mar 2012 08:25:22 -0400 Message-ID: From: Christopher Morrow To: Randy Bush , sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:25:25 -0000 Randy, Is this document prepared/ready/willing for WGLC in the near future? I believe there were some outstanding document comments still to be handled by your edit-buffer? -Chris From christopher.morrow@gmail.com Wed Mar 28 05:26:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8407821E8196; Wed, 28 Mar 2012 05:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFQunxdi4fqg; Wed, 28 Mar 2012 05:26:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7921E812E; Wed, 28 Mar 2012 05:26:54 -0700 (PDT) Received: by yhkk25 with SMTP id k25so668062yhk.31 for ; Wed, 28 Mar 2012 05:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BwJM6pD2etBiJk8Yl8sc9HE3EnEESNtRUG471aHYsIo=; b=dtI08LGtHyesap/qheJ/ggDUT/u30LBhzewZEnvkel4ZL7qmlokeCmWindPezMqgFq 0t/M12/9NrzAjxjI11U6M7uoj+zXuWnEGBuxteGiMyJyxJwuy7bHPom2vdQxQTiQsgT1 n0X5kAgLW0cfiAGUYVUJ0Laebv23USuVMAmwt5oIg4A5VlQ1fGHhH0/czJDKw1NsKrRP qycxqKKd1FcVAMxXaprYQtghHHwrgmQhM8UpGe0gXFtnkpxhFsIJwNeTpHfH+3Dh6umh CYk5Lpc0n8oCikAUccW7vxekwwkNtmpOiNoFY5i5fjL060KIhwxefbnjIgmWlg7vwkKX PWUA== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr37181881oei.71.1332937614414; Wed, 28 Mar 2012 05:26:54 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:26:54 -0700 (PDT) Date: Wed, 28 Mar 2012 08:26:54 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] activity!! ACHTUNG! X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:26:55 -0000 howdy WG folk: yes, some emails are coming out (now), perhaps I'll double-count/mis-count on a document, please speak up if you think that is the case :) The purpose here is to get status updated on docs and move things along if they are in the right place for said movement. thanks! -chris From christopher.morrow@gmail.com Wed Mar 28 05:29:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C192C21E81B9; Wed, 28 Mar 2012 05:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XAynb9+TKiM; Wed, 28 Mar 2012 05:29:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3D221E8182; Wed, 28 Mar 2012 05:29:32 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1517292obb.31 for ; Wed, 28 Mar 2012 05:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BZwY52dBvHMVDHBGzVGqKOM5lfgtQaKkH9Uwk5YeUnE=; b=SecCPGYnQcXjX+6lq2BlawuM+nqG9mhcL9bMjqKi0fohT7VvpGGDAx9WVd1r7vL7S/ 0sK1Yu+Oy4lYE7bYHUHS02lSQLWG/y9rQ+pAP/bqP9sA/SPJEp/A9wy3OiqVpdidGhGs hNxxYwoQf7mKiJwe1vo8mNDd/6u1Z7CoJvxZOr0Kxmqwrq8WpzTHV6ys7kbS2nJ5j4g6 5qdKvpMSKkj4bW0icn+bIKcIo3r+iXYXC/HsqlSbr2RxqSGMUSrOaWsWVv4n0x/esQiJ P3lBv1O2T0hJFQePQTUotx1Rr9mnlNh1zgj4c0dW1nV8lHMjlg1SBKu73cGZLMHE+4uu tsZw== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr37195192oei.71.1332937771739; Wed, 28 Mar 2012 05:29:31 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:29:31 -0700 (PDT) In-Reply-To: <20111031180236.14850.43978.idtracker@ietfa.amsl.com> References: <20111031180236.14850.43978.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:29:31 -0400 X-Google-Sender-Auth: nemQKwzJjB9UP_dJRSsh0yC-E48 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:29:32 -0000 Matt/Sean, This document hasn't changed in a while, Wes (copied) had some comments which I believe were addressed in the October/2011 update? Is this document ready to move forward? Wes, did you review the changes sent? -Chris On Mon, Oct 31, 2011 at 2:02 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Secure Inter-Domain Routing Working= Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Overview of BGPSEC > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Matt Lepinski > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sean Turner > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-overview-= 01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31 > > =A0 This document provides an overview of a security extension to the > =A0 Border Gateway Protocol (BGP) referred to as BGPSEC. =A0BGPSEC improv= es > =A0 security for BGP routing. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.tx= t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 05:33:09 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0092A21E81A9; Wed, 28 Mar 2012 05:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6dfEfl7uzNE; Wed, 28 Mar 2012 05:33:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3276021E81C7; Wed, 28 Mar 2012 05:33:08 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1521964obb.31 for ; Wed, 28 Mar 2012 05:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sHwfGlGhjGlYQ7sr4V1S+0+Fw7mvnWTdV2ICwcry9s4=; b=Hgvf1qy6fiKivet0THkIj8G9nqJ+H3OW1vKbWJqZwkjI9X1y9h23XM5g+tgXgVbKi3 6+19d7+FVLdMEKvBv65XsX7BourvEeZepkG/joDII7NrvVZEwexe4aGML9g73bsGCnFd OsxZFwohKLEPluakrkGF/edzadUB7C5zq4lFPHQhu007Ba5c08hUMlYNXuoFKZouXGd6 zXUi3tyK8bTJrnfadHsGUth3p+uN9c0va6YyHXQjwsZj+vZdzCQfqtV2aMajbpNg5KRZ nERi3n3cTW0zEDDGXo2h3c308Amskc3W/vfxT2VEqeSdQ3yBqJG+pGbKRiJ8Bth2/hjg RdnQ== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr37135835obz.51.1332937987858; Wed, 28 Mar 2012 05:33:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:33:07 -0700 (PDT) In-Reply-To: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:33:07 -0400 X-Google-Sender-Auth: haXRAqsZC14_ASOVLLHzdLB7W10 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Sean Turner , "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:33:09 -0000 Sean/Tom, Tom had some comments on the previous (I believe) version of this draft, are they addressed to your satisfaction Tom? Sean, if Tom's ok with the changes, should we move this along? -Chris On Mon, Dec 5, 2011 at 1:20 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Secure Inter-Domain Routing Working= Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Profile for BGPSEC Router Ce= rtificates, Certificate Revocation Lists, and Certification Requests > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mark Reynolds > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sean Turner > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Steve Kent > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-pki-profi= les-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-05 > > =A0 This document defines a standard profile for X.509 certificates for > =A0 the purposes of supporting validation of Autonomous System (AS) paths > =A0 in the Border Gateway Protocol (BGP), as part of an extension to that > =A0 protocol known as BGPSEC. =A0BGP is a critical component for the prop= er > =A0 operation of the Internet as a whole. =A0The BGPSEC protocol is under > =A0 development as a component to address the requirement to provide > =A0 security for the BGP protocol. =A0The goal of BGPSEC is to design a > =A0 protocol for full AS path validation based on the use of strong > =A0 cryptographic primitives. =A0The end-entity (EE) certificates specifi= ed > =A0 by this profile are issued under Resource Public Key Infrastructure > =A0 (RPKI) Certification Authority (CA) certificates, containing the AS > =A0 Identifier Delegation extension, to routers within the Autonomous > =A0 System (AS). =A0The certificate asserts that the router(s) holding th= e > =A0 private key are authorized to send out secure route advertisements on > =A0 behalf of the specified AS. =A0This document also profiles the > =A0 Certificate Revocation List (CRL), profiles the format of > =A0 certification requests, and specifies Relying Party certificate path > =A0 validation procedures. =A0The document extends the RPKI; therefore, > =A0 this documents updates the RPKI Resource Certificates Profile (draft- > =A0 ietf-sidr-res-cert-profile). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-0= 1.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01= .txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 05:47:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2648C21E81E6; Wed, 28 Mar 2012 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc-tbjli4UVr; Wed, 28 Mar 2012 05:47:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 566A021E81F4; Wed, 28 Mar 2012 05:47:35 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1540501obb.31 for ; Wed, 28 Mar 2012 05:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kp1vjiu4c4LWxOYeMMfFWpmRoehzAXByL1TFsn43hn4=; b=vdqyLth+YeWdOVWuOD6TJMWdKYDTRKYHsqk3UusD1fHZhFflnTQr0Tk7/T4QgNbOc9 koi93DyFsuubA9J+BPdQmduEAk0ycJSm8uENWKqPXdakmERtMvs56hIyaIBlUy8Iax0r nVWB+TPvli6hgiP0tCAplH7L4lF4fUvb6Sho+xb3r/Yey3NzlWwcOLcgOKv9n4aBDwFz 0V76iW1zILC+dSzmo2X48gjGFLTj1dNEbGQXn5tfz7NLGgf82+Ky8XAxzq025SM472U7 WDsEREVO9i8z3MmZ6/tbfZ6R/p8g2HWg1XW75iR51WhfznTSIMocxUKoSAcuBeTlslr8 ZN3Q== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr37205277obz.51.1332938854996; Wed, 28 Mar 2012 05:47:34 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:47:34 -0700 (PDT) In-Reply-To: <20111204203254.1087.96249.idtracker@ietfa.amsl.com> References: <20111204203254.1087.96249.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:47:34 -0400 X-Google-Sender-Auth: wVGQyGlTdiO6JNH37dvMC0HpYds Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:47:36 -0000 Hello authors, What is your intent with this document? moving along the process? delaying on other references? holiday-for-document in sweden? Inquiring minds would like to be informed! :) Thanks! -Chris On Sun, Dec 4, 2011 at 3:32 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Secure Inter-Domain Routing Working= Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Local Trust Anchor Management = for the Resource Public Key Infrastructure > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mark Reynolds > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stephen Kent > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-ltamgmt-04.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 28 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-12-04 > > =A0 This document describes a facility to enable a relying party (RP) to > =A0 manage trust anchors (TAs) in the context of the Resource Public Key > =A0 Infrastructure (RPKI). It is common to allow an RP to import TA > =A0 material in the form of self-signed certificates. The facility > =A0 described in this document allows an RP to impose constraints on such > =A0 TAs. Because this mechanism is designed to operate in the RPKI > =A0 context, the relevant constraints are the RFC 3779 extensions that > =A0 bind address spaces and/or autonomous system (AS) numbers to > =A0 entities. The primary motivation for this facility is to enable an RP > =A0 to ensure that resource allocation information that it has acquired > =A0 via some trusted channel is not overridden by the information > =A0 acquired from the RPKI repository system or by the putative TAs that > =A0 the RP imports. Specifically, the mechanism allows an RP to specify a > =A0 set of bindings between public key identifiers and RFC 3779 extension > =A0 data and will override any conflicting bindings expressed via the > =A0 putative TAs and the certificates downloaded from the RPKI repository > =A0 system. Although this mechanism is designed for local use by an RP, > =A0 an entity that is accorded administrative control over a set of RPs > =A0 may use this mechanism to convey its view of the RPKI to a set of RPs > =A0 within its jurisdiction. The means by which this latter use case is > =A0 effected is outside the scope of this document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-04.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 05:53:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE421E8210 for ; Wed, 28 Mar 2012 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6ZuPlYE-Knu for ; Wed, 28 Mar 2012 05:53:17 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA321E81DE for ; Wed, 28 Mar 2012 05:53:17 -0700 (PDT) Received: by ggmi1 with SMTP id i1so706345ggm.31 for ; Wed, 28 Mar 2012 05:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FgJIYV4x/2t3xRPOM7/aSvYNahOBWhOD+fDEGmUR9lc=; b=rqTfWVwvGlzz2GqqIsJzieVaGO//RmXB6rh5Rb6onUnlQpiDMZThf24RExaLwpYWKS PClI7SISPDdY0jZoD9XJJZNF598SWwYNcJDNa08rnIg2cuX9kHPsOFl4K3z6AAgPWtXO nAuBr2QeVGknA6gnR/XQkXDZZ7H9bHnGP5gR2syKXVKx+tu7i3lKUrbZ/nqzjDT6bXGv 7COb0DjFMiTrESK8fClNeXLLUDsAsXSHWdvIEyBcvBFHwAD4DNQJqGj4rpTrFi+AydLB nhQpSY4TF0BTgn2NzhqMICIVIOuqjHirn3K3AmI+Ys15c0nZ8mywtafI2DxhTd8zgaNh kphw== MIME-Version: 1.0 Received: by 10.60.9.38 with SMTP id w6mr36742323oea.41.1332939196941; Wed, 28 Mar 2012 05:53:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:53:16 -0700 (PDT) In-Reply-To: <45A556D4-F367-4193-A418-7993AF42A0EC@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> <20111114133704.72C05654865@minas-ithil.hactrn.net> <45A556D4-F367-4193-A418-7993AF42A0EC@tcb.net> Date: Wed, 28 Mar 2012 08:53:16 -0400 X-Google-Sender-Auth: 2IH8e_UZ8OWxGZ8UqLEp8L_wbgY Message-ID: From: Christopher Morrow To: Danny McPherson , Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:53:18 -0000 Reviving a zombie thread... So, Where does this set of comments end us? Are the updates put in between 11/11 and 03/12 taking care of the discussion? or are there still things to wrangle? I think, given the length and breadth of discussion here we'd all do to re-read and re-WGLC this doc once things are settled. -chris On Mon, Nov 14, 2011 at 5:57 PM, Danny McPherson wrote: > > On Nov 14, 2011, at 8:37 AM, Rob Austein wrote: > >> Ultimately, the problem is the same as distributing DNSSEC TAs, or any >> other TA for that matter. =A0Pretty much by definition, these things >> have to be configured outside the automated system, because they're >> the bootstrap data. =A0Inclusion in distributions of software using the >> system seems to be the most common way, but one could envision other >> methods (T shirts handed out at IETF or *OG meetings, publication in >> major newspapers, perhaps as QR codes, invent your own mechanism -- >> the key point is that grounds for believing the TAL come from outside >> the system we're trying to bootstrap). > > However, in the interim (until we have a single RPKI root), the origin-op= s > draft should provide some guidance about how an RP should have the > capability to verify "look-aside" (ugh) what resources an "INR" holds, an= d > recommend that they only accept associated RPKI data for those > resources. =A0The onus cannot be on the RP to resolve this themselves at > on a global scale. > > The model where each of the TAs in the TAL can assert what it is they're > authoritative for is even mode broken than the browser/SSL/CA issues > that we're trying to fix with DANE (the attacker at least has to be on-pa= th > there, before they consult a compromised CA). > > Furthermore, pending the outcome of the discussion in the other thread > I started related to this topic and local TAs, the origin-ops draft shoul= d also > include some discussion about multiple parties involved in LTA-esque > functions (or extra TALs with "constraints") to preserve inter-domain > connectivity during putative RPKI override/bypass functions for source, > destination, and intermediate networks. > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Mar 28 05:57:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8926A21E81DE; Wed, 28 Mar 2012 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aid9FeWNVCe7; Wed, 28 Mar 2012 05:57:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF95821E81BB; Wed, 28 Mar 2012 05:57:19 -0700 (PDT) Received: by yenm5 with SMTP id m5so696812yen.31 for ; Wed, 28 Mar 2012 05:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1rIW+fPvfwTjCmz3sP67v1h2LVeGOwPGJgT8q9A3X48=; b=zbTrzcOGCFbB1pr2ILIVrRJ5/SqIsK8vHmYJVwfGo7Z80G02tI+FUP+THzhc+FaMzn YyNYeRmFFwlvhCU/yNyvv9tHw3y94Qvau5+wehoAYvdwfhMfbOOjLVTGlfoxTy9o7JaB 8MgZ++/aIWtCvoVFU8xaz2BlqjqDAC5I5nDo3rrJrmPvd7Vx3Uz7sESKW0ZkoMyiTOfY G3H7d2SFxJxxpSLFC4R5QbbpTi5nF8M8F/VVgcvTTXxR6qFhAkpnfwH7izDSw6REPcYV Glzh5+4t25SH5nkAStWid/oLzY6EHr8FpCeF+hoSankPMJgjLs4PLnXxyh6YPuvBC7vD Lw1g== MIME-Version: 1.0 Received: by 10.60.24.164 with SMTP id v4mr33880354oef.51.1332939439318; Wed, 28 Mar 2012 05:57:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 05:57:19 -0700 (PDT) In-Reply-To: <20120312205331.1904.65803.idtracker@ietfa.amsl.com> References: <20120312205331.1904.65803.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:57:19 -0400 X-Google-Sender-Auth: KZHew0lgxCMP02oSf1q2E3XSL5A Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Samuel Weiler , Rob Austein , anuja.sonalker@sparta.com Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:57:20 -0000 Draft Author Ship Steerers, This we didn't chat about at the meeting(s), but are there outstanding bits/pieces or should this be sent along for WGLC in the near future? -Chris On Mon, Mar 12, 2012 at 4:53 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Secure Inter-Domain Routing Working= Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Publication Protocol for the= Resource Public Key Infrastructure (RPKI) > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Samuel Weiler > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anuja Sonalker > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rob Austein > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-publication-02.t= xt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 This document defines a protocol for publishing Resource Public Key > =A0 Infrastructure (RPKI) objects. =A0Even though the RPKI will have many > =A0 participants issuing certificates and creating other objects, it is > =A0 operationally useful to consolidate the publication of those objects. > =A0 This document provides the protocol for doing so. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-publication-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-publication-02.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Wed Mar 28 05:59:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813921E81F5; Wed, 28 Mar 2012 05:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBldq-I32iT6; Wed, 28 Mar 2012 05:59:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D68A521E81DE; Wed, 28 Mar 2012 05:59:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41844 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCsTN-000Ihp-D4; Wed, 28 Mar 2012 08:59:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20111204203254.1087.96249.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 08:56:49 -0400 To: Christopher Morrow From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:59:49 -0000 At 8:47 AM -0400 3/28/12, Christopher Morrow wrote: >Hello authors, >What is your intent with this document? moving along the process? >delaying on other references? holiday-for-document in sweden? > >Inquiring minds would like to be informed! :) > >Thanks! >-Chris > I think another rev is needed before this doc is fully-baked. I will talk with Mark about what I think we need to change, and he'll create a new version. Steve From paul@jakma.org Wed Mar 28 06:10:09 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8AA21E8216 for ; Wed, 28 Mar 2012 06:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hRWWrWDMPEU for ; Wed, 28 Mar 2012 06:10:08 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 58EA321E8237 for ; Wed, 28 Mar 2012 06:10:08 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so5634493wib.1 for ; Wed, 28 Mar 2012 06:10:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=CIQJqQqh2vZe8zPV5/LnlescW8NrZxrZkxc2Dut2JCI=; b=Y2G5JrgZuK06w2RFKTlw+ava7EyfpomJaK0RFl9PHz2jigCk4DVNZrdHg29rgty45P xGEJvjEybUDuyjRXKskTb8w/Sg9fGnRwtd2htgHo8HSunSeZWXi3yyCDJHWG+fuvGLNM 8bngXEI9ogWJrR7dCqHP99JGaJpEHLd9wrRd9TZnWl22/jSs0gpG/zz2IhrJfZIeLyo9 Mok/h5KqgUFZyMddylSDrLNz46GSk68HDNanUpm2PXX2nPCcVmKsd7WAw+/KrZljizYp S1ZykPrvqdKEddt1DRLudl7/AHL7/ItlgIgH1gI4wDOvujIIS6nu4mI90QytMcYVrtD5 Vu4w== Received: by 10.216.52.14 with SMTP id d14mr16665409wec.35.1332940207273; Wed, 28 Mar 2012 06:10:07 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id k6sm57874255wiy.7.2012.03.28.06.10.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 06:10:05 -0700 (PDT) Date: Wed, 28 Mar 2012 14:10:04 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQmgFUcLf2JdniAvFUnIkx8TfE4D4ReiXYcTtLbJ5rTSuEYjP6JTUuVRO1IQ94I8OVqeSm5A Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:10:09 -0000 On Tue, 27 Mar 2012, Jakob Heitz wrote: > Alternatively, send both routes and let the end user decide to use them > in a multipath. Can you say ebgp add-path? Where's the document to describe how to do multi-pathing using add-path? E.g. what should happen when there is a non-add-path capable neighbour? regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner From randy@psg.com Wed Mar 28 06:30:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1269021F895D for ; Wed, 28 Mar 2012 06:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHtU5tNBMs43 for ; Wed, 28 Mar 2012 06:29:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 93ABF21F8946 for ; Wed, 28 Mar 2012 06:29:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCswn-000K0J-G8; Wed, 28 Mar 2012 13:29:58 +0000 Date: Wed, 28 Mar 2012 15:29:56 +0200 Message-ID: From: Randy Bush To: Christopher Morrow 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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:30:00 -0000 > Is this document prepared/ready/willing for WGLC in the near future? imiho, no > I believe there were some outstanding document comments still to be > handled by your edit-buffer? it is matt's edit buffer which gives me pause randy From christopher.morrow@gmail.com Wed Mar 28 06:34:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80921E809D for ; Wed, 28 Mar 2012 06:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYsM8+ornpFy for ; Wed, 28 Mar 2012 06:34:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 854C821E808C for ; Wed, 28 Mar 2012 06:34:42 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1598908obb.31 for ; Wed, 28 Mar 2012 06:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kwKmWv8v7ZoKD8qnYHa3EydZWkHPXWV/sOmeYqQlHh0=; b=qoFS9k7r3uh7xAXPOx8Qu6sMl3wk2YzKT0oj5fCJI8OVYuSR8dEiU+FGmMUUlZ3Fen 1yCuCvmqT9No7PI4uLZqtc1rL7DX3/Kpfg+KWIiTAdMUlzMc9J/7U5h9G4I+y61RHDzF bs+yZEdMnzX9IlNK+ZpMbx4eRffuqVyxhxWoFl7QYj3JhscOiHRO9BdaSR/cu5bAgEr/ du3ujp58CQAFmZrnbbhOYRP8AAoq896Qc8oe8D4r2J3AsI3/wAVikLb58AuyevLlX7ns 1HOwyPY2fa61QBws5pgDnGY2Lkr8nEUkuqBS9toSoUc+hT0oVTCLyxjSuHeWAc0XzRCj DbvA== MIME-Version: 1.0 Received: by 10.60.9.38 with SMTP id w6mr36942828oea.41.1332941682167; Wed, 28 Mar 2012 06:34:42 -0700 (PDT) Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 06:34:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 09:34:42 -0400 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:34:43 -0000 On Wed, Mar 28, 2012 at 9:29 AM, Randy Bush wrote: >> Is this document prepared/ready/willing for WGLC in the near future? > > imiho, no > >> I believe there were some outstanding document comments still to be >> handled by your edit-buffer? > > it is matt's edit buffer which gives me pause terrific! Matt can probably update once he's made progress? :) -Chris From wesley.george@twcable.com Wed Mar 28 06:34:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D112121E8151; Wed, 28 Mar 2012 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl329BjLwaNW; Wed, 28 Mar 2012 06:34:53 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0321E814E; Wed, 28 Mar 2012 06:34:52 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,661,1325480400"; d="scan'208";a="343721047" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Mar 2012 09:33:42 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 28 Mar 2012 09:34:28 -0400 From: "George, Wes" To: Christopher Morrow , Randy Bush , "sidr@ietf.org" , "sidr-chairs@ietf.org" Date: Wed, 28 Mar 2012 09:34:26 -0400 Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? Thread-Index: Ac0M3eDrAxl2NttmRLKUABsNQmhZ1wACWfUA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:34:54 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Wednesday, March 28, 2012 8:25 AM > To: Randy Bush; sidr@ietf.org; sidr-chairs@ietf.org > Subject: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? > > Is this document prepared/ready/willing for WGLC in the near future? [WEG] There are far too many things in flux within BGPSec design for this c= ompanion doc to be anywhere near ready. As things coalesce, there are undou= btedly going to be updates to this draft. Origin ops, sure, but not BGPsec-ops. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Sandra.Murphy@sparta.com Wed Mar 28 06:42:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897DE21E819B for ; Wed, 28 Mar 2012 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxjwemTjQMfz for ; Wed, 28 Mar 2012 06:42:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 051E021E8196 for ; Wed, 28 Mar 2012 06:42:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SDg4Fj025471 for ; Wed, 28 Mar 2012 08:42:05 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SDg4OB010802 for ; Wed, 28 Mar 2012 08:42:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 09:42:04 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: remote participation experience today Thread-Index: Ac0M5//f0srobMRMSzy2GLfZeuNaQQ== Date: Wed, 28 Mar 2012 13:42:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] remote participation experience today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:42:06 -0000 The webex session on Monday failed completely, due to laptop wireless incap= ability to maintain a connection (20-50-80-100% packet loss).=0A= =0A= The webex session on Wednesday (this morning) seemed to work (alternate net= working arranged).=0A= =0A= But being the presentation laptop for webex, I was unable to see who (if an= y) the participants were.=0A= =0A= If you joined the webex session today, PLEASE do comment on the list of wha= t you found worked or did not work for that experience. (Was your view of = slides keeping up? were you listenting to webex telecon or to ietf audio s= tream? could you follow the discussion amongst those in the room? audio q= uality? etc.)=0A= =0A= It would help in figuring out the future virtual meetings.=0A= =0A= --Sandy= From turners@ieca.com Wed Mar 28 06:44:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7A421F88A8 for ; Wed, 28 Mar 2012 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIxjWbWdEdUh for ; Wed, 28 Mar 2012 06:44:09 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.22.93]) by ietfa.amsl.com (Postfix) with ESMTP id EE25621F889A for ; Wed, 28 Mar 2012 06:44:08 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 1F01B1F0E25C9; Wed, 28 Mar 2012 08:44:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 147121F0E2597 for ; Wed, 28 Mar 2012 08:44:08 -0500 (CDT) Received: from [198.180.150.230] (port=58433 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SCtAV-0005H0-4I; Wed, 28 Mar 2012 08:44:07 -0500 Message-ID: <4F7315A4.5010507@ieca.com> Date: Wed, 28 Mar 2012 15:44:04 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (dhcp-2594.meeting.ietf.org) [198.180.150.230]:58433 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:44:13 -0000 Chris, I think this draft should probably go in a cluster. There are normative references to draft-sidr-bgpsec-pki-profiles and draft-ietf-sidr-bgpsec-protocol. However, you could WGLC this draft because unless you're planning on changing the alg (ECDSA) there's really no dependencies on the other drafts. In other words, if you change bgpsec or the cert profile to add/remove fields them really doesn't affect this draft. It could then just wait on the protocol to go forward in a sensible cluster. There's two tweaks I'd do before a WGLC and barring any other changes: 1. s3: r/The RSA key pairs/The key pairs I'd do this because RSA might not be the alg used in the RPKI later. It's helping to future proof this draft. 2. s11.1: Update references to [ID.sidr-res-cert-profile] and [ID.sidr-rpki-algs] to the appropriate RFC #s. Why don't I go ahead and post a new version to fix these two points and then you & Sandy can decide whether to start the WGLC button. spt On 3/28/12 2:23 PM, Christopher Morrow wrote: > Sean, > This document seems settled, should we WGLC this in the near future? > > -chris > > > On Mon, Dec 5, 2011 at 1:21 PM, wrote: >> >> 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 : BGP Algorithms, Key Formats,& Signature Formats >> Author(s) : Sean Turner >> Filename : draft-ietf-sidr-bgpsec-algs-01.txt >> Pages : 7 >> Date : 2011-12-05 >> >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format used >> in BGPSEC (Border Gateway Protocol Security). This document updates >> the Profile for Algorithms and Key Sizes for use in the Resource >> Public Key Infrastructure (draft-ietf-sidr-rpki-algs). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-01.txt >> >> _______________________________________________ >> 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 > From wesley.george@twcable.com Wed Mar 28 06:48:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D770C21E8188; Wed, 28 Mar 2012 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-MFOsWkzc-Y; Wed, 28 Mar 2012 06:48:26 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4821E8165; Wed, 28 Mar 2012 06:48:25 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,661,1325480400"; d="scan'208";a="360150333" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Mar 2012 09:47:26 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 28 Mar 2012 09:48:24 -0400 From: "George, Wes" To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" Date: Wed, 28 Mar 2012 09:48:22 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt Thread-Index: Ac0M3nqPcWCp/XaUQ/20KlB4tTjuDQACT7cg Message-ID: References: <20111031180236.14850.43978.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:48:27 -0000 I'll re-review, but I think that this is similar to origin-ops, where until= the protocol design is stable, it's not really ready. We have a similar gr= oup of docs that block each other as we did with the big chunk for origin v= alidation. Thanks, Wes > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] = On > Behalf Of Christopher Morrow > Sent: Wednesday, March 28, 2012 8:30 AM > To: sidr@ietf.org; sidr-chairs@ietf.org > Cc: Matt Lepinski; Sean Turner; George, Wes > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt > > Matt/Sean, > This document hasn't changed in a while, Wes (copied) had some > comments which I believe were addressed in the October/2011 update? Is > this document ready to move forward? Wes, did you review the changes > sent? > > -Chris > > > On Mon, Oct 31, 2011 at 2:02 PM, wrote: > > 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 : An Overview of BGPSEC > > Author(s) : Matt Lepinski > > Sean Turner > > Filename : draft-ietf-sidr-bgpsec-overview-01.txt > > Pages : 10 > > Date : 2011-10-31 > > > > This document provides an overview of a security extension to the > > Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves > > security for BGP routing. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.= txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.t= xt > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Wed Mar 28 06:52:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9993B21F8698; Wed, 28 Mar 2012 06:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeBeQ1gARwTc; Wed, 28 Mar 2012 06:52:07 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id E073521E81C2; Wed, 28 Mar 2012 06:52:05 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,661,1325480400"; d="scan'208";a="343733763" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Mar 2012 09:51:19 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 28 Mar 2012 09:52:05 -0400 From: "George, Wes" To: Christopher Morrow Date: Wed, 28 Mar 2012 09:52:04 -0400 Thread-Topic: [sidr] Interim Meeting Dates/Locations (Proposed) Thread-Index: Ac0Muv1tUNKkOM5SQqGee9stVy/HNQALW81g Message-ID: References: <3AE49CA5-A647-41B2-9E10-D2CDAA399AE1@ripe.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:52:07 -0000 > 2) would having these coincident with existing events and ~1/month > be acceptable to the majority > > we (everyone involved) do know that not everyone can make every > meeting... aiming for best participation level is the goal. > > -chris > [WEG] Avoiding some number of messages saying "can't/can attend x, y, z" is= exactly why I requested that the chairs use a doodle poll or similar to ga= ther that feedback (a bit more quietly), especially when there is more than= one alternative for a date (before vs after an event, for example). You're= asking for feedback, which is good, but you've still pre-set the dates, wh= ich really isn't aiming for best participation level. It's simply giving pe= ople an opportunity to throw rocks, and hope that enough people throw rocks= of the same shape to change the schedule as necessary. For example, although it means I have to give up more weekend for travel, I= 'd rather see us go on the front side of NANOG. I am unlikely to be able to= do anything not World V6 launch related on June 6, and I'd bet I'm not the= only one. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From shane@castlepoint.net Wed Mar 28 06:56:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786A321F898B for ; Wed, 28 Mar 2012 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tmr-oSw9Nt5z for ; Wed, 28 Mar 2012 06:56:45 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id A5A5621F8967 for ; Wed, 28 Mar 2012 06:56:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0AA01268063; Wed, 28 Mar 2012 07:56:45 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Mar 2012 07:56:44 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=50011; data-bytes=0 From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2012 15:56:41 +0200 Message-Id: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:56:46 -0000 To expand on my comments at the mic earlier today on this draft, I think = there is universal acknowledgment that there should be statements that = attacks involving path shortening should be acknowledged as a "threat" = in this document. OTOH, with respect to path-lengthening, my comment was NOT aimed at the = normal, operation practice of AS_PATH prepending for the purposes of = Traffic Engineering. My concern is one that is related to the purported Kapela/Pilosov = "threat". Specifically, think of the following scenario: a) Someone is forging an AS4_PATH towards another (remote) party, to = stimulate then to drop the UPDATE. b) An implementation is checking the AS4_PATH attribute to see if they = find their ASN in there. If they find their own ASN, they consider this = UPDATE as being looped and, per BGP protocol, should drop it. c) I can see a scenario where, similar to GTSM, implementers might have = a [strong] preference to verify the AS4_PATH does not have any loops = /first/, before doing any crypto verification on BGPSEC_Path_Signatures, = since crypto verification is "[much] more expensive". d) Further, what if an attacker did this to valid, BGPSEC-signed paths = that he/she was originating and/or receiving and propagating downstream = toward other ASN's? The larger point here is that documenting, preferably in this I-D, the = Kapela/Pilsov threat and other threats related to upgrade/downgrade = threats discussed at the Prague IETF allows us to more holistically = consider whether, or not, BGPSEC addresses it. -shane= From mlepinski@bbn.com Wed Mar 28 07:03:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0007121F8A55; Wed, 28 Mar 2012 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb6IDph1wFfE; Wed, 28 Mar 2012 07:03:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2121F8A54; Wed, 28 Mar 2012 07:03:13 -0700 (PDT) Received: from [128.89.255.28] (port=49289) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCtSk-000KZs-U0; Wed, 28 Mar 2012 10:02:59 -0400 Message-ID: <4F731A1D.50707@bbn.com> Date: Wed, 28 Mar 2012 10:03:09 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <20111031180236.14850.43978.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:03:15 -0000 Wes, Please do not re-review until the -02 version. This document needs to be updated based on some changes to other docs in the BGPSEC document suite. - Matt Lepinski On 3/28/2012 8:29 AM, Christopher Morrow wrote: > Matt/Sean, > This document hasn't changed in a while, Wes (copied) had some > comments which I believe were addressed in the October/2011 update? Is > this document ready to move forward? Wes, did you review the changes > sent? > > -Chris > > > On Mon, Oct 31, 2011 at 2:02 PM, wrote: >> 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 : An Overview of BGPSEC >> Author(s) : Matt Lepinski >> Sean Turner >> Filename : draft-ietf-sidr-bgpsec-overview-01.txt >> Pages : 10 >> Date : 2011-10-31 >> >> This document provides an overview of a security extension to the >> Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves >> security for BGP routing. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-01.txt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From jakob.heitz@ericsson.com Wed Mar 28 07:11:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D721E8266; Wed, 28 Mar 2012 07:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAWtHhoLaIo8; Wed, 28 Mar 2012 07:11:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7C21E8262; Wed, 28 Mar 2012 07:11:38 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2SEBMgv026611; Wed, 28 Mar 2012 09:11:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 28 Mar 2012 10:11:22 -0400 From: Jakob Heitz To: Paul Jakma Date: Wed, 28 Mar 2012 10:11:20 -0400 Thread-Topic: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0M5BoLhVc0G6SbQBC7uJyOppR6xgACFkDQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:11:40 -0000 I don't know. I'm just throwing ideas around. However, it appears that inter AS multipath has a lot of problems. -- Jakob Heitz. -----Original Message----- From: Paul Jakma [mailto:paul@jakma.org]=20 Sent: Wednesday, March 28, 2012 6:10 AM To: Jakob Heitz Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath On Tue, 27 Mar 2012, Jakob Heitz wrote: > Alternatively, send both routes and let the end user decide to use them=20 > in a multipath. Can you say ebgp add-path? Where's the document to describe how to do multi-pathing using add-path?=20 E.g. what should happen when there is a non-add-path capable neighbour? regards, --=20 Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner From robert@raszuk.net Wed Mar 28 07:32:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236A021E8097 for ; Wed, 28 Mar 2012 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnYvqZM31c1B for ; Wed, 28 Mar 2012 07:32:00 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 08EF121F88BF for ; Wed, 28 Mar 2012 07:32:00 -0700 (PDT) Received: (qmail 27352 invoked by uid 399); 28 Mar 2012 14:31:59 -0000 Received: from unknown (HELO ?10.0.1.3?) (robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPAM; 28 Mar 2012 14:31:59 -0000 X-Originating-IP: 79.141.15.165 References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> Mime-Version: 1.0 (iPad Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8L1) From: Robert Raszuk Date: Wed, 28 Mar 2012 16:32:01 +0200 To: Jakob Heitz Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:32:01 -0000 Jakob, The issue is also about intra-as ibgp multipath not inter-as one. Observe th= at data usually flows into opposite direction then routing ;) Cheers, R. On 28 mar 2012, at 16:11, Jakob Heitz wrote: > I don't know. I'm just throwing ideas around. > However, it appears that inter AS multipath > has a lot of problems. >=20 > -- > Jakob Heitz. >=20 > -----Original Message----- > From: Paul Jakma [mailto:paul@jakma.org]=20 > Sent: Wednesday, March 28, 2012 6:10 AM > To: Jakob Heitz > Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >=20 > On Tue, 27 Mar 2012, Jakob Heitz wrote: >=20 >> Alternatively, send both routes and let the end user decide to use them=20= >> in a multipath. Can you say ebgp add-path? >=20 > Where's the document to describe how to do multi-pathing using add-path?=20= > E.g. what should happen when there is a non-add-path capable neighbour? >=20 > regards, > --=20 > Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A > Fortune: > The Second Law of Thermodynamics: > If you think things are in a mess now, just wait! > -- Jim Warner > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Anuja.Sonalker@sparta.com Wed Mar 28 07:42:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3121E812F for ; Wed, 28 Mar 2012 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYJEo+-AkELy for ; Wed, 28 Mar 2012 07:42:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9502B21E8177 for ; Wed, 28 Mar 2012 07:42:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SEgfWf026207 for ; Wed, 28 Mar 2012 09:42:41 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SEgeWk013017 for ; Wed, 28 Mar 2012 09:42:41 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 10:42:40 -0400 From: "Sonalker, Anuja" To: "Murphy, Sandra" , "sidr@ietf.org" Thread-Topic: remote participation experience today Thread-Index: Ac0M5//f0srobMRMSzy2GLfZeuNaQQABeoGg Date: Wed, 28 Mar 2012 14:42:39 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.81.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] remote participation experience today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:44:38 -0000 Hi Sandy, All I attended the Webex session this morning (Wednesday) and attempted the one= on Monday. Here is my experience: - Webex session was quick to launch and start today unlike Monday. - I used the IETF audio stream along with the Webex visual just to get an i= dea of real-time lag. (And as a backup in case Webex failed today.) Audio w= as behind with respect to slides by maybe 10-15 seconds.=20 - The slides kept up very well and in sync with the jabber room logs.=20 - Audience voices were very clear (I know that's not a Webex thing in my ca= se) and discussion around the room was easy to follow. Plus Jabber logs tod= ay were excellent. Together it made for very easy comprehension. Eyes + Ears + Text All information streams together worked great to give a= great experience. - My location: Columbia, Maryland, USA (~ Washington DC.) --Anuja -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Mur= phy, Sandra Sent: Wednesday, March 28, 2012 9:42 AM To: sidr@ietf.org Subject: [sidr] remote participation experience today The webex session on Monday failed completely, due to laptop wireless incap= ability to maintain a connection (20-50-80-100% packet loss). The webex session on Wednesday (this morning) seemed to work (alternate net= working arranged). But being the presentation laptop for webex, I was unable to see who (if an= y) the participants were. If you joined the webex session today, PLEASE do comment on the list of wha= t you found worked or did not work for that experience. (Was your view of = slides keeping up? were you listenting to webex telecon or to ietf audio s= tream? could you follow the discussion amongst those in the room? audio q= uality? etc.) It would help in figuring out the future virtual meetings. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From turners@ieca.com Wed Mar 28 07:46:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A621E8255 for ; Wed, 28 Mar 2012 07:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhtjWL1obDHc for ; Wed, 28 Mar 2012 07:46:41 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.70.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9391421E812F for ; Wed, 28 Mar 2012 07:46:41 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id B8D231F550BAD; Wed, 28 Mar 2012 09:46:38 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 81E481F550AF2 for ; Wed, 28 Mar 2012 09:46:38 -0500 (CDT) Received: from [198.180.150.230] (port=58533 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SCu8z-0003mJ-Vi; Wed, 28 Mar 2012 09:46:38 -0500 Message-ID: <4F73244C.6020006@ieca.com> Date: Wed, 28 Mar 2012 16:46:36 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (dhcp-2594.meeting.ietf.org) [198.180.150.230]:58533 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:46:42 -0000 I think this draft should probably get out of the WG in a cluster. There is normative references to draft-sidr-bgpsec-algs. However, you could WGLC this draft because unless you're planning on the name format or the alg in draft-ietf-sidr-bgpsec-algs there's nothing really to argue about. It could then just wait on the protocol/alg to go forward in a sensible cluster. There's one tweak I'd do before a WGLC: update references to the published RFC #s. Why don't I post a new version and then you & Sandy can decide whether to start the WGLC button. The only thing remaining would be to get example encodings, but I think that can wait. spt On 3/28/12 2:33 PM, Christopher Morrow wrote: > Sean/Tom, > Tom had some comments on the previous (I believe) version of this > draft, are they addressed to your satisfaction Tom? > > Sean, if Tom's ok with the changes, should we move this along? > > -Chris > > > On Mon, Dec 5, 2011 at 1:20 PM, wrote: >> >> 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 Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests >> Author(s) : Mark Reynolds >> Sean Turner >> Steve Kent >> Filename : draft-ietf-sidr-bgpsec-pki-profiles-01.txt >> Pages : 11 >> Date : 2011-12-05 >> >> This document defines a standard profile for X.509 certificates for >> the purposes of supporting validation of Autonomous System (AS) paths >> in the Border Gateway Protocol (BGP), as part of an extension to that >> protocol known as BGPSEC. BGP is a critical component for the proper >> operation of the Internet as a whole. The BGPSEC protocol is under >> development as a component to address the requirement to provide >> security for the BGP protocol. The goal of BGPSEC is to design a >> protocol for full AS path validation based on the use of strong >> cryptographic primitives. The end-entity (EE) certificates specified >> by this profile are issued under Resource Public Key Infrastructure >> (RPKI) Certification Authority (CA) certificates, containing the AS >> Identifier Delegation extension, to routers within the Autonomous >> System (AS). The certificate asserts that the router(s) holding the >> private key are authorized to send out secure route advertisements on >> behalf of the specified AS. This document also profiles the >> Certificate Revocation List (CRL), profiles the format of >> certification requests, and specifies Relying Party certificate path >> validation procedures. The document extends the RPKI; therefore, >> this documents updates the RPKI Resource Certificates Profile (draft- >> ietf-sidr-res-cert-profile). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Wed Mar 28 07:48:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E0021E825A; Wed, 28 Mar 2012 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBcPHmeiCPOE; Wed, 28 Mar 2012 07:48:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54CD21E812F; Wed, 28 Mar 2012 07:48:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120328144815.21926.65622.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 07:48:15 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:48:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGP Algorithms, Key Formats, & Signature Formats Author(s) : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-02.txt Pages : 7 Date : 2012-03-28 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-02.txt From christopher.morrow@gmail.com Wed Mar 28 07:48:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE821E8267 for ; Wed, 28 Mar 2012 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEOsBFVptSq2 for ; Wed, 28 Mar 2012 07:48:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A33F121E8261 for ; Wed, 28 Mar 2012 07:48:21 -0700 (PDT) Received: by yhkk25 with SMTP id k25so819200yhk.31 for ; Wed, 28 Mar 2012 07:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RGJqK56dgmen0eg1TQEekkrYU+J/veBHP19nX94WfB0=; b=B2dRSihOdtUHN3cQnc4w/1MMLnCS1zwuTxFDNpe4WMGBG6qdax9v6I94fd8XGFXcPv +IdQ0kWEJzHrLa9ojzCV4nOAxmP6nF6MA4TMERM8JVQxQoblBRJH5pcFhnAj+U518Q/V UD5I7TxI79x4UugkS8NG8jsFZCUfSgFEMFrAwFU5oEpYdz7fQb6R12FZAhb9K0CYZ5Ii o2yMxkLAwR1l/o+uJEVDqqJC+pv2Sz/NAa4LjjUP77ZiD5VYxi7mwSwOtJM3qMoC88BP QaG4vmX3ote0HCGib7OSnrCHtS5+GL0trRbWF+QtsJ3tLcP5l33tT3eTn1kz8mYCKy2e jz3g== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr37083913oea.61.1332946101136; Wed, 28 Mar 2012 07:48:21 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 07:48:21 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391B3DE2F950@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 28 Mar 2012 10:48:21 -0400 X-Google-Sender-Auth: Ys_-maCvn_agG8p4asvfJUXo-Y4 Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] sidr drafts link broken X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:48:22 -0000 On Sat, Mar 24, 2012 at 4:34 PM, Jakob Heitz wrote: > https://datatracker.ietf.org/meeting/83/agenda/sidr-drafts.pdf > link on agenda page is broken maybe someone reported this to the HD already, but ... working now! :) (or worked for me at least) -chris From internet-drafts@ietf.org Wed Mar 28 07:48:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94AD21E826F; Wed, 28 Mar 2012 07:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLDdqXFn0yqr; Wed, 28 Mar 2012 07:48:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320B221E8261; Wed, 28 Mar 2012 07:48:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120328144823.21928.22460.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 07:48:23 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:48:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Re= vocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-02.txt Pages : 11 Date : 2012-03-28 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-02.t= xt From jakob.heitz@ericsson.com Wed Mar 28 07:57:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264F621F87C7; Wed, 28 Mar 2012 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cQOkXFeZIxS; Wed, 28 Mar 2012 07:57:04 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 777BA21F87BE; Wed, 28 Mar 2012 07:57:04 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2SEutHX006286; Wed, 28 Mar 2012 09:57:03 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 28 Mar 2012 10:56:54 -0400 From: Jakob Heitz To: Robert Raszuk Date: Wed, 28 Mar 2012 10:56:52 -0400 Thread-Topic: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0M75QQymtUp79iSAiomQKXD5VYPgAAk1/g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:57:05 -0000 The issue is SIDR can not aggregate multiple paths. Solutions I can think of: 1. Aggregate the signatures of the paths being aggregated. 2. Don't aggregate, but send both paths.=20 Should SIDR work on path aggregation? Are there other possibilities? -- Jakob Heitz. -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Wednesday, March 28, 2012 7:32 AM To: Jakob Heitz Cc: Paul Jakma; idr@ietf.org List; Tony Li; sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath Jakob, The issue is also about intra-as ibgp multipath not inter-as one. Observe t= hat data usually flows into opposite direction then routing ;) Cheers, R. On 28 mar 2012, at 16:11, Jakob Heitz wrote: > I don't know. I'm just throwing ideas around. > However, it appears that inter AS multipath > has a lot of problems. >=20 > -- > Jakob Heitz. >=20 > -----Original Message----- > From: Paul Jakma [mailto:paul@jakma.org]=20 > Sent: Wednesday, March 28, 2012 6:10 AM > To: Jakob Heitz > Cc: robert@raszuk.net; Tony Li; idr@ietf.org List; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >=20 > On Tue, 27 Mar 2012, Jakob Heitz wrote: >=20 >> Alternatively, send both routes and let the end user decide to use them= =20 >> in a multipath. Can you say ebgp add-path? >=20 > Where's the document to describe how to do multi-pathing using add-path?= =20 > E.g. what should happen when there is a non-add-path capable neighbour? >=20 > regards, > --=20 > Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A > Fortune: > The Second Law of Thermodynamics: > If you think things are in a mess now, just wait! > -- Jim Warner > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From Anuja.Sonalker@sparta.com Wed Mar 28 08:05:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67C321E8258 for ; Wed, 28 Mar 2012 08:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEXGsE8QLJUX for ; Wed, 28 Mar 2012 08:05:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 17A5221E8255 for ; Wed, 28 Mar 2012 08:05:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SF56KY026539 for ; Wed, 28 Mar 2012 10:05:06 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SF5395013959 for ; Wed, 28 Mar 2012 10:05:03 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 11:05:03 -0400 From: "Sonalker, Anuja" To: "sidr@ietf.org" , "Murphy, Sandra" Thread-Topic: remote participation experience today Thread-Index: Ac0M5//f0srobMRMSzy2GLfZeuNaQQABeoGgAAGHNIA= Date: Wed, 28 Mar 2012 15:05:02 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.81.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] remote participation experience today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:05:07 -0000 Hi Sandy, All I attended the Webex session this morning (Wednesday) and attempted the one= on Monday. Here is my experience: - Webex session was quick to launch and start today unlike Monday. - I used the IETF audio stream along with the Webex visual just to get an i= dea of real-time lag. (And as a backup in case Webex failed today.) Audio w= as behind with respect to slides by maybe 10-15 seconds.=20 - The slides kept up very well and in sync with the jabber room logs.=20 - Audience voices were very clear (I know that's not a Webex thing in my ca= se) and discussion around the room was easy to follow. Plus Jabber logs tod= ay were excellent. Together it made for very easy comprehension. Eyes + Ears + Text All information streams together worked great to give a= great experience. - My location: Columbia, Maryland, USA (~ Washington DC.) --Anuja -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Mur= phy, Sandra Sent: Wednesday, March 28, 2012 9:42 AM To: sidr@ietf.org Subject: [sidr] remote participation experience today The webex session on Monday failed completely, due to laptop wireless incap= ability to maintain a connection (20-50-80-100% packet loss). The webex session on Wednesday (this morning) seemed to work (alternate net= working arranged). But being the presentation laptop for webex, I was unable to see who (if an= y) the participants were. If you joined the webex session today, PLEASE do comment on the list of wha= t you found worked or did not work for that experience. (Was your view of = slides keeping up? were you listenting to webex telecon or to ietf audio s= tream? could you follow the discussion amongst those in the room? audio q= uality? etc.) It would help in figuring out the future virtual meetings. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From paul@jakma.org Wed Mar 28 09:01:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3B121F895D for ; Wed, 28 Mar 2012 09:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1aTbQ3ofjLf for ; Wed, 28 Mar 2012 09:01:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB99821F8934 for ; Wed, 28 Mar 2012 09:01:21 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so771174wgb.13 for ; Wed, 28 Mar 2012 09:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=+0uEIwsMFKU/8VVCBL7rWE6RgIDCxky52XrXsP6gagY=; b=ZKpFOa//LpzSsKNGW1TIyPYZapVrPwmAKXyXLxp9aDU+KA4MT991P5JTgD2G+eqWlt 35d26eaCZdiZimZ3ZFxoscfbW4P6JFnMigzDYa9K85uKnDezj76lVBWwjp7ZNKBRKtfI x0/MBI+S98sIdc10jVTs+FV9laBXIcLhIBR41Xz0d3PUIAuLKhQiPvgOYOLbbEGWoTlb 95QhdZY2A7cqMnOLaDEAi4/3Fad2BRwGQXg8IcGU+R6egn8FP2WdW+tFSfPi8OX7AyUn BkjKoQaRa9tYhbxYvQcaP1+VuCENk3DxUM/vnoR0QlbLyLKAMv9nHJVQVebae2gv1OER eu1Q== Received: by 10.216.137.74 with SMTP id x52mr17906962wei.77.1332950480973; Wed, 28 Mar 2012 09:01:20 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id n8sm14872598wix.10.2012.03.28.09.01.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:01:20 -0700 (PDT) Date: Wed, 28 Mar 2012 17:01:18 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQkFSJNa+0IGvZagShRNFN51GUbhK9yz4CNBr5PncDrlSF9z2nZToD14EgOpLp5fTaeZpm5Y Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:01:23 -0000 On Wed, 28 Mar 2012, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > Should SIDR work on path aggregation? If we ever want to make routing state scale sub-linearly (i.e. make IDR "compact") in the size of the internet, then we're almost certainly going to need some form of conglomeration of routing information in some shape or form. Still having support for aggregation in BGP could then be useful. It'd be a shame if we ended up having to choose between scalable and secure routing. (OTOH scalable routing is potentially so far off in the future, and might be so different, that it's hard to say what level of extra engineering or overhead, if any would be justified for SIDR). regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: COBOL: Completely Over and Beyond reason Or Logic. From christopher.morrow@gmail.com Wed Mar 28 09:15:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9601A21E808F; Wed, 28 Mar 2012 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLQa7CyKoG2f; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9892F21E8135; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1789638obb.31 for ; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BOnqtymFmnekG3Q1PIOEh3AuqVm+jnz08U/tIOi/SDY=; b=BTJGwQ1jxmhIic+rMUaeQ3yzoZJochqSDwFFpzmtsyjA/rgRwa4sGkhlDDtSgLA6PX XrafDYFIlDnGxuIBMrdGmGQiQURKABytJ6mHMmfT9y4JByQqxbo/2LhtdxEU5IGIxFY5 E7IVHvYl+XG66xmf6Kunx4xcusnonH9nvovB0caz7ux2I/QvH/7vqaSKRPlv93PILurw qWJIGjsFZBU0xlvOlmHKcqmU7RUW0sr0T/BnBNDC4cbSrl4IHYCzI9ex4SLVZmE+fLkj LcAHTj3tfl0LPCUMqru44RjPojeWoHxxOuD0Vec1Plv4QiJ5951zlhk4ShwwYdKXfv4K ZoKw== MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr38891209obb.71.1332951316187; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:15:16 -0700 (PDT) In-Reply-To: References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 28 Mar 2012 12:15:16 -0400 X-Google-Sender-Auth: NpVjtzScSQGFCmEAe1ifE7dHgEI Message-ID: From: Christopher Morrow To: Paul Jakma Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:15:17 -0000 On Wed, Mar 28, 2012 at 12:01 PM, Paul Jakma wrote: > On Wed, 28 Mar 2012, Jakob Heitz wrote: > >> The issue is SIDR can not aggregate multiple paths. > > >> Should SIDR work on path aggregation? > > > If we ever want to make routing state scale sub-linearly (i.e. make IDR > "compact") in the size of the internet, then we're almost certainly going to > need some form of conglomeration of routing information in some shape or > form. Still having support for aggregation in BGP could then be useful. or we could have fixed the problem with locator/id separation... oh well. > > It'd be a shame if we ended up having to choose between scalable and secure > routing. it's hardly a choice of one or the other, framing the question in this manner is a 'suckers choice'. It's certianly possible that at some point when aggregation between AS's becomes used properly and effectively... someone will figure out the security properties if this configuration. > (OTOH scalable routing is potentially so far off in the future, and might be > so different, that it's hard to say what level of extra engineering or > overhead, if any would be justified for SIDR). it seems that to date, folk can't seem to figure out the aggregation bits, maybe that will change in the future. -chris From robert@raszuk.net Wed Mar 28 09:29:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5346921E81C3 for ; Wed, 28 Mar 2012 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCTPDVFwp3x5 for ; Wed, 28 Mar 2012 09:29:45 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7EE21E819E for ; Wed, 28 Mar 2012 09:29:44 -0700 (PDT) Received: (qmail 29028 invoked by uid 399); 28 Mar 2012 16:29:44 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 16:29:44 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F733C79.8080600@raszuk.net> Date: Wed, 28 Mar 2012 18:29:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:29:46 -0000 Chris, > it seems that to date, folk can't seem to figure out the aggregation > bits, maybe that will change in the future. Let me point out that IBGP multipath is used very commonly today. When you do that you need to advertise something meaningful out to your neighbors. Yes that is open IDR topic no one seems to be actively working on. However let's not block any work on it just because SIDR can not handle some solutions. Are we going to freeze any AS_PATH modifications by operator's policy too ? I mentioned replace-as which all major vendors support. There can be more knobs like this coming in the future. CDNI is just getting extended to BGP (new SAFI) and they have their own uses for AS_PATH being sort of over the top of classic ASes. Regards, R. From christopher.morrow@gmail.com Wed Mar 28 09:38:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BBC21E8234; Wed, 28 Mar 2012 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP-C1YOmCwY5; Wed, 28 Mar 2012 09:38:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6410521E8191; Wed, 28 Mar 2012 09:38:10 -0700 (PDT) Received: by ghbg16 with SMTP id g16so973430ghb.31 for ; Wed, 28 Mar 2012 09:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5fbmyIaMKqeSwebjDiIbQam1/AAH6jiqpPOUKR7Bu/M=; b=ouOwJkG2+KvHL6OFhBK/ItUPZ8I0kL3tuWgur85OCHG4sQVBzOwIWaATvWorgat6dl NLMeWeDdLijl+ae86qUF8Z9ozBzlb95+fu9vvDcyFEp0MFX2e50m2H5YKVgQSFBAcJEf 0TxCwkRaLA3+0yz64ygkgPssph4ZU4eWhdmQdyUo2kPBDWRmi1vvJidjGgYbSF6jECyR cuhEM3wqadSYsbXvMK7HpNWfyyJyMs+vLpLe3ArLSAE6pC11pb+1SRGbCFJqNCiuHNnR 57ZitNMzSBQ9pv1IjQz2YpqttPWi4D20Xsk4F37pgk3x/5DMCR4fr6fm/iQgXwEYiSSa QXOg== MIME-Version: 1.0 Received: by 10.60.24.164 with SMTP id v4mr35010478oef.51.1332952689874; Wed, 28 Mar 2012 09:38:09 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:38:09 -0700 (PDT) In-Reply-To: <4F733C79.8080600@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> Date: Wed, 28 Mar 2012 12:38:09 -0400 X-Google-Sender-Auth: kUkfbJ7WVX0vuV2p82qTCnfRrLg Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:38:18 -0000 On Wed, Mar 28, 2012 at 12:29 PM, Robert Raszuk wrote: > Are we going to freeze any AS_PATH modifications by operator's policy too ? > I mentioned replace-as which all major vendors support. There can be more > knobs like this coming in the future. replace as i think is dealt with .... sign again and pcount=0 and move along. > CDNI is just getting extended to BGP (new SAFI) and they have their own uses > for AS_PATH being sort of over the top of classic ASes. good for them? From robert@raszuk.net Wed Mar 28 09:43:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F37121E8258 for ; Wed, 28 Mar 2012 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vG3YNdIc9DP for ; Wed, 28 Mar 2012 09:43:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4430321E8234 for ; Wed, 28 Mar 2012 09:43:44 -0700 (PDT) Received: (qmail 15704 invoked by uid 399); 28 Mar 2012 16:43:41 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 16:43:41 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F733FBE.1020902@raszuk.net> Date: Wed, 28 Mar 2012 18:43:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:43:45 -0000 >> Are we going to freeze any AS_PATH modifications by operator's policy too ? >> I mentioned replace-as which all major vendors support. There can be more >> knobs like this coming in the future. > > replace as i think is dealt with .... sign again and pcount=0 and move along. replace-as allows to replace any arbitrary match of list of ASes in the AS_PATH by your own AS. Does not need to be the last one. I don't think SIDR has a solution to deal with such policy. Best regards, R. From christopher.morrow@gmail.com Wed Mar 28 09:45:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE24C21E8268; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F87qYz3idpXk; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4279421E80F3; Wed, 28 Mar 2012 09:45:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1825007obb.31 for ; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+Ge5LcT3qUg4DbDJxMmS/8vUJ2+NlGYHLRryBPreCUE=; b=CivTklSivROsZ5zFWSoSGTbXqSsgolTs+gOTymKrXguT49sP//8LbfI7W5BNNd0Tu8 0FybenzJn4BONWakmhDkqrCRnmZCAxzorI7jDYhYBkScPplp3jjYs8TCxNzZ0F9xa/lW Tzmblaz0w6XV4Oig1UkptT2moLbMnXCGGG2b9QOc0LqjWbnvDXsoD7whp4ZDL2QXOkta 5af0o+9lwXZkZoisdVcDG4k8CvS/NhbNnN9SyQTFMYau/486HaCzqvf/vP6FbQi4nxjU 3RwI4Jun2AmxChyoQq0CUCthNkL8YNMHmiZgUAhAa3EBvcxD/kOgpt68xWxtXzRWLnSU 8f2A== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr38456879obb.61.1332953122839; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 09:45:22 -0700 (PDT) In-Reply-To: <4F733FBE.1020902@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> Date: Wed, 28 Mar 2012 12:45:22 -0400 X-Google-Sender-Auth: -ZUr_-v_m2YbAL2MLLYop-shfa8 Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:45:24 -0000 On Wed, Mar 28, 2012 at 12:43 PM, Robert Raszuk wrote: > >>> Are we going to freeze any AS_PATH modifications by operator's policy too >>> ? >>> I mentioned replace-as which all major vendors support. There can be more >>> knobs like this coming in the future. >> >> >> replace as i think is dealt with .... sign again and pcount=0 and move >> along. > > > replace-as allows to replace any arbitrary match of list of ASes in the > AS_PATH by your own AS. Does not need to be the last one. ah yes, was thinking of local-as. the 'replace-as' seems like loop-creation, joy. > I don't think SIDR has a solution to deal with such policy. nope, seems crazy though:) (to use it I mean) From shane@castlepoint.net Wed Mar 28 09:53:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEFC21E80C4 for ; Wed, 28 Mar 2012 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEdb8KJ14uH9 for ; Wed, 28 Mar 2012 09:53:54 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id A775121E8091 for ; Wed, 28 Mar 2012 09:53:54 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 706E8268063; Wed, 28 Mar 2012 10:53:54 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Mar 2012 10:53:54 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=50272; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Shane Amante In-Reply-To: Date: Wed, 28 Mar 2012 18:53:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D95FAC8-02B6-4BBA-A37D-2DB3FBE27ACF@castlepoint.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:53:55 -0000 On Mar 28, 2012, at 3:34 PM, George, Wes wrote: >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >> Christopher Morrow >> Sent: Wednesday, March 28, 2012 8:25 AM >> To: Randy Bush; sidr@ietf.org; sidr-chairs@ietf.org >> Subject: [sidr] draft-ietf-sidr-bgpsec-ops - Ready for WGLC? >>=20 >> Is this document prepared/ready/willing for WGLC in the near future? > [WEG] There are far too many things in flux within BGPSec design for = this companion doc to be anywhere near ready. As things coalesce, there = are undoubtedly going to be updates to this draft. >=20 > Origin ops, sure, but not BGPsec-ops. +1. -shane > Wes >=20 > 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 From Sandra.Murphy@sparta.com Wed Mar 28 10:00:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35CF21E82A8; Wed, 28 Mar 2012 10:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sApDSMrkhgw; Wed, 28 Mar 2012 10:00:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id F258621E8254; Wed, 28 Mar 2012 10:00:58 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SH0tC1028116; Wed, 28 Mar 2012 12:00:55 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SH0jrM018452; Wed, 28 Mar 2012 12:00:45 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 13:00:44 -0400 From: "Murphy, Sandra" To: "robert@raszuk.net" , Christopher Morrow Thread-Topic: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: AQHNDP4G0vO63JE6pUGZF6souGb62JaAKQqAgAACWYCAAAGNAP//vzar Date: Wed, 28 Mar 2012 17:00:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> , <4F733FBE.1020902@raszuk.net> In-Reply-To: <4F733FBE.1020902@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:00:59 -0000 Replacing ASs in the AS_PATH sounds like a behavior you would want the secu= rity protections to prohibit. It would enable attacks.=0A= =0A= Can you explain how you would distinguish legitimate uses of this feature?= =0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Ras= zuk [robert@raszuk.net]=0A= Sent: Wednesday, March 28, 2012 12:43 PM=0A= To: Christopher Morrow=0A= Cc: idr@ietf.org List; Paul Jakma; sidr wg list=0A= Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath= =0A= =0A= >> Are we going to freeze any AS_PATH modifications by operator's policy to= o ?=0A= >> I mentioned replace-as which all major vendors support. There can be mor= e=0A= >> knobs like this coming in the future.=0A= >=0A= > replace as i think is dealt with .... sign again and pcount=3D0 and move = along.=0A= =0A= replace-as allows to replace any arbitrary match of list of ASes in the=0A= AS_PATH by your own AS. Does not need to be the last one.=0A= =0A= I don't think SIDR has a solution to deal with such policy.=0A= =0A= Best regards,=0A= R.=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From pmohapat@cisco.com Wed Mar 28 10:06:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A221E82C6 for ; Wed, 28 Mar 2012 10:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcUMotg1q5tW for ; Wed, 28 Mar 2012 10:06:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9538821E82C0 for ; Wed, 28 Mar 2012 10:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=2114; q=dns/txt; s=iport; t=1332954398; x=1334163998; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8RxhBljzdz/3xFUiGmmr0d80S7xv4AGCtrpAJKRuI0s=; b=Qu+ohj486sxphtP0FT5LQaBxPpr1YaDp0mmBkzGU9zD/IVTAiZeXE60p vuCqAtdB/4rmTZ+kcBf91TMHYYrUOvCtdCK9sUJQJHmFt1G8BsMGHjzsc QIK7Ha6nASxZfUTR4qvW8LjPSaxRyqWfgtw+doLJuXizMK41zU75Zcaoe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ5Ec0+rRDoG/2dsb2JhbABFuGyBB4IJAQEBAwESASUCPxALRlcGJw6HYwSbfZ8kkC9jBIhYjQmORYFogweBNhc X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="38054949" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Mar 2012 17:06:38 +0000 Received: from sjc-vpn6-894.cisco.com (sjc-vpn6-894.cisco.com [10.21.123.126]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SH6cH6015521; Wed, 28 Mar 2012 17:06:38 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: <20336.45627.147578.984228@oz.mt.att.com> Date: Wed, 28 Mar 2012 10:07:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20336.45627.147578.984228@oz.mt.att.com> To: Jay Borkenhagen X-Mailer: Apple Mail (2.1075.2) Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:06:39 -0000 Hi Jay, >> at this afternoon's sidr ssion, i presented two open issue with >> draft-ietf-sidr-pfx-validate-04.txt >> >> 1 - Should updates learned via iBGP be marked? >> >> 2 - Should updates injected into BGP on this router be marked? >> >> i think yes because: >> o i want support of incremental deployment >> o i do not want to find out I am announcing garbage when my >> neighbor$,1ry(Bs >> NOC calls, mis-originations should be stopped at the source >> >> there was fear that, if used at other than edge routers, this allowed >> creation of loops, as setting local pref etc, do. >> >> i think there was general agreement that this was ok on edge routers >> and the point of injection, as that is logically an edge router. >> >> would like to see convergence on this > > > I could not hear the discussion in the room today because the utter > webex fail prevented my remote participation. So let me ask about > today's discussion. > > Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just > at ingress edge routers, and if the policy is broken it can result in > loops. It's something to watch out for when designing a policy, but I > am thankful that this kind of flexibility exists, because not all > policies that manipulate attributes other than at ingress edges are > broken. > > Regarding pfx-validate: > > I hope the agreement in the room was that a sane network design would > probably involve setting a local 'origin has been checked' community > on the first router inside the AS where that check occurred. like draft-ietf-sidr-origin-validation-signaling ? > > I hope the agreement was _not_ that pfx-validate implementations > should be hard-coded to assess validation state only at the ingress > edge router. I couldn't go to IETF either. The argument is over what the default behavior should be (spec'ed). My vote is that origin validation should NOT be performed on IBGP learnt prefixes by default as there is potential for loops and inconsistency. For everything else, there are knobs. - Pradosh From randy@psg.com Wed Mar 28 10:13:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF5E21E8274 for ; Wed, 28 Mar 2012 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlMu4VsY7yzt for ; Wed, 28 Mar 2012 10:13:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3521E80A4 for ; Wed, 28 Mar 2012 10:13:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCwRI-000KiI-Un; Wed, 28 Mar 2012 17:13:41 +0000 Date: Wed, 28 Mar 2012 19:13:39 +0200 Message-ID: From: Randy Bush To: Pradosh Mohapatra In-Reply-To: References: <20336.45627.147578.984228@oz.mt.att.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:13:43 -0000 > I couldn't go to IETF either. The argument is over what the default > behavior should be (spec'ed). My vote is that origin validation should > NOT be performed on IBGP learnt prefixes by default as there is > potential for loops and inconsistency. For everything else, there are > knobs. you mean like there is with local pref? one should only set these at the edge. randy From pmohapat@cisco.com Wed Mar 28 10:17:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6C21E80AB for ; Wed, 28 Mar 2012 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crSAzoBzDCsl for ; Wed, 28 Mar 2012 10:17:45 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3421E80A4 for ; Wed, 28 Mar 2012 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=585; q=dns/txt; s=iport; t=1332955065; x=1334164665; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hVRrspbvTB09903dI5ANpOzAHPO0L9t9RMTgwsFCgT0=; b=DtHcFRryQ23eAOhftkWIY8PPxbVuVMxI7dAC3qgufaXoeqDQdFp2W835 DAdvWpckTW707Ix1IGHFEGc+wXmOdJjFTSV5aplPx5eakxuAo2TtaMw+R Qv539sWSDdKGTxB5utqSZrU0+kZAWdfrXIMJT3rkGa4hjan9RP87DWTEU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPdGc0+rRDoH/2dsb2JhbABFuGyBB4IJAQEBAwESASUCPxALRlcGNYdjBJt6nySQL2MEiFiNCY5FgWiDB4E2Fw X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="38056716" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Mar 2012 17:17:45 +0000 Received: from sjc-vpn6-894.cisco.com (sjc-vpn6-894.cisco.com [10.21.123.126]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2SHHicK012889; Wed, 28 Mar 2012 17:17:44 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: Date: Wed, 28 Mar 2012 10:18:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8ED269A6-A913-46E3-A5FD-A3BDC6683D9F@cisco.com> References: <20336.45627.147578.984228@oz.mt.att.com> To: Randy Bush X-Mailer: Apple Mail (2.1075.2) Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:17:47 -0000 >> I couldn't go to IETF either. The argument is over what the default >> behavior should be (spec'ed). My vote is that origin validation >> should >> NOT be performed on IBGP learnt prefixes by default as there is >> potential for loops and inconsistency. For everything else, there are >> knobs. > > you mean like there is with local pref? No - knob to turn on IBGP validation. This is what pfx-validate says: This procedure SHOULD NOT be performed for Routes learned from peers of types other than EBGP. (Any of these MAY be overridden by configuration.) From randy@psg.com Wed Mar 28 10:26:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC2F21E809E for ; Wed, 28 Mar 2012 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zt2pWdQy7NR for ; Wed, 28 Mar 2012 10:26:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9E21E804A for ; Wed, 28 Mar 2012 10:26:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCwdc-000KkT-7U; Wed, 28 Mar 2012 17:26:24 +0000 Date: Wed, 28 Mar 2012 19:26:22 +0200 Message-ID: From: Randy Bush To: Pradosh Mohapatra In-Reply-To: <8ED269A6-A913-46E3-A5FD-A3BDC6683D9F@cisco.com> References: <20336.45627.147578.984228@oz.mt.att.com> <8ED269A6-A913-46E3-A5FD-A3BDC6683D9F@cisco.com> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:26:25 -0000 > No - knob to turn on IBGP validation. how many knobs will i have to turn to get policy control of my router? randy From heas@shrubbery.net Wed Mar 28 10:30:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1221E809E; Wed, 28 Mar 2012 10:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95BuxumnM2qD; Wed, 28 Mar 2012 10:30:10 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB5421E804A; Wed, 28 Mar 2012 10:30:10 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 673F888B42; Wed, 28 Mar 2012 17:30:10 +0000 (UTC) Date: Wed, 28 Mar 2012 17:30:10 +0000 From: heasley To: "Murphy, Sandra" Message-ID: <20120328173010.GB72348@shrubbery.net> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:30:11 -0000 Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra: > Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. > > Can you explain how you would distinguish legitimate uses of this feature? I've not used this feature, but from cisco's documentation, it doesnt appear to function as raszuk described. http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html if local-as is configured for a peer(-group), ie: if configured to peer as a different AS than your own, such as for merging two ASes or changing your ASN, then: "The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended." though I think that is unclear, I interpret it to mean that if my ASN is 1 and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will have the path [2 3], but if configured with replace-as, it will be [3]. I do not believe that the feature allows the arbitrary replacement of AS path elements. > --Sandy > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszuk.net] > Sent: Wednesday, March 28, 2012 12:43 PM > To: Christopher Morrow > Cc: idr@ietf.org List; Paul Jakma; sidr wg list > Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath > > >> Are we going to freeze any AS_PATH modifications by operator's policy too ? > >> I mentioned replace-as which all major vendors support. There can be more > >> knobs like this coming in the future. > > > > replace as i think is dealt with .... sign again and pcount=0 and move along. > > replace-as allows to replace any arbitrary match of list of ASes in the > AS_PATH by your own AS. Does not need to be the last one. > > I don't think SIDR has a solution to deal with such policy. > > Best regards, > R. > _______________________________________________ > 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 From Sandra.Murphy@sparta.com Wed Mar 28 10:38:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6987621E8040 for ; Wed, 28 Mar 2012 10:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klg82fdyZqzQ for ; Wed, 28 Mar 2012 10:38:22 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3532A21E804A for ; Wed, 28 Mar 2012 10:38:22 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2SHcL1q028653; Wed, 28 Mar 2012 12:38:21 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2SHc7Qw020015; Wed, 28 Mar 2012 12:38:14 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 13:38:06 -0400 From: "Murphy, Sandra" To: "draft-ietf-sidr-cps-irs@tools.ietf.org" , "draft-ietf-sidr-cps-isp@tools.ietf.org" Thread-Topic: status of draft-ietf-sidr-cps-irs and draft-ietf-sidr-cps-isp Thread-Index: Ac0NCYiVKcfxxTWgRqWnPVODTZFVxA== Date: Wed, 28 Mar 2012 17:38:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB7D7@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: [sidr] status of draft-ietf-sidr-cps-irs and draft-ietf-sidr-cps-isp X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:38:23 -0000 These two drafts have been expired for a good while now. Do the authors in= tend to pick them up now that the CP document is published?=0A= =0A= The wg should take a look at these and see if there is still interest in pu= rsuing them.=0A= =0A= --Sandy, speaking as wg co-chair= From robert@raszuk.net Wed Mar 28 13:07:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7BA21F864E for ; Wed, 28 Mar 2012 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe80Q0XwI62k for ; Wed, 28 Mar 2012 13:07:10 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9F21F8649 for ; Wed, 28 Mar 2012 13:07:09 -0700 (PDT) Received: (qmail 15980 invoked by uid 399); 28 Mar 2012 20:07:09 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:07:09 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F736F6E.70205@raszuk.net> Date: Wed, 28 Mar 2012 22:07:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:07:11 -0000 > the 'replace-as' seems like > loop-creation, joy. Nope. No loops at least in one implementation ... the implementation mandates that you insert your own AS - that is not optional. Rgs, R. From robert@raszuk.net Wed Mar 28 13:23:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4F921E80A3 for ; Wed, 28 Mar 2012 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7j2uJMfRqPx for ; Wed, 28 Mar 2012 13:23:35 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7021E802A for ; Wed, 28 Mar 2012 13:23:34 -0700 (PDT) Received: (qmail 10182 invoked by uid 399); 28 Mar 2012 20:23:34 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:23:34 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F737347.4040206@raszuk.net> Date: Wed, 28 Mar 2012 22:23:35 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: heasley , "Murphy, Sandra" References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> <20120328173010.GB72348@shrubbery.net> In-Reply-To: <20120328173010.GB72348@shrubbery.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:23:36 -0000 > it doesnt appear to function as raszuk described. Let me point out that heasley is looking at completely different knob which has nothing to do with replace as path policy extension. The correct pointer is: http://goo.gl/xVToJ Rgs, R. > Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra: >> Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. >> >> Can you explain how you would distinguish legitimate uses of this feature? > > I've not used this feature, but from cisco's documentation, it doesnt appear > to function as raszuk described. > > http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html > > if local-as is configured for a peer(-group), ie: if configured to peer as > a different AS than your own, such as for merging two ASes or changing your > ASN, then: > "The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended." > > though I think that is unclear, I interpret it to mean that if my ASN is 1 > and, I peer as ASN 2 with ebgp peer 3, then a route received from AS 3 will > have the path [2 3], but if configured with replace-as, it will be [3]. > > I do not believe that the feature allows the arbitrary replacement of AS path > elements. > >> --Sandy >> >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszuk.net] >> Sent: Wednesday, March 28, 2012 12:43 PM >> To: Christopher Morrow >> Cc: idr@ietf.org List; Paul Jakma; sidr wg list >> Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath >> >>>> Are we going to freeze any AS_PATH modifications by operator's policy too ? >>>> I mentioned replace-as which all major vendors support. There can be more >>>> knobs like this coming in the future. >>> >>> replace as i think is dealt with .... sign again and pcount=0 and move along. >> >> replace-as allows to replace any arbitrary match of list of ASes in the >> AS_PATH by your own AS. Does not need to be the last one. >> >> I don't think SIDR has a solution to deal with such policy. >> >> Best regards, >> R. >> _______________________________________________ >> 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From brian.peter.dickson@gmail.com Wed Mar 28 13:25:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11921E802A; Wed, 28 Mar 2012 13:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgfpNrj7+kJr; Wed, 28 Mar 2012 13:25:08 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 941C521E8019; Wed, 28 Mar 2012 13:25:07 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so4570386wgb.1 for ; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6nR4oM1o2kq+HyP99ZpUw+NjW2V8m5esmLE2iXfHQ3I=; b=O0h0RjTM8eDyLASb2X2ph5Z79QDXDZf6AcxT2RpEKt5tMDY53nEg7baXRAzA90oumh g2Wxi//nJtc1zz/1jZh/rQNpGBQMndroRBuLucBDDkLSiT/z9BXwLDWvyCD6aqsTSE+g Tv5/GtWcXJSBD1Vam/CCEYZQ4R1QEDR/h6X23bJG5Gn9ns0D6nCBYSTYL8TPdDGGqATz NCclu8YxcPIZRxQAmA/21ezX1G5OCeC5OCELXCdFbuBy6djBDIJ2pTlpY5FKpDhi59M8 JIjFDG5a95gDNjJfax3ZDVbuMuYz+UrqmagSMl0dorzXt1gugm8Q3urFsFWI0LkyoKZZ NGvg== MIME-Version: 1.0 Received: by 10.216.133.93 with SMTP id p71mr18501949wei.10.1332966306719; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 28 Mar 2012 13:25:06 -0700 (PDT) In-Reply-To: <4F736F6E.70205@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> Date: Wed, 28 Mar 2012 16:25:06 -0400 Message-ID: From: Brian Dickson To: robert@raszuk.net Content-Type: multipart/alternative; boundary=0016e6dbde5735a74d04bc536740 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:25:08 -0000 --0016e6dbde5735a74d04bc536740 Content-Type: text/plain; charset=ISO-8859-1 Arbitrary AS substitution allows loop creation, even if your own AS is required. All that is needed, is multiple instances of replace-as in the loop. Suppose A replaces B C D with A E F. Suppose B replaces G A with B C D. A received B C D, sends A E F to G. G sends G A E F to B. B sends B C D E F to A. We have a loop, which eventually results in path overflow with E F E F E F etc. at the end of it. On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk wrote: > > the 'replace-as' seems like >> loop-creation, joy. >> > > Nope. No loops at least in one implementation ... the implementation > mandates that you insert your own AS - that is not optional. > > Rgs, > R. > > ______________________________**_________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/**listinfo/sidr > --0016e6dbde5735a74d04bc536740 Content-Type: text/html; charset=ISO-8859-1 Arbitrary AS substitution allows loop creation, even if your own AS is required.

    All that is needed, is multiple instances of replace-as in the loop.

    Suppose A replaces B C D with A E F.

    Suppose B replaces G A with B C D.

    A received B C D, sends A E F to G.

    G sends G A E F to B.
    B sends B C D E F to A.

    We have a loop, which eventually results in path overflow with E F E F E F etc. at the end of it.

    On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk <robert@raszuk.net> wrote:

    the 'replace-as' seems like
    loop-creation, joy.

    Nope. No loops at least in one implementation ... the implementation mandates that you insert your own AS - that is not optional.

    Rgs,
    R.

    _______________________________________________
    sidr mailing list
    sidr@ietf.org
    https://www.ietf.org/mailman/listinfo/sidr

    --0016e6dbde5735a74d04bc536740-- From robert@raszuk.net Wed Mar 28 13:30:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A01721F87BC for ; Wed, 28 Mar 2012 13:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjo3HQVjmtzL for ; Wed, 28 Mar 2012 13:30:34 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id B44BA21F8853 for ; Wed, 28 Mar 2012 13:30:32 -0700 (PDT) Received: (qmail 4324 invoked by uid 399); 28 Mar 2012 20:30:25 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 28 Mar 2012 20:30:25 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F7374DD.7060301@raszuk.net> Date: Wed, 28 Mar 2012 22:30:21 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Brian Dickson References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:30:34 -0000 Brian, The customer's workaround was to erase entire AS_PATH via redistribution. I am not saying that use of this knob is safe. I am saying that it exists in shipping implementations and simply asking what SIDR behaviour should be when such policy is present. That's all. Best, R. > Arbitrary AS substitution allows loop creation, even if your own AS is > required. > > All that is needed, is multiple instances of replace-as in the loop. > > Suppose A replaces B C D with A E F. > > Suppose B replaces G A with B C D. > > A received B C D, sends A E F to G. > > G sends G A E F to B. > B sends B C D E F to A. > > We have a loop, which eventually results in path overflow with E F E F E > F etc. at the end of it. > > On Wed, Mar 28, 2012 at 4:07 PM, Robert Raszuk > wrote: > > > the 'replace-as' seems like > loop-creation, joy. > > > Nope. No loops at least in one implementation ... the implementation > mandates that you insert your own AS - that is not optional. > > Rgs, > R. > > _________________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/__listinfo/sidr > > > From jhaas@slice.pfrc.org Wed Mar 28 13:55:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A221F883D; Wed, 28 Mar 2012 13:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+E4f+r9d83I; Wed, 28 Mar 2012 13:55:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42121F8833; Wed, 28 Mar 2012 13:55:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F76C170425; Wed, 28 Mar 2012 16:55:22 -0400 (EDT) Date: Wed, 28 Mar 2012 16:55:22 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120328205522.GA16814@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:55:24 -0000 Chris, On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote: > ah yes, was thinking of local-as. the 'replace-as' seems like > loop-creation, joy. It can. The use of replace-as is typically in situations where you need to replace private AS numbers with a public number. This is typically done when you have deployments that have a mix of private and public ASes behind a common transit carrier and "remove-private" isn't sufficient. The required behavior in order to avoid problems here is to make sure that the set of ASes involved are behind that common carrier and either are not multi-homed to the wider Internet (unlikely since they have private ASes) or are applying appropriate AS filtering to manually suppress loops. -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:05:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E61421E8040; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEglyoKWX9fy; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1C93821E800E; Wed, 28 Mar 2012 14:05:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DB75F17041D; Wed, 28 Mar 2012 17:05:19 -0400 (EDT) Date: Wed, 28 Mar 2012 17:05:19 -0400 From: Jeffrey Haas To: Paul Jakma Message-ID: <20120328210519.GC16814@slice> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:05:20 -0000 Paul, On Wed, Mar 28, 2012 at 02:10:04PM +0100, Paul Jakma wrote: > Where's the document to describe how to do multi-pathing using > add-path? E.g. what should happen when there is a non-add-path > capable neighbour? In add-path, this is no different than receiving routes from directly attached peers. You should either do Internet-safe multipath or do the less safe multipath knowing that you're in a position to cause problems. Add-path doesn't really change the basic problem of multipath. -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:17:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A7421F843E; Wed, 28 Mar 2012 14:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoED3lGA5iGT; Wed, 28 Mar 2012 14:17:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8221E8132; Wed, 28 Mar 2012 14:17:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E2C80170421; Wed, 28 Mar 2012 17:17:28 -0400 (EDT) Date: Wed, 28 Mar 2012 17:17:28 -0400 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20120328211728.GD16814@slice> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:17:43 -0000 On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > > Solutions I can think of: > 1. Aggregate the signatures of the paths being aggregated. What are the semantics you're trying to preserve SIDR-wise? We're hitting the realm where Russ White would point out that BGP path validation can't prove how forwarding works. Presume we managed to pass along two distinct paths for the same multi-path route in BGP. What do you do if one doesn't validate? What do you do if they do, but you think this is a form of a "route leak" for one path? As a receiver of the route that is making use of multipath, you can't selectively choose which sub-paths to take. (It's not like we're gettng something like MPLS entropy labels.) > 2. Don't aggregate, but send both paths. That doesn't cover the actual forwarding semantics. > Should SIDR work on path aggregation? > Are there other possibilities? The biggest problem here is "SIDR secures BGP". The issue hasn't been clear in BGP for years, although I'm perhaps of the cynical opinion that it's been a well understood problem space for a while now. The protocol doesn't reflect what is done operationally. The safe thing operationally when aggregating unsafe paths is to generate sets, but some people have never liked sets. And as I mentioned elsewhere, it doesn't matter as long as you take care in where you redistribute such unsafe multipath. There was a reason I wasn't terribly supportive of the deprecating AS_SETs I-D. However, I also knew it was a losing battle. :-) -- Jeff From jhaas@slice.pfrc.org Wed Mar 28 14:23:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FE821F860E; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRM0dyBtXTVB; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD9B21F860B; Wed, 28 Mar 2012 14:23:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F04221703F4; Wed, 28 Mar 2012 17:23:34 -0400 (EDT) Date: Wed, 28 Mar 2012 17:23:34 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120328212334.GF16814@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:23:35 -0000 On Wed, Mar 28, 2012 at 12:45:22PM -0400, Christopher Morrow wrote: > ah yes, was thinking of local-as. the 'replace-as' seems like > loop-creation, joy. For the list, as I mentioned in SIDR, the use of local-AS where the router has more than one local AS will generate AS_SETs in some implementations. In particular, implementations with gated lineages may do this. This is because in pretending to be another AS it's still necessary to throw the global and local ASes in the path to prevent loops in cases where the local AS on one router may not be configured consistently (global) AS-wide. In those implementations, a single AS is simply added prior to the global AS in the path as a sequence or all local ASes as a set. In another implementation, the local ASes are added as a sequence. Adding the additional AS to the path would still require an additional signature step in BGPSEC. Clearly this doesn't work for AS-sets. -- Jeff From jakob.heitz@ericsson.com Wed Mar 28 15:02:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3021E80FC; Wed, 28 Mar 2012 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO+zX15AHvXl; Wed, 28 Mar 2012 15:02:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C281B21E80B1; Wed, 28 Mar 2012 15:02:49 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2SM2laZ017641; Wed, 28 Mar 2012 17:02:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 28 Mar 2012 18:02:46 -0400 From: Jakob Heitz To: sidr wg list Date: Wed, 28 Mar 2012 18:03:16 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0NLoGzh7neYzreT06/e8Cqxu9uMA== Message-ID: <1229E370-0830-4815-AFB7-304D1479FC62@ericsson.com> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> In-Reply-To: <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 22:02:51 -0000 including sidr=20 -- Jakob Heitz. On Mar 28, 2012, at 11:57 PM, "Jakob Heitz" wrot= e: > This can be done. > Like I said before: aggregate the signatures of the paths being aggregate= d. > String all the signed paths together (after wrapping them with a header),= add your SKI and destination AS (as normal) and sign over the lot. >=20 > Question is: does anyone want to? >=20 > -- > Jakob Heitz. >=20 >=20 > On Mar 28, 2012, at 11:17 PM, "Tony Li" wrote: >=20 >>=20 >> On Mar 28, 2012, at 2:09 PM, Robert Raszuk wrote: >>=20 >>>>> * Continue to call as_aggregate and still generate AS_SET >>>>> effectively depreciating RFC6472 (quagga approach) >>>>=20 >>>> Generating sets is the safest thing to do. >>>=20 >>> Glad you said this. I do agree. >>=20 >>=20 >> Understood, but how do you ever secure this? Set SIDR aside for a secon= d, what would ANY path verification mechanism have to do to secure the full= path? >>=20 >> It would seem that the ONLY thing one could reasonably do is to describe= the full topology, and that would seem to require the ability to describe = an arbitrary tree, not just a set of vectors of paths. >>=20 >> Tony >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Wed Mar 28 15:15:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0121E8101; Wed, 28 Mar 2012 15:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M8FIXWMr3PE; Wed, 28 Mar 2012 15:15:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5347B21E80FB; Wed, 28 Mar 2012 15:15:15 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2212580obb.31 for ; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OvDZYE8GehlboS1naVrDM7QBFZ4XJdcoNj+7y/yswtE=; b=lqYe5HtQE2U/CxqJFD6XnPE2xCCz0UDUuWFjdV0L9dCPibL6gWQTvMQp6GtrdsY2i6 JvtD0r38EF9L6WBBFBvMWvUUhMrH2SnUelgfdlFv7jc3Trf0rnqQOD2UF5FaO3HeCnY1 lvJRRfb/cyrBEaSDtvEr2k8s6h4dbP/tnCaWIU7zvsteyqeDbXAPQpL3AglV96EtL4wn BY9+Dz2TuBthDZ5cuTSszTInhnWdtcLPBV543qdqE+px1KdugTE80sey9qPwMKt2GDEr /YbOGXCRLGFGBtR/vYlNKw0hiBixXoKdb4oPHBCOLWDmtx02dwHkV3HwM/JVbU+abtPS iSYQ== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr39979033obb.61.1332972914880; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Wed, 28 Mar 2012 15:15:14 -0700 (PDT) In-Reply-To: <4F7374DD.7060301@raszuk.net> References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <4F736F6E.70205@raszuk.net> <4F7374DD.7060301@raszuk.net> Date: Wed, 28 Mar 2012 18:15:14 -0400 X-Google-Sender-Auth: Pl6mxZAWlmXnwmU-G4enVt-_ots Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 22:15:16 -0000 On Wed, Mar 28, 2012 at 4:30 PM, Robert Raszuk wrote: > I am saying that it exists in shipping implementations and simply asking > what SIDR behaviour should be when such policy is present. I guess what I wasn't saying was that not every oddball wierdness permitted TODAY in BGP is able to be secured, or validate-able. It's not required that this be the case actually. -chris From danny@tcb.net Wed Mar 28 17:33:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F221E808C for ; Wed, 28 Mar 2012 17:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haUn5-yyfMxQ for ; Wed, 28 Mar 2012 17:33:40 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5A121E8020 for ; Wed, 28 Mar 2012 17:33:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 192C1268063; Wed, 28 Mar 2012 18:33:40 -0600 (MDT) Received: from new-host-4.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Mar 2012 18:33:40 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=55927; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Danny McPherson In-Reply-To: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> Date: Wed, 28 Mar 2012 20:33:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> To: sidr wg list X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 00:33:41 -0000 i don't think the rsync scale issues surprise anyone that was paying = attention. If we're already considering new architectures, substrates, = et al., here perhaps we shouldn't be so quick on the trigger for = Standards Track work and move this and related "investigation" to the = IRTF, or at least ensure they're only Experimental until broader = experience is gained. Looking at the charts you presented I can only imagine what will happen = with 40K RPs and >1M objects (which might be a reasonable assumption if = this were fully deployed today - and that's only focusing on routed = number resources).=20 -danny On Mar 26, 2012, at 1:33 PM, Rob Austein wrote: > For those who didn't get to see the end of the "RPKI Over BitTorrent" > presentation in today's SIDR meeting, the full slide deck is available > at >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf >=20 > and should be relatively self-explanatory. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Wed Mar 28 18:02:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C40821E8041 for ; Wed, 28 Mar 2012 18:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrZaQdu-oOEt for ; Wed, 28 Mar 2012 18:02:40 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2D421E800F for ; Wed, 28 Mar 2012 18:02:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DBAAB268063; Wed, 28 Mar 2012 19:02:39 -0600 (MDT) Received: from new-host-4.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Mar 2012 19:02:39 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=57079; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Danny McPherson In-Reply-To: <20120328081939.GA19843@slice> Date: Wed, 28 Mar 2012 21:02:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120328081939.GA19843@slice> To: sidr wg list X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 01:02:40 -0000 On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote: > Per my mic comment at IETF 83: > During the San Diego interim session we had discussed potentially = signaling > in BGP the idea that a given AS may have fresher data available in its > repository.=20 Shouldn't this problem be solved in the resource certification = infrastructure (i.e., RPKI) - signaling RPKI freshness in BGP and = distributing to literally millions of routers seems like a REALLY bad = idea to me. -danny From Sandra.Murphy@sparta.com Wed Mar 28 23:46:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A5321E80E0 for ; Wed, 28 Mar 2012 23:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8dHF0XnL8wH for ; Wed, 28 Mar 2012 23:46:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0721E80DD for ; Wed, 28 Mar 2012 23:46:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2T6kuJM001217; Thu, 29 Mar 2012 01:46:56 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2T6ktJB001947; Thu, 29 Mar 2012 01:46:55 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 02:46:55 -0400 From: "Murphy, Sandra" To: Danny McPherson , sidr wg list Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP Thread-Index: AQHNDLuHdFMpLM9MUEW66tsebWmsS5aAuMoAgAAaQJc= Date: Thu, 29 Mar 2012 06:46:54 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB97C@Hermes.columbia.ads.sparta.com> References: <20120328081939.GA19843@slice>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:46:58 -0000 Speaking as regular ol' member.=0A= =0A= Too bad you couldn't make the meeting, Danny.=0A= =0A= This is in bgpsec path validation and the signalling would go no further th= an the bgpsec path validation would go.=0A= =0A= A method of "signalling" that was mentioned was the validity periods on the= router keys so all RPKI info needed would already be available. Other mea= ns were also discussed, no decision made.=0A= =0A= --Sandy, regular ol' member=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Wednesday, March 28, 2012 9:02 PM=0A= To: sidr wg list=0A= Subject: Re: [sidr] Injecting idea of "freshness of repository data" into B= GP=0A= =0A= On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote:=0A= =0A= > Per my mic comment at IETF 83:=0A= > During the San Diego interim session we had discussed potentially signali= ng=0A= > in BGP the idea that a given AS may have fresher data available in its=0A= > repository.=0A= =0A= =0A= Shouldn't this problem be solved in the resource certification infrastructu= re (i.e., RPKI) - signaling RPKI freshness in BGP and distributing to liter= ally millions of routers seems like a REALLY bad idea to me.=0A= =0A= -danny=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From jhaas@slice.pfrc.org Thu Mar 29 00:22:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD95B21F85AA for ; Thu, 29 Mar 2012 00:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.011 X-Spam-Level: X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEaNWBndouYB for ; Thu, 29 Mar 2012 00:22:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BFA9A21E80EA for ; Thu, 29 Mar 2012 00:22:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 888E517041E; Thu, 29 Mar 2012 03:22:36 -0400 (EDT) Date: Thu, 29 Mar 2012 03:22:36 -0400 From: Jeffrey Haas To: Danny McPherson Message-ID: <20120329072236.GA7311@slice> References: <20120328081939.GA19843@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:22:44 -0000 On Wed, Mar 28, 2012 at 09:02:24PM -0400, Danny McPherson wrote: > On Mar 28, 2012, at 4:19 AM, Jeffrey Haas wrote: > > Per my mic comment at IETF 83: > > During the San Diego interim session we had discussed potentially signaling > > in BGP the idea that a given AS may have fresher data available in its > > repository. > > Shouldn't this problem be solved in the resource certification infrastructure (i.e., RPKI) - signaling RPKI freshness in BGP and distributing to literally millions of routers seems like a REALLY bad idea to me. One "route" per AS in the system which is a 20byte value max (per the cert) hardly seems that scary. :-) But that said, I don't object to some sort of mechanism used as part of the RPKI infra would do such a "you may want to refresh" request. My thought is that since the certs in question are required for validation, the routing system already has a strong interest in making sure downstreams can validate (or invalidate!) routes. -- Jeff From jakob.heitz@ericsson.com Thu Mar 29 00:37:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FD521F8664; Thu, 29 Mar 2012 00:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ep5X-NKT2kd; Thu, 29 Mar 2012 00:37:40 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DDBE221F865E; Thu, 29 Mar 2012 00:37:38 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2T7batg020881; Thu, 29 Mar 2012 02:37:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 03:37:31 -0400 From: Jakob Heitz To: Jeffrey Haas , sidr wg list Date: Thu, 29 Mar 2012 03:38:00 -0400 Thread-Topic: [Idr] AS_SET depreciation (RFC6472) and BGP multipath Thread-Index: Ac0NfswdCrXhNNkERAWjzsbUAFPwEQ== Message-ID: <3C0C3A96-8AFD-4AD6-A571-5896DD370806@ericsson.com> References: <4F72166F.6080503@raszuk.net> <20120328210335.GB16814@slice> <4F737DF4.7030202@raszuk.net> <24F722F3-4D36-40D4-83FE-27B14CB5B9ED@tony.li> <5FE465B7-5005-4FE4-B97C-0608C9F9A45C@ericsson.com> <20120329071053.GA6831@slice> In-Reply-To: <20120329071053.GA6831@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:37:41 -0000 of course, we would need to reinvent the AS_SET to go along with it, but th= is time, enumerating each exact path. Definitely unwieldy. -- Jakob Heitz. On Mar 29, 2012, at 9:10 AM, "Jeffrey Haas" wrote: > On Wed, Mar 28, 2012 at 05:57:32PM -0400, Jakob Heitz wrote: >> This can be done. >> Like I said before: aggregate the signatures of the paths being aggregat= ed. >> String all the signed paths together (after wrapping them with a header)= , add your SKI and destination AS (as normal) and sign over the lot. >>=20 >> Question is: does anyone want to? >=20 > At minimum, this would further decouple the signature from the actual pat= h. >=20 > And given multipath covers *many* routes, the result would likely be > unwieldy. >=20 > -- Jeff From jakob.heitz@ericsson.com Thu Mar 29 00:50:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3906921F88A9 for ; Thu, 29 Mar 2012 00:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WklfTx5KeSPD for ; Thu, 29 Mar 2012 00:50:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 04BDA21F88AA for ; Thu, 29 Mar 2012 00:50:40 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2T7od89024813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 02:50:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 03:50:39 -0400 From: Jakob Heitz To: Jeffrey Haas Date: Thu, 29 Mar 2012 03:51:10 -0400 Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP Thread-Index: Ac0NgKJSzknqk2ZPTj2OLKxRSKkVaA== Message-ID: <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> In-Reply-To: <20120329072236.GA7311@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:50:42 -0000 Could we not put a freshness indication into the BGP update? Then everyone that receives the new update would know to invalidate the les= s fresh paths. Here is the key point: The new update will reach everywhere that it needs to go. Won't it? No expiry time needed. -- Jakob Heitz.= From jakob.heitz@ericsson.com Thu Mar 29 00:58:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BFE21F8978 for ; Thu, 29 Mar 2012 00:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPj3eXuffSKU for ; Thu, 29 Mar 2012 00:58:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7F21F8974 for ; Thu, 29 Mar 2012 00:58:13 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2T7wBf7021398; Thu, 29 Mar 2012 02:58:12 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 29 Mar 2012 03:58:06 -0400 From: Jakob Heitz To: Jakob Heitz Date: Thu, 29 Mar 2012 03:58:38 -0400 Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP Thread-Index: Ac0NgazA05JkQoEETy2psAv0reFN3Q== Message-ID: <00857EED-F2E7-4E41-884E-F25492CF3BF1@ericsson.com> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> In-Reply-To: <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:58:15 -0000 Any place that does not receive a new BGP update can not be helped. Even wi= th a beacon. Therefore, a freshness indicator in the BGP update itself is enough to inva= lidate less fresh updates. Only freshen the BGP update when you actually have a dispute with your old = provider. -- Jakob Heitz. On Mar 29, 2012, at 9:51 AM, "Jakob Heitz" wrote= : > Could we not put a freshness indication into the BGP update? > Then everyone that receives the new update would know to invalidate the l= ess fresh paths. >=20 > Here is the key point: > The new update will reach everywhere that it needs to go. > Won't it? >=20 > No expiry time needed. >=20 > -- > Jakob Heitz. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu Mar 29 01:05:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4AD21F8890 for ; Thu, 29 Mar 2012 01:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2nHZodqamJJ for ; Thu, 29 Mar 2012 01:05:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 227ED21F886E for ; Thu, 29 Mar 2012 01:05:35 -0700 (PDT) Received: by obbta17 with SMTP id ta17so225649obb.31 for ; Thu, 29 Mar 2012 01:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=byDF3vHT2kiKkVZjiAUqgPrYnPXrdPVMCh4f1IK+PMs=; b=TIFEnOnY2LmM/+kuFE14BFbQzHD9wIaX2GJedFl/MvWqQoXgpiYyv3aEkoUBJG836L iwrZD76Vw/BrYgPxs8yKb1Cd0X7n6dKhO1fEZXVsb6FKUsbNMMHzNyLoTWMiepVgpHTV Vff/N1zxnjwjiHbz6w0KSuF8lTBuYuP23Ck1H23AZyawIx+g2giGzPgMjj0OlemZAJmP /yZdT2UmJVP0TEvVOl7psGNjTpU8ODPbzEEXXdSghuCdgT78h1v81UiRHI78PmGS8hFu aOLpYGieCviEV0jZWBiHsA+cSCP33hk676mV2VGDn7wpvoPDUV+f2knfMbb+en3IDq9p XlpA== MIME-Version: 1.0 Received: by 10.182.155.68 with SMTP id vu4mr41683416obb.61.1333008334719; Thu, 29 Mar 2012 01:05:34 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 01:05:34 -0700 (PDT) In-Reply-To: References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> Date: Thu, 29 Mar 2012 04:05:34 -0400 X-Google-Sender-Auth: Lyt6Gwu9TajrCgHkgQXfs0GFoyQ Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:05:35 -0000 On Wed, Mar 28, 2012 at 8:33 PM, Danny McPherson wrote: > > i don't think the rsync scale issues surprise anyone that was paying atte= ntion. =A0If we're already considering new architectures, substrates, et al= ., here perhaps we shouldn't be so quick on the trigger for Standards Track= work and move this and related "investigation" to the IRTF, or at least en= sure they're only Experimental until broader experience is gained. > terry seemed interested (and had a draft from 08 that looked like an alternate option for transport) in gathering some requirements and options for transport... I think in the end having more than one transport is good, having one to start things off though is also good. -chris > Looking at the charts you presented I can only imagine what will happen w= ith 40K RPs and >1M objects (which might be a reasonable assumption if this= were fully deployed today - and that's only focusing on routed number reso= urces). > > -danny > > > On Mar 26, 2012, at 1:33 PM, Rob Austein wrote: > >> For those who didn't get to see the end of the "RPKI Over BitTorrent" >> presentation in today's SIDR meeting, the full slide deck is available >> at >> >> =A0http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf >> >> and should be relatively self-explanatory. >> _______________________________________________ >> 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 From jhaas@slice.pfrc.org Thu Mar 29 01:16:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52B21F87CB for ; Thu, 29 Mar 2012 01:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9RE+Jb1AJ5Q for ; Thu, 29 Mar 2012 01:16:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B187721F89BF for ; Thu, 29 Mar 2012 01:16:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79D81170427; Thu, 29 Mar 2012 04:16:25 -0400 (EDT) Date: Thu, 29 Mar 2012 04:16:25 -0400 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20120329081625.GA9609@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:16:30 -0000 Jakob, On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote: > Could we not put a freshness indication into the BGP update? > Then everyone that receives the new update would know to invalidate the less fresh paths. Just to be clear, this is not a route freshness mechanism I am recommending. What I am recommending is a signal that a repository has newer data that may be needed for validation. Given such a mechanism, we may be able to reduce the work upon the repository mirroring system (distributed or not) by not having to regularly poll for new objects frequently unless the repository indicates there is new data present. -- Jeff From jhaas@slice.pfrc.org Thu Mar 29 01:21:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2921F8A03; Thu, 29 Mar 2012 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzmKC4-dPbEW; Thu, 29 Mar 2012 01:21:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E06ED21F8A07; Thu, 29 Mar 2012 01:21:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AC599170429; Thu, 29 Mar 2012 04:21:03 -0400 (EDT) Date: Thu, 29 Mar 2012 04:21:03 -0400 From: Jeffrey Haas To: "Murphy, Sandra" Message-ID: <20120329082103.GC9609@slice> References: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <4F733C79.8080600@raszuk.net> <4F733FBE.1020902@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB73F@Hermes.columbia.ads.sparta.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , sidr wg list Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:21:04 -0000 Sandy, On Wed, Mar 28, 2012 at 05:00:43PM +0000, Murphy, Sandra wrote: > Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. > > Can you explain how you would distinguish legitimate uses of this feature? The feature is typically used on private AS numbers. One could point out that any procedures dealing with them are probably out of scope of SIDR. :-) -- Jeff From christopher.morrow@gmail.com Thu Mar 29 01:24:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811421F8A20 for ; Thu, 29 Mar 2012 01:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK963eftoiLr for ; Thu, 29 Mar 2012 01:24:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6AAD21F8A1F for ; Thu, 29 Mar 2012 01:24:46 -0700 (PDT) Received: by obbta17 with SMTP id ta17so251495obb.31 for ; Thu, 29 Mar 2012 01:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I3K2lcZLKoWFkHXr4cvQX652LFUIVtkMwM1RDAwoTnY=; b=CbRB+P+q2ckZohT6bSIdx17dUDZT5aol2LnyT/1V9X7I52ZxJ1yKSwl8neivnAh/nO oMpqNIlOD3YTpJGCJxXKpXLOLRKn9gbV9STf8fQ7OH5GdBdIKeJS5zVMxNByCOM/0OWK c6buek/Lq70JTSh0WZ2jZorqjEGOMb802s0ZcqJwRVLB93bLV5nJBAgj4dfCQKp//iBj pnXnQcPXwObGbB+5P631YStuTs3MJpiaCPwpF556UCqVLMNzkPPMLkteO7YF13PMmASs eTXCFfvUKBeXetYNzA1ZZsPjJXpSec0nYBQeXbSBrtkwkgl42VxfYt1EWvJ2oF2CEK2w up0A== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr42573017obv.41.1333009486584; Thu, 29 Mar 2012 01:24:46 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 01:24:46 -0700 (PDT) In-Reply-To: <20120329081625.GA9609@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> Date: Thu, 29 Mar 2012 04:24:46 -0400 X-Google-Sender-Auth: haMAcaQga-hMSrEekw3r0fs422Q Message-ID: From: Christopher Morrow To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:24:48 -0000 On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote: > Jakob, > > On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote: >> Could we not put a freshness indication into the BGP update? >> Then everyone that receives the new update would know to invalidate the = less fresh paths. > > Just to be clear, this is not a route freshness mechanism I am > recommending. =A0What I am recommending is a signal that a repository has > newer data that may be needed for validation. the comment at the mic from Mr Hoffman was interesting to me, potentially signalling via something akin to RSS/Atom, something light weight and simple. -chris > Given such a mechanism, we may be able to reduce the work upon the > repository mirroring system (distributed or not) by not having to regular= ly > poll for new objects frequently unless the repository indicates there is = new > data present. > > -- Jeff > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From joelja@bogus.com Thu Mar 29 01:43:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8287321F876F for ; Thu, 29 Mar 2012 01:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CuhOdONpkXR for ; Thu, 29 Mar 2012 01:43:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC2021F892F for ; Thu, 29 Mar 2012 01:43:25 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2T8hHLM098549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 08:43:19 GMT (envelope-from joelja@bogus.com) Message-ID: <4F7420A4.8070305@bogus.com> Date: Thu, 29 Mar 2012 10:43:16 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 29 Mar 2012 08:43:20 +0000 (UTC) Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:43:29 -0000 On 3/29/12 10:24 , Christopher Morrow wrote: > On Thu, Mar 29, 2012 at 4:16 AM, Jeffrey Haas wrote: >> Jakob, >> >> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote: >>> Could we not put a freshness indication into the BGP update? >>> Then everyone that receives the new update would know to invalidate the less fresh paths. >> >> Just to be clear, this is not a route freshness mechanism I am >> recommending. What I am recommending is a signal that a repository has >> newer data that may be needed for validation. > > the comment at the mic from Mr Hoffman was interesting to me, > potentially signalling via something akin to RSS/Atom, something light > weight and simple. update frequency is in either case the product of the polling interval. if you want to not be dependant on a polling interval one could choose a signaled rather than polled approach. > -chris > >> Given such a mechanism, we may be able to reduce the work upon the >> repository mirroring system (distributed or not) by not having to regularly >> poll for new objects frequently unless the repository indicates there is new >> data present. >> >> -- Jeff >> _______________________________________________ >> 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 > From kent@bbn.com Thu Mar 29 02:16:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6221F8A1F for ; Thu, 29 Mar 2012 02:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QoJACrO6lbO for ; Thu, 29 Mar 2012 02:16:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 829DE21F8A17 for ; Thu, 29 Mar 2012 02:16:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51600 helo=[10.108.69.44]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDBSd-000EdZ-5y; Thu, 29 Mar 2012 05:16:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> Date: Thu, 29 Mar 2012 05:07:38 -0400 To: Shane Amante From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-879109920==_ma============" Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:16:21 -0000 --============_-879109920==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Shane, >To expand on my comments at the mic earlier today on this draft, I >think there is universal acknowledgment that there should be >statements that attacks involving path shortening should be >acknowledged as a "threat" in this document. Section 4.2, near the top of page 12, addresses this attack, in the BGPSEC context: Secure Path Downgrade: A router might remove signatures from a BGPSEC update that it receives, when forwarding this update to a BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec and thus is considered an attack. This is the path shortening attack, expressed in terms of an attack against a BGPSEC-protected path. >OTOH, with respect to path-lengthening, my comment was NOT aimed at >the normal, operation practice of AS_PATH prepending for the >purposes of Traffic Engineering. Section 4.2, bottom of page 11, says: AS Insertion: A router might insert one or more ASNs, other than its own ASN, into an update message. This violates the BGP spec and thus is considered an attack. This seems to address the K/P attack, in the BGPSEC context. >The larger point here is that documenting, preferably in this I-D, >the Kapela/Pilsov threat and other threats related to >upgrade/downgrade threats discussed at the Prague IETF allows us to >more holistically consider whether, or not, BGPSEC addresses it. So, ignoring the "threat" vs. "attack" terminology issue that we discussed at the mic :-), I could add some text to describe classes of attacks in terms of vanilla BGP, as well as BGPSEC. But, RFC 4272 already did this in a fair level of detail, so I didn't see the need for this doc to include an attack enumeration for BGP. When discussing security, it is generally preferable to define what constitutes secure or "correct" operation for a protocol, rather than trying to enumerate attacks against the protocol. If one wants to be more specific, then one can describe classes of attacks, and provide some illustrative examples. That's what we have tried to do here. Not sure I understand you last comment: >d) Further, what if an attacker did this to valid, BGPSEC-signed >paths that he/she was originating and/or receiving and propagating >downstream toward other ASN's? Steve --============_-879109920==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shorten
    Shane,

    To expand on my comments at the mic earlier today on this draft, I think there is universal acknowledgment that there should be statements that attacks involving path shortening should be acknowledged as a "threat" in this document.

    Section 4.2, near the top of page 12,  addresses this attack, in the BGPSEC context:

          Secure Path Downgrade: A router might remove signatures from a
          BGPSEC update that it receives, when forwarding this update to a
          BGPSEC-enabled neighbor.  This behavior violates the BGPSEC spec
          and thus is considered an attack.
    This is the path shortening attack, expressed in terms of an attack against a BGPSEC-protected path.

    OTOH, with respect to path-lengthening, my comment was NOT aimed at the normal, operation practice of AS_PATH prepending for the purposes of Traffic Engineering.

    Section 4.2, bottom of page 11, says:

          AS Insertion: A router might insert one or more ASNs, other than
          its own ASN, into an update message.  This violates the BGP spec
          and thus is considered an attack.
    This seems to address the K/P attack, in the BGPSEC context.

    The larger point here is that documenting, preferably in this I-D, the Kapela/Pilsov threat and other threats related to upgrade/downgrade threats discussed at the Prague IETF allows us to more holistically consider whether, or not, BGPSEC addresses it.

    So, ignoring the "threat" vs. "attack" terminology issue that we discussed at the mic :-), I could add some text to describe classes of attacks in terms of vanilla BGP, as well as BGPSEC.  But, RFC 4272 already did this in a fair level of detail, so I didn't see the need for this doc to include an attack enumeration for BGP.

    When discussing security, it is generally preferable to define what constitutes secure or "correct" operation for a protocol, rather than trying to enumerate attacks against the protocol. If one wants to be more specific, then one can
    describe classes of attacks, and provide some illustrative examples. That's what we have tried to do here.


    Not sure I understand you last comment:

    d)  Further, what if an attacker did this to valid, BGPSEC-signed paths that he/she was originating and/or receiving and propagating downstream toward other ASN's?

    Steve
    --============_-879109920==_ma============-- From sra@hactrn.net Thu Mar 29 02:29:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F9A21F8970; Thu, 29 Mar 2012 02:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.246 X-Spam-Level: X-Spam-Status: No, score=-100.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17AMrrQ4Iyxr; Thu, 29 Mar 2012 02:29:14 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 5B41521F897A; Thu, 29 Mar 2012 02:29:14 -0700 (PDT) Received: from minas-ithil.hactrn.net (ATuileries-151-1-32-98.w82-123.abo.wanadoo.fr [82.123.248.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 83AD628465; Thu, 29 Mar 2012 09:29:11 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 150E66EDFC8; Thu, 29 Mar 2012 11:29:10 +0200 (CEST) Date: Thu, 29 Mar 2012 11:29:10 +0200 From: Rob Austein To: sidr-chairs@ietf.org In-Reply-To: References: <20120312205331.1904.65803.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: <20120329092910.150E66EDFC8@minas-ithil.hactrn.net> Cc: Samuel Weiler , sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:29:15 -0000 At Wed, 28 Mar 2012 08:57:19 -0400, Christopher Morrow wrote: > > Draft Author Ship Steerers, > This we didn't chat about at the meeting(s), but are there outstanding > bits/pieces or should this be sent along for WGLC in the near future? Not ready yet. A few year's experience of using this protocol suggests the need for an additional message type, to let the RPKI engine monitor what the publication server has on file for it. We've seen a few cases where, for whatever reason (bug, system crash, ...) the two can get out of sync, and while it's theoretically possible for the RPKI engine to determine what's in the publication repository by fetching as if it were a relying party, it'd probably be easier just to let the RPKI engine ask the publication server directly. From shares@ndzh.com Thu Mar 29 02:29:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9150221F886E; Thu, 29 Mar 2012 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OJuqv-Djm7x; Thu, 29 Mar 2012 02:29:34 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [63.208.161.199]) by ietfa.amsl.com (Postfix) with ESMTP id A919C21F8970; Thu, 29 Mar 2012 02:29:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.18.145; Received: from SKH2012HPLT (unverified [130.129.18.145]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3214306-1945496 for multiple; Thu, 29 Mar 2012 04:29:28 -0500 From: "Susan Hares" To: "'Jeffrey Haas'" , "'Jakob Heitz'" References: <4F72166F.6080503@raszuk.net> <42776E13-8FFC-485F-8EC2-C93D047C3F6D@tony.li> <4F7229A0.1070109@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3E908892@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD895@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFD924@EUSAACMS0701.eamcs.ericsson.se> <20120328211728.GD16814@slice> In-Reply-To: <20120328211728.GD16814@slice> Date: Thu, 29 Mar 2012 05:29:26 -0400 Message-ID: <00d001cd0d8e$70649710$512dc530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHUVGlAkFUTNdWUzptD3/gnNKFqTQDFVHs7Af0Ug1QCqr2q1AI0RKHPAlc5mOoCBoopmAGbNBMlAbvhU4qV97x08A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, 'Paul Jakma' , 'sidr wg list' Subject: Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:29:34 -0000 Jeff and Jakob: Several people shared the qualm that "AS-SETS" would be necessary. However, Sandy has always posited that aggregation creates a point of change/risk. So, are we just trying to reduce this risk by providing lists of certificates for paths? Or is would an AS-Sets originated at a point in the network - have the security information to consider the existing certificates and generate a valid certificate. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, March 28, 2012 5:17 PM To: Jakob Heitz Cc: idr@ietf.org List; Tony Li; Paul Jakma; Robert Raszuk; sidr wg list Subject: Re: [Idr] [sidr] AS_SET depreciation (RFC6472) and BGP multipath On Wed, Mar 28, 2012 at 10:56:52AM -0400, Jakob Heitz wrote: > The issue is SIDR can not aggregate multiple paths. > > Solutions I can think of: > 1. Aggregate the signatures of the paths being aggregated. What are the semantics you're trying to preserve SIDR-wise? We're hitting the realm where Russ White would point out that BGP path validation can't prove how forwarding works. Presume we managed to pass along two distinct paths for the same multi-path route in BGP. What do you do if one doesn't validate? What do you do if they do, but you think this is a form of a "route leak" for one path? As a receiver of the route that is making use of multipath, you can't selectively choose which sub-paths to take. (It's not like we're gettng something like MPLS entropy labels.) > 2. Don't aggregate, but send both paths. That doesn't cover the actual forwarding semantics. > Should SIDR work on path aggregation? > Are there other possibilities? The biggest problem here is "SIDR secures BGP". The issue hasn't been clear in BGP for years, although I'm perhaps of the cynical opinion that it's been a well understood problem space for a while now. The protocol doesn't reflect what is done operationally. The safe thing operationally when aggregating unsafe paths is to generate sets, but some people have never liked sets. And as I mentioned elsewhere, it doesn't matter as long as you take care in where you redistribute such unsafe multipath. There was a reason I wasn't terribly supportive of the deprecating AS_SETs I-D. However, I also knew it was a losing battle. :-) -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From sra@hactrn.net Thu Mar 29 03:04:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC31721F8939 for ; Thu, 29 Mar 2012 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.246 X-Spam-Level: X-Spam-Status: No, score=-100.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqzSCgk5l4qZ for ; Thu, 29 Mar 2012 03:04:42 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5D21F87E5 for ; Thu, 29 Mar 2012 03:04:41 -0700 (PDT) Received: from minas-ithil.hactrn.net (ATuileries-151-1-32-98.w82-123.abo.wanadoo.fr [82.123.248.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 334D32846B for ; Thu, 29 Mar 2012 10:04:36 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id BBE5A6EE29F for ; Thu, 29 Mar 2012 12:04:34 +0200 (CEST) Date: Thu, 29 Mar 2012 12:04:34 +0200 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> 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: <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:04:43 -0000 At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote: > > i don't think the rsync scale issues surprise anyone that was paying > attention. If we're already considering new architectures, > substrates, et al., here perhaps we shouldn't be so quick on the > trigger for Standards Track work and move this and related > "investigation" to the IRTF, or at least ensure they're only > Experimental until broader experience is gained. If you're talking about moving all of the existing SIDR protocols to Experimental, that's a cheap shot and you know it. Any protocol will behave badly if misused. In my opinion the RIRs are currently using rsync badly, given the way they've chosen to set up their repositories. This is not an inherent property of the protocol, just a bad configuration decision which could be fixed at any time. It may be possible to find or invent better protocols than rsync, but rsync was a reasonable choice for initial deployment. If you're just talking about RPKI over BitTorrent, the BitTorrent experiment was just that, an experiment. The slides say so, and state, in so many words, that this was not a proposal to change the SIDR protocol suite. For the record, this presentation was originally targeted at the IEPG, as a direct follow-up to multiple suggestions received at a previous IEPG meeting that it might be interesting to see how BitTorrent works in this environment. I presented this at the SIDR WG meeting because the chairs thought it might be of interest to the WG. Several other people have made comments which pretty clearly indicate that they either did not read or did not understand the slides. If the former, please do so; if the latter, my apologies, please ask. > Looking at the charts you presented I can only imagine what will > happen with 40K RPs and >1M objects (which might be a reasonable > assumption if this were fully deployed today - and that's only > focusing on routed number resources). Thank you for making my point for me. We can do much better than what we're seeing right now, but the first step is understanding where the problems are, which involves studying behavior and reporting results. This is less likely to happen if every report is viewed as an occasion for an axe-grinding contest, so perhaps we should focus on the technical issues. From randy@psg.com Thu Mar 29 04:41:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50A121F89CB for ; Thu, 29 Mar 2012 04:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxrndEu5vieu for ; Thu, 29 Mar 2012 04:41:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 86E4F21F89C8 for ; Thu, 29 Mar 2012 04:41:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDDjJ-000NO2-4o; Thu, 29 Mar 2012 11:41:25 +0000 Date: Thu, 29 Mar 2012 13:41:23 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120329081625.GA9609@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:41:27 -0000 > Just to be clear, this is not a route freshness mechanism I am > recommending. What I am recommending is a signal that a repository > has newer data that may be needed for validation. Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides such a mechanism randy From rogaglia@cisco.com Thu Mar 29 04:51:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8F221F88AF for ; Thu, 29 Mar 2012 04:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-WcL17H4r5C for ; Thu, 29 Mar 2012 04:51:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id F22AF21F87B1 for ; Thu, 29 Mar 2012 04:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7682; q=dns/txt; s=iport; t=1333021868; x=1334231468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uWexYxeRmAom7Pu4edgk7l/QLA4Xmll7ZgBLQjwIMqY=; b=OWG8+tijidAQlVlhFJQybwa9sYKuabyN6kgNcwjhxSu8LhSse5hZN0ao wSow14xCM9ESIVwVQPkgI2C9XJ5BtVC6TtF432hzD5SHms6TJctGmqq70 wx7OacizWwjHYBJ5jYqyx14/8x2n6CL1rxVXJGA2l+fgMHXAJ6yIhTCod 4=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPBLdE+rRDoH/2dsb2JhbABEuQ+BB4IJAQEBAwEBAQEPAVsLBQsCAQhGAiULJQIEDgUOFIdjBAELm2efHQSQPGMEjmiBIoVXjkWBaIJn X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="p7s'?scan'208";a="35075910" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Mar 2012 11:51:08 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBp8tU023335; Thu, 29 Mar 2012 11:51:08 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 04:51:08 -0700 From: "Roque Gagliano (rogaglia)" To: "Murphy, Sandra" Thread-Topic: [sidr] remote participation experience today Thread-Index: AQHNDaI1ummgnXfOvUeFpNJD54OHdw== Date: Thu, 29 Mar 2012 11:51:07 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18804.006 x-tm-as-result: No--34.455000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-184-379864185"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] remote participation experience today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:51:10 -0000 --Apple-Mail-184-379864185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sandra, I attend the meeting remotely on both Monday and Wednesday. I did not = feel the need for Webex as the audio streaming + jabber worked just = fine.=20 My only comment is to re-emphasize what was mentioned by Wes on the = jabber room, please request including page numbers on presentation decks = to facilitate the remote experience. Roque. On Mar 28, 2012, at 3:42 PM, Murphy, Sandra wrote: > The webex session on Monday failed completely, due to laptop wireless = incapability to maintain a connection (20-50-80-100% packet loss). >=20 > The webex session on Wednesday (this morning) seemed to work = (alternate networking arranged). >=20 > But being the presentation laptop for webex, I was unable to see who = (if any) the participants were. >=20 > If you joined the webex session today, PLEASE do comment on the list = of what you found worked or did not work for that experience. (Was your = view of slides keeping up? were you listenting to webex telecon or to = ietf audio stream? could you follow the discussion amongst those in the = room? audio quality? etc.) >=20 > It would help in figuring out the future virtual meetings. >=20 > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-184-379864185 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAz MjkxMTUxMDZaMCMGCSqGSIb3DQEJBDEWBBR/if9OlRYwzeziJ7pCWkWMKZvHUDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCRkP3o+ah1NVAQsT3HTpvDHKhLA/pDtO65UrZA9hOFsz4/ FSo5aP5uAF9F11lX2OJgbB8KzLs4Yjk6O1h7cXDKHyNzBEwc70ytlrMKjFlzHMvnPlejILyxLRXT 1w770Vx/x1Ib6EswQiP914rrz/tx6H68uC+FTovRI3LB+U4nuzjZ4oYGfNWmYxr3p/S+eTWqML24 ookiz/ddzFfrCOw2gAO344NdbFqnj8uOvN3pTTqbY3U3S52i3WJhaomi9unL1Xucd3bbDlAq+pzj gc8InRDdcMTjev8jkmbiKfmYfumIkzbcyAjawfaZW1F4hp7eQnaF0+Ii7D+VNGjJ1ZlCAAAAAAAA --Apple-Mail-184-379864185-- From jhaas@slice.pfrc.org Thu Mar 29 04:57:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ED421F8604 for ; Thu, 29 Mar 2012 04:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyDCpwUTvDsj for ; Thu, 29 Mar 2012 04:57:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6021F85CE for ; Thu, 29 Mar 2012 04:57:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CC78717042B; Thu, 29 Mar 2012 07:57:14 -0400 (EDT) Date: Thu, 29 Mar 2012 07:57:14 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20120329115714.GA18393@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:57:16 -0000 Randy, On Thu, Mar 29, 2012 at 01:41:23PM +0200, Randy Bush wrote: > > Just to be clear, this is not a route freshness mechanism I am > > recommending. What I am recommending is a signal that a repository > > has newer data that may be needed for validation. > > Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides such > a mechanism Not what I'm talking about. What notifies a cache that it needs to fetch new objects from a RPKI repository? As best I understood, it's largely done on cron jobs now. I could readily see a BGP signaled "This AS has a manifest with a newer serial number" being passed back to rpki-rtr so that it could kick off rsync (or whatever). -- Jeff From randy@psg.com Thu Mar 29 05:01:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67EF21F8A26 for ; Thu, 29 Mar 2012 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0su1YKz-626 for ; Thu, 29 Mar 2012 05:01:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7421F8A23 for ; Thu, 29 Mar 2012 05:01:26 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDE2f-000NRo-I5; Thu, 29 Mar 2012 12:01:25 +0000 Date: Thu, 29 Mar 2012 14:01:24 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120329115714.GA18393@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:01:27 -0000 >> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides >> such a mechanism > Not what I'm talking about. > > What notifies a cache that it needs to fetch new objects from a RPKI > repository? As best I understood, it's largely done on cron jobs now. ahh. yes. if we do a next-gen rpki flooding mechanism, that would be a good addition. > I could readily see a BGP signaled "This AS has a manifest with a > newer serial number" being passed back to rpki-rtr so that it could > kick off rsync (or whatever). to a bgp hacker everything looks like a nail, eh? how about a sip notification? :) randy From jhaas@slice.pfrc.org Thu Mar 29 05:18:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE42D21F86AF for ; Thu, 29 Mar 2012 05:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSz6BB4-ondu for ; Thu, 29 Mar 2012 05:18:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 68C2221F86AA for ; Thu, 29 Mar 2012 05:18:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 34A0A170414; Thu, 29 Mar 2012 08:18:24 -0400 (EDT) Date: Thu, 29 Mar 2012 08:18:24 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20120329121824.GB18393@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:18:25 -0000 On Thu, Mar 29, 2012 at 02:01:24PM +0200, Randy Bush wrote: > ahh. yes. if we do a next-gen rpki flooding mechanism, that would be a > good addition. Agreed. It certainly belongs in there. > to a bgp hacker everything looks like a nail, eh? how about a sip > notification? :) Just a minor correction: To a BGP hacker, every solution looks like a baby seal. If you'd like to do the distribution of bgp path security state in SIP, I'm happy to review the document. There's at least 2 days before it'd need to be published. -- Jeff From Sandra.Murphy@sparta.com Thu Mar 29 05:54:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95A521F8AD5 for ; Thu, 29 Mar 2012 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76MwRmJYqeGt for ; Thu, 29 Mar 2012 05:54:13 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9C721F8AD4 for ; Thu, 29 Mar 2012 05:54:13 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2TCsCdc002743; Thu, 29 Mar 2012 07:54:12 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2TCsBBO008743; Thu, 29 Mar 2012 07:54:11 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 08:54:11 -0400 From: "Murphy, Sandra" To: Danny McPherson , sidr wg list Thread-Topic: [sidr] Slides for "RPKI Over BitTorrent" presentation Thread-Index: AQHNC3aMKgfPiAS3J0C3Tp5xvVBeQZaAszoAgACBz0M= Date: Thu, 29 Mar 2012 12:54:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CBB6E@Hermes.columbia.ads.sparta.com> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:54:14 -0000 >i don't think the rsync scale issues surprise anyone that was paying atten= tion. =0A= =0A= I am not sure what part of the presentation you are talking about. In the = "day in the life" presentation, I saw only differences due to implementatio= n, not differences due to scale.=0A= =0A= And in the "rpki over bittorrent" presentation, the point was made that the= implementation choice creates performance differences.=0A= =0A= >perhaps we shouldn't be so quick on the trigger for Standards Track work a= nd move this and related "investigation" to the IRTF, or at least ensure th= ey're only Experimental until broader experience is gained.=0A= =0A= There's a process in the IETF for protocols to go from Proposed to full sta= ndard as lessons are learned from operational experience. The progress th= rough maturity levels is a fundamental part of the IETF process. You seem = to suggest that new protocols should start out in Experimental "until broad= er experience is gained" - perhaps you should suggest an IETF process chang= e.=0A= =0A= Having one protocol for everyone to use was necessary for interoperability = and rsync was chosen as the MTI. Again, typical IETF process.=0A= =0A= >Looking at the charts you presented I can only imagine what will happen wi= th 40K RPs and >1M objects (which might be a reasonable assumption if this = were fully deployed today - and that's only focusing on routed number resou= rces).=0A= =0A= I don't imagine that 40K relying parties or even full certification will be= any time soon. In the meantime we have a MTI protocol for interop. And t= he architecture is extensible so that other transports could be introduced = as deemed necessary from experience.=0A= =0A= Don't worry so much. The sky is not falling here.=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Wednesday, March 28, 2012 8:33 PM=0A= To: sidr wg list=0A= Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation=0A= =0A= If we're already considering new architectures, substrates, et al., here pe= rhaps we shouldn't be so quick on the trigger for Standards Track work and = move this and related "investigation" to the IRTF, or at least ensure they'= re only Experimental until broader experience is gained.=0A= =0A= Looking at the charts you presented I can only imagine what will happen wit= h 40K RPs and >1M objects (which might be a reasonable assumption if this w= ere fully deployed today - and that's only focusing on routed number resour= ces).=0A= =0A= -danny=0A= =0A= =0A= On Mar 26, 2012, at 1:33 PM, Rob Austein wrote:=0A= =0A= > For those who didn't get to see the end of the "RPKI Over BitTorrent"=0A= > presentation in today's SIDR meeting, the full slide deck is available=0A= > at=0A= >=0A= > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf=0A= >=0A= > and should be relatively self-explanatory.=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From shane@castlepoint.net Thu Mar 29 06:04:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E416521F8993 for ; Thu, 29 Mar 2012 06:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLRKa4hp13on for ; Thu, 29 Mar 2012 06:04:38 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id A48FC21F8986 for ; Thu, 29 Mar 2012 06:04:29 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 35547268063; Thu, 29 Mar 2012 07:04:29 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 29 Mar 2012 07:04:28 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54011; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_3A651CA3-A674-4267-93F1-4D8CDE7A503C" From: Shane Amante In-Reply-To: Date: Thu, 29 Mar 2012 15:04:25 +0200 Message-Id: <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> To: Stephen Kent X-Mailer: Apple Mail (2.1257) Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:04:40 -0000 --Apple-Mail=_3A651CA3-A674-4267-93F1-4D8CDE7A503C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steve, Thanks for the response. First, a high-level comment before more = specific responses below. =20 The challenge I'm having is trying to reconcile threats against the = existing AS4_PATH attribute vs. threats against the BGP_Path_Signature = attribute. More specifically, the AS4_PATH attribute is used by the BGP = protocol for loop detection, (i.e.: if I find my own ASN in the = AS4_PATH, today, then I drop the route because the BGP protocol = considers that a routing information loop). So, the question is: = if/when BGPSEC is deployed, will BGP be expected to perform this loop = detection check on the AS4_PATH attribute /prior/ to verification of the = BGPSEC_Path_Signature attribute or after? If it's before, then there's = the potential for someone to forge a AS4_PATH attribute to cause a = receiver to drop a BGP UPDATE causing a DoS attack. OTOH, if loop = detection is after verification of the BGPSEC_Path_Signature attribute, = then this may be another form of DoS attack, given that the UPDATE needs = to be run through crypto processors, (which like general purpose CPU's = have a finite # of Ops/sec they can run), to check the = BGPSEC_Path_Signature validity before going through protocol correctness = checks on AS4_PATH attribute. There may be a third answer, which is = that the SIDR WG will deprecate the AS4_PATH attribute and replace it = with the BGPSEC_Path_Signatures attribute, but even in this case I think = the same two choices I just outlined need to be decided upon. I don't see an easy answer here; however, I suspect that from a security = PoV, there is likely a "preference" to verify the BGPSEC_Path_Signature = attribute, first, before running protocol correctness checks (loop = avoidance), which may result in the threat of a DoS. Regardless, I = think that its best to acknowledge, in this draft, that there is a = threat of DoS to the availability of the BGP control plane and/or to the = feasibility of unvalidated paths carried in the control plane, (until = they are later, perhaps "lazily", validated via a background process). Please see below. On Mar 29, 2012, at 11:07 AM, Stephen Kent wrote: > Shane, >=20 >> To expand on my comments at the mic earlier today on this draft, I = think there is universal acknowledgment that there should be statements = that attacks involving path shortening should be acknowledged as a = "threat" in this document. >=20 > Section 4.2, near the top of page 12, addresses this attack, in the = BGPSEC context: >=20 > Secure Path Downgrade: A router might remove signatures from a > BGPSEC update that it receives, when forwarding this update to a > BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec > and thus is considered an attack. > This is the path shortening attack, expressed in terms of an attack = against a BGPSEC-protected path. I suspect that this, and other, text was written a little while ago when = there was a much tighter coupling of the AS4_PATH attribute & the = proposed BGPSEC_Path_Signature attribute. However, given recent = discussions around (ab)using pCount =3D 0 for Route Servers at IX'es, = ASN migrations, etc., then perhaps Section 4.2 of this draft should be = revisited in light of whether the BGP Path Selection algorithm is going = to use data from the AS4_PATH attribute, at all, (even after = verification of the BGPSEC_Path_Attribute) and the potential for various = DoS threats that /may/ have wrt availability vs. validity of = reachability ... >> OTOH, with respect to path-lengthening, my comment was NOT aimed at = the normal, operation practice of AS_PATH prepending for the purposes of = Traffic Engineering. >=20 > Section 4.2, bottom of page 11, says: >=20 > AS Insertion: A router might insert one or more ASNs, other than > its own ASN, into an update message. This violates the BGP spec > and thus is considered an attack. > This seems to address the K/P attack, in the BGPSEC context. Same comment as above. At a minimum, can the above text be more clear = on whether those statements are in relation to the AS4_PATH attribute or = BGPSEC_Path_Attributes attribute, or both? >> The larger point here is that documenting, preferably in this I-D, = the Kapela/Pilsov threat and other threats related to upgrade/downgrade = threats discussed at the Prague IETF allows us to more holistically = consider whether, or not, BGPSEC addresses it. >=20 > So, ignoring the "threat" vs. "attack" terminology issue that we = discussed at the mic :-), I could add some text to describe classes of = attacks in terms of vanilla BGP, as well as BGPSEC. But, RFC 4272 = already did this in a fair level of detail, so I didn't see the need for = this doc to include an attack enumeration for BGP. >=20 > When discussing security, it is generally preferable to define what = constitutes secure or "correct" operation for a protocol, rather than = trying to enumerate attacks against the protocol. If one wants to be = more specific, then one can > describe classes of attacks, and provide some illustrative examples. = That's what we have tried to do here. Understood.=20 > Not sure I understand you last comment: >=20 >> d) Further, what if an attacker did this to valid, BGPSEC-signed = paths that he/she was originating and/or receiving and propagating = downstream toward other ASN's? There is text about MITM threat in Section 4.2; however, that seems to = relate to crypto security between two adjacent routers over, say, a = directly connected link. However, what about MITM attacks that create = what appear to be valid BGPSEC_Path_Signature attribute that would pass = verification by downstream parties? Thanks, -shane= --Apple-Mail=_3A651CA3-A674-4267-93F1-4D8CDE7A503C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


    Please see = below.

    On Mar 29, 2012, at 11:07 AM, Stephen = Kent wrote:

    Section 4.2, = near the top of page 12,  addresses this attack, in the BGPSEC = context:

          Secure Path Downgrade: = A router might remove signatures from = a
          BGPSEC update that it receives, when = forwarding this update to a
          = BGPSEC-enabled neighbor.  This behavior violates the BGPSEC = spec
          and thus is considered = an attack.
    This is the path shortening attack, = expressed in terms of an attack against a BGPSEC-protected = path.

    I suspect that = this, and other, text was written a little while ago when there was a = much tighter coupling of the AS4_PATH attribute & the proposed = BGPSEC_Path_Signature attribute.  However, given recent discussions = around (ab)using pCount =3D 0 for Route Servers at IX'es, ASN = migrations, etc., then perhaps Section 4.2 of this draft should be = revisited in light of whether the BGP Path Selection algorithm is going = to use data from the AS4_PATH attribute, at all, (even after = verification of the BGPSEC_Path_Attribute) and the potential for various = DoS threats that /may/ have wrt availability vs. validity of = reachability ...


    OTOH, with respect to = path-lengthening, my comment was NOT aimed at the normal, operation = practice of AS_PATH prepending for the purposes of Traffic = Engineering.

    Section 4.2, bottom of page = 11, says:

          AS Insertion: A router = might insert one or more ASNs, other = than
          its own ASN, into an update = message.  This violates the BGP spec
          and thus is considered = an attack.
    This seems to address the K/P = attack, in the BGPSEC = context.

    Same comment as = above.  At a minimum, can the above text be more clear on whether = those statements are in relation to the AS4_PATH attribute or = BGPSEC_Path_Attributes attribute, or = both?


    The larger point here = is that documenting, preferably in this I-D, the Kapela/Pilsov threat = and other threats related to upgrade/downgrade threats discussed at the = Prague IETF allows us to more holistically consider whether, or not, = BGPSEC addresses it.

    So, ignoring the = "threat" vs. "attack" terminology issue that we discussed at the mic = :-), I could add some text to describe classes of attacks in terms of = vanilla BGP, as well as BGPSEC.  But, RFC 4272 already did this in = a fair level of detail, so I didn't see the need for this doc to include = an attack enumeration for BGP.

    When discussing = security, it is generally preferable to define what constitutes secure = or "correct" operation for a protocol, rather than trying to enumerate = attacks against the protocol. If one wants to be more specific, then one = can
    describe classes of attacks, and provide some illustrative = examples. That's what we have tried to do = here.

    Understood. 


    Not sure I understand = you last comment:d)  Further, what = if an attacker did this to valid, BGPSEC-signed paths that he/she was = originating and/or receiving and propagating downstream toward other = ASN's?

    There is = text about MITM threat in Section 4.2; however, that seems to relate to = crypto security between two adjacent routers over, say, a directly = connected link.  However, what about MITM attacks that create what = appear to be valid BGPSEC_Path_Signature attribute that would pass = verification by downstream = parties?

    Thanks,

    -= shane
    = --Apple-Mail=_3A651CA3-A674-4267-93F1-4D8CDE7A503C-- From danny@tcb.net Thu Mar 29 06:07:33 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6065621F88C8 for ; Thu, 29 Mar 2012 06:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg2nwKBWdrOA for ; Thu, 29 Mar 2012 06:07:32 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id AB19821F884E for ; Thu, 29 Mar 2012 06:07:32 -0700 (PDT) Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id 73C1E26800D for ; Thu, 29 Mar 2012 07:07:32 -0600 (MDT) Received: from 216.168.230.7 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Thu, 29 Mar 2012 09:07:32 -0400 (EDT) Message-ID: <7812.216.168.230.7.1333026452.squirrel@webmail.tcb.net> In-Reply-To: <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> Date: Thu, 29 Mar 2012 09:07:32 -0400 (EDT) From: "Danny McPherson" To: sidr@ietf.org User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: danny@tcb.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:07:33 -0000 > At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote: > > If you're talking about moving all of the existing SIDR protocols to > Experimental, that's a cheap shot and you know it. I didn't say that. > If you're just talking about RPKI over BitTorrent, the BitTorrent > experiment was just that, an experiment. The slides say so, and > state, in so many words, that this was not a proposal to change the > SIDR protocol suite. I actually agree with the premise here, that there are scale and freshness and distribution issues in the current model that need to be worked out. > Thank you for making my point for me. We can do much better than what > we're seeing right now, but the first step is understanding where the > problems are, which involves studying behavior and reporting results. > This is less likely to happen if every report is viewed as an occasion > for an axe-grinding contest, so perhaps we should focus on the > technical issues. This is not "axe grinding". These designs are likely to considerably influence how networks and routing architectures and support systems are designed and operated - in the real world, not in a lab or 'pilot'. I'd like to get this right as much as you would (moreso, because my $dayjob relies on it), and that should encourage us to fully understand the long-term desirable objectives before stepping on the accelerator for full standardization. Whatever we design today should at least be able to accommodate full deployment in the current system (even when focusing on *routed* resource certification), which given the data you've presented at the past coupled meetings it's already strained and there appears to be a disconnect between those designing the RPKI and the initial folks captive to operationalizing it (e.g., the RIRs). Out of curiosity, what were the initial design / scale goals of the RPKI team for aggregate object count, frequency of publication and access by RPs? -danny From jakob.heitz@ericsson.com Thu Mar 29 06:47:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551D21F8792 for ; Thu, 29 Mar 2012 06:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1iAS0LVVqvP for ; Thu, 29 Mar 2012 06:47:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D96BA21F8781 for ; Thu, 29 Mar 2012 06:47:08 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2TDkao2014424; Thu, 29 Mar 2012 08:46:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 29 Mar 2012 09:46:36 -0400 From: Jakob Heitz To: Shane Amante , Stephen Kent Date: Thu, 29 Mar 2012 09:46:35 -0400 Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening Thread-Index: Ac0NrIU6cOVSY2FNQvy4/3XlMZDEXwABTsTQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9@EUSAACMS0701.eamcs.ericsson.se> References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> In-Reply-To: <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9EUSAACMS0701e_" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:47:10 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's just require that BGPSEC capable routers also support 4 byte AS. Then we don't need to worry about AS4_PTH. -- Jakob Heitz. ________________________________ From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Thursday, March 29, 2012 6:04 AM To: Stephen Kent Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & le= ngthening Steve, Thanks for the response. First, a high-level comment before more specific = responses below. The challenge I'm having is trying to reconcile threats against the existin= g AS4_PATH attribute vs. threats against the BGP_Path_Signature attribute. = More specifically, the AS4_PATH attribute is used by the BGP protocol for = loop detection, (i.e.: if I find my own ASN in the AS4_PATH, today, then I = drop the route because the BGP protocol considers that a routing informatio= n loop). So, the question is: if/when BGPSEC is deployed, will BGP be expe= cted to perform this loop detection check on the AS4_PATH attribute /prior/= to verification of the BGPSEC_Path_Signature attribute or after? If it's = before, then there's the potential for someone to forge a AS4_PATH attribut= e to cause a receiver to drop a BGP UPDATE causing a DoS attack. OTOH, if = loop detection is after verification of the BGPSEC_Path_Signature attribute= , then this may be another form of DoS attack, given that the UPDATE needs = to be run through crypto processors, (which like general purpose CPU's have= a finite # of Ops/sec they can run), to check the BGPSEC_Path_Signature va= lidity before going through protocol correctness checks on AS4_PATH attribu= te. There may be a third answer, which is that the SIDR WG will deprecate = the AS4_PATH attribute and replace it with the BGPSEC_Path_Signatures attri= bute, but even in this case I think the same two choices I just outlined ne= ed to be decided upon. I don't see an easy answer here; however, I suspect that from a security Po= V, there is likely a "preference" to verify the BGPSEC_Path_Signature attri= bute, first, before running protocol correctness checks (loop avoidance), w= hich may result in the threat of a DoS. Regardless, I think that its best = to acknowledge, in this draft, that there is a threat of DoS to the availab= ility of the BGP control plane and/or to the feasibility of unvalidated pat= hs carried in the control plane, (until they are later, perhaps "lazily", v= alidated via a background process). Please see below. On Mar 29, 2012, at 11:07 AM, Stephen Kent wrote: Shane, To expand on my comments at the mic earlier today on this draft, I think th= ere is universal acknowledgment that there should be statements that attack= s involving path shortening should be acknowledged as a "threat" in this do= cument. Section 4.2, near the top of page 12, addresses this attack, in the BGPSEC= context: Secure Path Downgrade: A router might remove signatures from a BGPSEC update that it receives, when forwarding this update to a BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec and thus is considered an attack. This is the path shortening attack, expressed in terms of an attack against= a BGPSEC-protected path. I suspect that this, and other, text was written a little while ago when th= ere was a much tighter coupling of the AS4_PATH attribute & the proposed BG= PSEC_Path_Signature attribute. However, given recent discussions around (a= b)using pCount =3D 0 for Route Servers at IX'es, ASN migrations, etc., then= perhaps Section 4.2 of this draft should be revisited in light of whether = the BGP Path Selection algorithm is going to use data from the AS4_PATH att= ribute, at all, (even after verification of the BGPSEC_Path_Attribute) and = the potential for various DoS threats that /may/ have wrt availability vs. = validity of reachability ... OTOH, with respect to path-lengthening, my comment was NOT aimed at the nor= mal, operation practice of AS_PATH prepending for the purposes of Traffic E= ngineering. Section 4.2, bottom of page 11, says: AS Insertion: A router might insert one or more ASNs, other than its own ASN, into an update message. This violates the BGP spec and thus is considered an attack. This seems to address the K/P attack, in the BGPSEC context. Same comment as above. At a minimum, can the above text be more clear on w= hether those statements are in relation to the AS4_PATH attribute or BGPSEC= _Path_Attributes attribute, or both? The larger point here is that documenting, preferably in this I-D, the Kape= la/Pilsov threat and other threats related to upgrade/downgrade threats dis= cussed at the Prague IETF allows us to more holistically consider whether, = or not, BGPSEC addresses it. So, ignoring the "threat" vs. "attack" terminology issue that we discussed = at the mic :-), I could add some text to describe classes of attacks in ter= ms of vanilla BGP, as well as BGPSEC. But, RFC 4272 already did this in a = fair level of detail, so I didn't see the need for this doc to include an a= ttack enumeration for BGP. When discussing security, it is generally preferable to define what constit= utes secure or "correct" operation for a protocol, rather than trying to en= umerate attacks against the protocol. If one wants to be more specific, the= n one can describe classes of attacks, and provide some illustrative examples. That's= what we have tried to do here. Understood. Not sure I understand you last comment: d) Further, what if an attacker did this to valid, BGPSEC-signed paths tha= t he/she was originating and/or receiving and propagating downstream toward= other ASN's? There is text about MITM threat in Section 4.2; however, that seems to rela= te to crypto security between two adjacent routers over, say, a directly co= nnected link. However, what about MITM attacks that create what appear to = be valid BGPSEC_Path_Signature attribute that would pass verification by do= wnstream parties? Thanks, -shane --_000_7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Let's just require that BG= PSEC=20 capable routers
    also support 4 byte AS. Th= en we don't=20 need to worry
    about AS4_PTH.

    --
    Jakob Heitz.

     

    From: sidr-bounces@ietf.org=20 [mailto:sidr-bounces@ietf.org] On Behalf Of Shane Amante
    Sent:= =20 Thursday, March 29, 2012 6:04 AM
    To: Stephen Kent
    Cc: s= idr=20 wg list
    Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Pa= th=20 shortening & lengthening

    Steve,

    Thanks for the response.  First, a high-level comment before more= =20 specific responses below.  

    The challenge I'm having is trying to reconcile threats against the=20 existing AS4_PATH attribute vs. threats against the BGP_Path_Signature=20 attribute.  More specifically, the AS4_PATH attribute is used by the B= GP=20 protocol for loop detection, (i.e.: if I find my own ASN in the AS4_PATH, t= oday,=20 then I drop the route because the BGP protocol considers that a routing=20 information loop).  So, the question is: if/when BGPSEC is deployed, w= ill=20 BGP be expected to perform this loop detection check on the AS4_PATH attrib= ute=20 /prior/ to verification of the BGPSEC_Path_Signature attribute or after?=20  If it's before, then there's the potential for someone to forge a AS4= _PATH=20 attribute to cause a receiver to drop a BGP UPDATE causing a DoS attack.=20  OTOH, if loop detection is after verification of the BGPSEC_Path_Sign= ature=20 attribute, then this may be another form of DoS attack, given that the UPDA= TE=20 needs to be run through crypto processors, (which like general purpose CPU'= s=20 have a finite # of Ops/sec they can run), to check the BGPSEC_Path_Signatur= e=20 validity before going through protocol correctness checks on AS4_PATH attri= bute.=20  There may be a third answer, which is that the SIDR WG will deprecate= the=20 AS4_PATH attribute and replace it with the BGPSEC_Path_Signatures attribute= , but=20 even in this case I think the same two choices I just outlined need to be=20 decided upon.

    I don't see an easy answer here; however, I suspect that from a securi= ty=20 PoV, there is likely a "preference" to verify the BGPSEC_Path_Signature=20 attribute, first, before running protocol correctness checks (loop avoidanc= e),=20 which may result in the threat of a DoS.  Regardless, I think that its= best=20 to acknowledge, in this draft, that there is a threat of DoS to the availab= ility=20 of the BGP control plane and/or to the feasibility of unvalidated paths car= ried=20 in the control plane, (until they are later, perhaps "lazily", validated vi= a a=20 background process).


    Please see below.

    On Mar 29, 2012, at 11:07 AM, Stephen Kent wrote:
    Shane,

    To expand on my comments at the mic earlier today on this d= raft,=20 I think there is universal acknowledgment that there should be statemen= ts=20 that attacks involving path shortening should be acknowledged as a "thr= eat"=20 in this document.

    Section 4.2, near the top of page 12,  addresses this attack, i= n the=20 BGPSEC context:

       &nb= sp; =20 Secure Path Downgrade: A router might remove signatures from=20 a
          BGPSEC update that it receives, when= =20 forwarding this update to a
          BGPSEC-enab= led=20 neighbor.  This behavior violates the BGPSEC spec
       &nb= sp; =20 and thus is considered an attack.
    This is the path shortening attack, expressed in terms of an attack= =20 against a BGPSEC-protected path.

    I suspect that this, and other, text was written a little while ago wh= en=20 there was a much tighter coupling of the AS4_PATH attribute & the propo= sed=20 BGPSEC_Path_Signature attribute.  However, given recent discussions ar= ound=20 (ab)using pCount =3D 0 for Route Servers at IX'es, ASN migrations, etc., th= en=20 perhaps Section 4.2 of this draft should be revisited in light of whet= her=20 the BGP Path Selection algorithm is going to use data from the AS4_PATH=20 attribute, at all, (even after verification of the BGPSEC_Path_Attribute) a= nd=20 the potential for various DoS threats that /may/ have wrt availability vs.= =20 validity of reachability ...


    OTOH, with respect to path-lengthening, my comment was NOT = aimed=20 at the normal, operation practice of AS_PATH prepending for the purpose= s of=20 Traffic Engineering.

    Section 4.2, bottom of page 11, says:

       &nb= sp; =20 AS Insertion: A router might insert one or more ASNs, other=20 than
          its own ASN, into an update=20 message.  This violates the BGP spec
       &nb= sp; =20 and thus is considered an attack.
    This seems to address the K/P attack, in the BGPSEC=20 context.

    Same comment as above.  At a minimum, can the above tex= t be=20 more clear on whether those statements are in relation to the AS4_PATH attr= ibute=20 or BGPSEC_Path_Attributes attribute, or both?


    The larger point here is that documenting, preferably in th= is=20 I-D, the Kapela/Pilsov threat and other threats related to upgrade/down= grade=20 threats discussed at the Prague IETF allows us to more holistically con= sider=20 whether, or not, BGPSEC addresses it.

    So, ignoring the "threat" vs. "attack" terminology issue that we=20 discussed at the mic :-), I could add some text to describe classes of at= tacks=20 in terms of vanilla BGP, as well as BGPSEC.  But, RFC 4272 already d= id=20 this in a fair level of detail, so I didn't see the need for this doc to= =20 include an attack enumeration for BGP.

    When discussing security, it is generally preferable to define what= =20 constitutes secure or "correct" operation for a protocol, rather than try= ing=20 to enumerate attacks against the protocol. If one wants to be more specif= ic,=20 then one can
    describe classes of attacks, and provide some illustrative examples.= =20 That's what we have tried to do here.

    Understood. 


    Not sure I understand you last comment:

    d)  Further, what if an attacker did this to valid,=20 BGPSEC-signed paths that he/she was originating and/or receiving and=20 propagating downstream toward other=20 ASN's?

    There is text about MITM threat in Section 4.2; however, that seems to= =20 relate to crypto security between two adjacent routers over, say, a directl= y=20 connected link.  However, what about MITM attacks that create what app= ear=20 to be valid BGPSEC_Path_Signature attribute that would pass verification by= =20 downstream parties?

    Thanks,

    -shane
    --_000_7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9EUSAACMS0701e_-- From randy@psg.com Thu Mar 29 07:06:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B2921F8B39 for ; Thu, 29 Mar 2012 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vfn6ruD6aBv for ; Thu, 29 Mar 2012 07:06:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 96EA021F8B0E for ; Thu, 29 Mar 2012 07:06:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDFzO-000Nof-0N; Thu, 29 Mar 2012 14:06:10 +0000 Date: Thu, 29 Mar 2012 16:06:08 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20120329121824.GB18393@slice> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> User-Agent: Wanderlust/2.15.9 (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 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:06:16 -0000 just a note at the high level o anyone who thinks rsync is not gonna do well for the scaling we are likely to see in the next year+ is smoking some strong optimism. we're only at 5k objects today, three months into the game. o but we do not know the long term scaling characteristics of the current rsync scheme. http etc are not likely to scale any better. o we could get much better rsync performance with a trivial change at the rirs. o we are currently constructing some measurement experiments. on the order of 500k to 1m roas. we need some points on the curve not bs and fud in powerpoint. o we are already playing with a bittorrent experiment for a number of reasons, mainly because its model is so different. you have seen the initial results. the code is open. o but we are suspicions and curious creatures, so folk are already discussing mechanisms for v2, mechanism agility, ... to be deployed in a year or three. we now return you to the ppt and fud channel of your choice. but i am sure the channel will be transported over dns and bgp. :) randy From andrew.lange@alcatel-lucent.com Thu Mar 29 07:14:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1B721E803C for ; Thu, 29 Mar 2012 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiYNBzU-Letx for ; Thu, 29 Mar 2012 07:14:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AB11521E8124 for ; Thu, 29 Mar 2012 07:14:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2TEEr3x016192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2012 09:14:54 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2TEEr8Y000685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 09:14:53 -0500 Received: from pcp513229pcs.fr.alcatel-lucent.com (135.3.62.245) by USNAVSXCHHUB03.ndc.alcatel-lucent.com (135.3.39.112) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 29 Mar 2012 09:14:52 -0500 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Andrew Lange In-Reply-To: Date: Thu, 29 Mar 2012 07:14:49 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <2115D420-FF6A-4753-80DA-090C99FA47B2@alcatel-lucent.com> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:14:56 -0000 On Mar 29, 2012, at 5:01 AM, Randy Bush wrote: >>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides >>> such a mechanism >> Not what I'm talking about. >>=20 >> What notifies a cache that it needs to fetch new objects from a RPKI >> repository? As best I understood, it's largely done on cron jobs = now. >=20 > ahh. yes. if we do a next-gen rpki flooding mechanism, that would be = a > good addition. What about an XMPP-based PUSH service? The local cache can subscribe, = and get info pushed when it comes out (modulo a small delay).=20 Andrew >=20 >> I could readily see a BGP signaled "This AS has a manifest with a >> newer serial number" being passed back to rpki-rtr so that it could >> kick off rsync (or whatever). >=20 > to a bgp hacker everything looks like a nail, eh? how about a sip > notification? :) >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Thu Mar 29 07:24:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F76421E80B2 for ; Thu, 29 Mar 2012 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLVxKzvgQKUd for ; Thu, 29 Mar 2012 07:24:03 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6409421E8124 for ; Thu, 29 Mar 2012 07:23:55 -0700 (PDT) Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id DA8E126800D for ; Thu, 29 Mar 2012 08:23:54 -0600 (MDT) Received: from 216.168.230.7 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Thu, 29 Mar 2012 10:23:54 -0400 (EDT) Message-ID: <27610.216.168.230.7.1333031034.squirrel@webmail.tcb.net> In-Reply-To: References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> Date: Thu, 29 Mar 2012 10:23:54 -0400 (EDT) From: "Danny McPherson" To: "sidr wg list" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: danny@tcb.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:24:04 -0000 > o but we do not know the long term scaling characteristics of the > current rsync scheme. While we may not know the scaling characteristics of the solution, do we at least know what would be a desirable objective target for sustainable deployment? > o we could get much better rsync performance with a trivial change at > the rids. Does "much better" accommodate our desired engineering targets for long-term? What are those? > o we are already playing with a bittorrent experiment for a number of > reasons, mainly because its model is so different. you have seen > the initial results. the code is open. Twitter may be more real-time (only half kidding :-) > o but we are suspicions and curious creatures, so folk are already > discussing mechanisms for v2, mechanism agility, ... to be deployed > in a year or three. Again, if we're engineering here for the future and stable standards then what are the desirable long-term system scale objectives for the RPKI? I think this is a pretty reasonable question - when this is fully deployed in n years, whatever the timeline is, what do you believe will be the number of objects (CRLs, EEs, ROAs, Manifests, size, etc..), RPs, frequency of updates, etc.., given the operational and design experience you have thus far? While I suspect some clever response here, I'm being sincere with these questions, particularly if we're baking this stuff into standards track protocols. Thanks, -danny From dougm.tlist@gmail.com Thu Mar 29 08:08:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518EB21F87EB for ; Thu, 29 Mar 2012 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d06AKhbjUUGW for ; Thu, 29 Mar 2012 08:08:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D42921F87EA for ; Thu, 29 Mar 2012 08:08:06 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2288361bku.31 for ; Thu, 29 Mar 2012 08:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=1mmQ0OBvASDQWJ7dm+xyWupyBiWu0fKCCiKzryiggVo=; b=P9hH2N0HrEaXaMa2vE9jiAR3pyCaGg6CBPpSghP3K6S5JadlSBaAWrxxUo+kACdv0E dtTbouO1jU30DI5yS7YKSlcaw7zofdrtR0kZS/UYfVFMzDVgzjgaNf9YwL3E9ah4bNKS gp/xK5SXjkGrDwdAPc9MIRPn8LbJlvjR8D4znkF9sLEAfb8ATBvvnKxF7vMkrFe67RBR nzIfbT/yRjPpuYMCAFgB4VVZxA3jak+DJctbEpTYEpZoDVBQ601LkSi+DESpoa7QoiC5 b65ZraayLxCiWyUXtBYJKDzC/BERTcducTOr7wfHzY3NYVj0ZIPbI6SusgvAsKRRxR0+ VIig== Received: by 10.204.156.65 with SMTP id v1mr13677680bkw.109.1333033685621; Thu, 29 Mar 2012 08:08:05 -0700 (PDT) Received: from [130.129.87.191] (dhcp-57bf.meeting.ietf.org. [130.129.87.191]) by mx.google.com with ESMTPS id s16sm14444007bkt.3.2012.03.29.08.08.04 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 08:08:04 -0700 (PDT) Message-ID: <4F747AD3.2040009@gmail.com> Date: Thu, 29 Mar 2012 11:08:03 -0400 From: DougM lists User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <00857EED-F2E7-4E41-884E-F25492CF3BF1@ericsson.com> In-Reply-To: <00857EED-F2E7-4E41-884E-F25492CF3BF1@ericsson.com> Content-Type: multipart/alternative; boundary="------------090304040306020700040507" Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:08:08 -0000 This is a multi-part message in MIME format. --------------090304040306020700040507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/29/2012 3:58 AM, Jakob Heitz wrote: > Any place that does not receive a new BGP update can not be helped. > Even with a beacon. Just to be clear, the explicit expire time approach to freshness does work to age-out updates along a update path that is no longer bgp-reachable from the origin. It is the only technique that will help all withdrawl suppression, etc scenarios. That is a slightly different point than this thread (how to indicate that a router has updated RPKI state). But if you were doing origin beacons like the -01 draft, you may not need to do this. Actually from the belt-and-suspenders approach discussed yesterday (combining coarse beaconing with pre-staging two rtr keys and doing faster paced roll) ... what we need to do is expedite / trigger CRL retrievalal / processing (of router old key). The important part of a key roll, is invalidating the old key. We can't pre-stage the CRL, so while we can move to the new key at the speed of BGP convergence, we can only revoke the old key at the speed of RPKI publication, data distribution, and cache-to-rtr. Frankly if we limited the granularity of the beacon to days, I suspect that will be faster than the global CRL pipeline. dougm > > Therefore, a freshness indicator in the BGP update itself is enough > to invalidate less fresh updates. > > Only freshen the BGP update when you actually have a dispute with > your old provider. > > -- Jakob Heitz. > > > On Mar 29, 2012, at 9:51 AM, "Jakob Heitz" > wrote: > > > Could we not put a freshness indication into the BGP update? Then > > everyone that receives the new update would know to invalidate the > > less fresh paths. > > > > Here is the key point: The new update will reach everywhere that it > > needs to go. Won't it? > > > > No expiry time needed. > > > > -- Jakob Heitz. _______________________________________________ > > 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 --------------090304040306020700040507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/29/2012 3:58 AM, Jakob Heitz wrote:
    > Any place that does not receive a new BGP update can not be helped.
    > Even with a beacon.

    Just to be clear, the explicit expire time approach to freshness does work to age-out updates along a update path that is no longer bgp-reachable from the origin.    It is the only technique that will help all withdrawl suppression, etc scenarios.

    That is a slightly different point than this thread (how to indicate that a router has updated RPKI state).  But if you were doing origin beacons like the -01 draft, you may not need to do this.

    Actually from the belt-and-suspenders approach discussed yesterday (combining coarse beaconing with pre-staging two rtr keys and doing faster paced roll) ... what we need to do is expedite / trigger CRL retrievalal / processing (of router old key).

    The important part of a key roll, is invalidating the old key.   We can't pre-stage the CRL, so while we can move to the new key at the speed of BGP convergence, we can only revoke the old key at the speed of RPKI publication, data distribution, and cache-to-rtr.  

    Frankly if we limited the granularity of the beacon to days, I suspect that will be faster than the global CRL pipeline.

    dougm

    >
    > Therefore, a freshness indicator in the BGP update itself is enough
    > to invalidate less fresh updates.
    >
    > Only freshen the BGP update when you actually have a dispute with
    > your old provider.
    >
    > -- Jakob Heitz.
    >
    >
    > On Mar 29, 2012, at 9:51 AM, "Jakob Heitz" <jakob.heitz@ericsson.com>
    > wrote:
    >
    >> Could we not put a freshness indication into the BGP update? Then
    >> everyone that receives the new update would know to invalidate the
    >> less fresh paths.
    >>
    >> Here is the key point: The new update will reach everywhere that it
    >> needs to go. Won't it?
    >>
    >> No expiry time needed.
    >>
    >> -- Jakob Heitz. _______________________________________________
    >> 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


    --------------090304040306020700040507-- From Sandra.Murphy@sparta.com Thu Mar 29 10:51:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8B221F88C7 for ; Thu, 29 Mar 2012 10:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eaeRPSdJwBi for ; Thu, 29 Mar 2012 10:51:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DA1CC21F8868 for ; Thu, 29 Mar 2012 10:51:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2THp6Tm006337 for ; Thu, 29 Mar 2012 12:51:06 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2THous3019095 for ; Thu, 29 Mar 2012 12:50:56 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 13:50:56 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: presentation RPKI Gray Area: Inheritance? Thread-Index: Ac0N1H24xYwZVBtXT5y02H/Br681DQ== Date: Thu, 29 Mar 2012 17:50:55 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CBDA1@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] presentation RPKI Gray Area: Inheritance? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:51:08 -0000 Andrew expressed surprise when he looked at the slides displaying in Wednes= day's session. People looking at the slides remotely were also probably su= rprised.=0A= =0A= That's because andrew sent a set of updated slides shortly before the meeti= ng.=0A= =0A= I was already cut off from email getting webex and such spun up, so I did n= ot see the new set. Chris saw the new set and uploaded them.=0A= =0A= To maintain consistency between the minutes and audio and the slides in the= proceedings, I've uploaded the slides that were presented with the name "(= as presented) RPKI Gray Area: Inheritance?"=0A= =0A= Just so you know why.=0A= =0A= --Sandy= From morrowc@ops-netman.net Thu Mar 29 11:05:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FDC21E808E; Thu, 29 Mar 2012 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kr-oj6SeqV3; Thu, 29 Mar 2012 11:05:39 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id D47AD21E804A; Thu, 29 Mar 2012 11:05:37 -0700 (PDT) Received: from [IPv6:2001:df8:0:80:224:d7ff:fe9a:c078] (unknown [IPv6:2001:df8:0:80:224:d7ff:fe9a:c078]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 09A8D3202F4; Thu, 29 Mar 2012 18:05:35 +0000 (UTC) Message-ID: <4F74A46C.5030906@ops-netman.net> Date: Thu, 29 Mar 2012 14:05:32 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , sidr@ietf.org, sidr-ads@tools.ietf.org, iesg-secretary@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] SIDR Interim meeting 4/30/2012 (April 30, 2012) - IAD X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:05:39 -0000 Hello IESG Secretary, Please send out an announcement to the right places for an interim meeting (plus virtual attendance) for the SIDR-wg, April 30, 2012. Location: Adjacent to the Dulles Airport, Reston, VA, USA 20190-4415 Time: 0900 - 1700 EDT Draft agenda to be sent ~4/10/12. Thanks! -Chris (sidr-co-chair) From christopher.morrow@gmail.com Thu Mar 29 11:11:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225221F8807 for ; Thu, 29 Mar 2012 11:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mxow41JONvt for ; Thu, 29 Mar 2012 11:11:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6121F86F2 for ; Thu, 29 Mar 2012 11:11:03 -0700 (PDT) Received: by obbta17 with SMTP id ta17so983167obb.31 for ; Thu, 29 Mar 2012 11:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IskJFfG8SFqba70aGF1vRq2OFnZ3bkWf7SbWWaCIEAs=; b=e23D4oxiDMPTQsEG3eiVWjEDhd4G6o5QQZynPDvq8d4DpeeeeOl4k8+f75Ov2M5dDr eB7rs2vR4g1kTDt2txpxmVTCDwj0G3GNkyEbJbEESe+CkYFe1xZbhuzsZPnuVfRsqBn7 JEFyVdD4oFQVtMrgJUBiYZkzOTXBGcNa13hk6HSyBsPHoe0Vn0xFLQWvPeIZ6FLPQ5cq M7LTrkhQoAEjKV+TFOGR8elCnGOArMF5f4gWGLT8ELl+tQhAtDWfVhWomsWbJD7M+guC /AK87WPbQPiLEQhbW7bTvW1UkWl+UN9Aku7AABeKw4L2dZ1J5SZZ4ysSImC7WBB2uP0K fteQ== MIME-Version: 1.0 Received: by 10.182.74.8 with SMTP id p8mr45283399obv.41.1333044662708; Thu, 29 Mar 2012 11:11:02 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 11:11:02 -0700 (PDT) In-Reply-To: <4F74A46C.5030906@ops-netman.net> References: <4F74A46C.5030906@ops-netman.net> Date: Thu, 29 Mar 2012 14:11:02 -0400 X-Google-Sender-Auth: DJhHTJhGjKMdwUo0SS-bd7nAaWo Message-ID: From: Christopher Morrow To: Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-ads@tools.ietf.org, "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] SIDR Interim meeting 4/30/2012 (April 30, 2012) - IAD X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:11:03 -0000 -secretary We needed to send the announcement for the first date, in order to hit it, depending on attendence numbers we would be either in Reston for ~20 people or Arlington for 'more' (30). If the number of remote possibles is higher than in-person we should take the opportunity to run a fully remote/virtual meeting and work out the kinks that are sure to exist. (local folks are welcome to attend in person, we'll have decent network in the reston location at least) -chris On Thu, Mar 29, 2012 at 2:05 PM, Chris Morrow wrote: > Hello IESG Secretary, > Please send out an announcement to the right places for an interim > meeting (plus virtual attendance) for the SIDR-wg, April 30, 2012. > > Location: Adjacent to the Dulles Airport, Reston, VA, USA 20190-4415 > Time: 0900 - 1700 EDT > > Draft agenda to be sent ~4/10/12. > > Thanks! > -Chris > (sidr-co-chair) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu Mar 29 11:11:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F9421F8808 for ; Thu, 29 Mar 2012 11:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quYHCUuiARNx for ; Thu, 29 Mar 2012 11:11:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2CC21F8805 for ; Thu, 29 Mar 2012 11:11:55 -0700 (PDT) Received: by yenm5 with SMTP id m5so1884794yen.31 for ; Thu, 29 Mar 2012 11:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BetrA9QfPRhI3CFKvaMljVHkUWBm+Z5AZA3NOh8sUz4=; b=QE23AgimB7w+Fn1NENT+lV+L+wChjsoA8/YE2cKHNKeFAh+D13bk2noI+On62sXrMs yYjs4ybtqvhQMxucYJraKDVnd/qOdBt/mmfqAPEefJbIjQRaombXhZZqbUoRvJ/jiOJ9 3o/1wN6ncpd/mH7EO0uzUySBqS40i69lVA7ROS2kNkMQEXnLEuxzVTfuDig0I9xDQGL+ vDcfKwZcYZM3bzuh6X9wEV1IgBisbmSrQjki4YMrQ1cK/iI+U1GIOVf7snlwWcBHly0O ozdJs5kCZ3tcV2MZzzwpJIQRxbkJo9pI3/Lk45fuAQnDc8SORUFarFmARP/8sFkbzPn3 1v6w== MIME-Version: 1.0 Received: by 10.60.8.103 with SMTP id q7mr43560657oea.61.1333044714558; Thu, 29 Mar 2012 11:11:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 11:11:54 -0700 (PDT) In-Reply-To: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> Date: Thu, 29 Mar 2012 14:11:54 -0400 X-Google-Sender-Auth: SPe1jv9quyBFgNNHK7dAvQiG444 Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Morrow , "Murphy, Sandra" , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:11:56 -0000 Alright, I'll tackle that tomorrow morning. -chris (cochair) On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi wrote: > Sandy, > Chris, > > The WGLC on this doc ended 09/22/2011. > We (the authors) submitted a substantially revised version on October 31,= 2011, > taking into careful consideration all comments that were received during = the WGLC. > Please see Warren's note (attached below). > The authors feel that this document is now ripe and ready for wrapping up= the WGLC. > Thanks. > > Sriram > ________________________________________ > From: Warren Kumari [warren@kumari.net] > Sent: Thursday, November 03, 2011 1:06 PM > To: Sriram, Kotikalapudi > Cc: Warren Kumari; Randy Bush; sidr@ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > >> In this revised version, we (authors) have made changes with careful con= sideration >> of all the comments (mostly of editorial nature) received from Warren an= d Randy. >> >> http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html >> >> We have also made many other edits throughout the doc to improve >> clarity and readability. > > > Thank you. > > I support this moving forward (which is just a formality, I supported it = before as well, this all just makes it (IMO) better).. > > W > >> >> Sriram >> ________________________________________ >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Use Cases and Interpretation = of RPKI Objects for Issuers and Relying Parties >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Terry Manderson >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kotikalapudi Sriram >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Russ White >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-usecases-03.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 30 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Thu Mar 29 12:11:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BB721E8029 for ; Thu, 29 Mar 2012 12:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dody5vmCAB+4 for ; Thu, 29 Mar 2012 12:11:13 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB021E801B for ; Thu, 29 Mar 2012 12:11:11 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so311752wib.13 for ; Thu, 29 Mar 2012 12:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a6av5yoiDh6M7cdD234YmYuh+im4IW7KU1xYocbkqtc=; b=aJkstXFpyiE4ZTjQXRJJuq3/j5shOGa9TCu0ZDYftX3rayqs5N0713BNEv2gBIr5iD /y9kITsnLmwiCtUuxPqQ7pA8XyvOOYLQP/u0ftCKFee/dov/I2P9JTITXCTKnzi7TfUz cIFT+4C6/A8cKDFTRBiArZcKjA36mcx/4G3FsjVkL1Obr2aw7MxhM380ifVzqZPadfUM X198Tu9cOSZmmxevMk+7tctdUJqdad97nCYOVBOuOxsYbbI49+7N2oi0zgvoaXCoZSG2 tVUS7ru4cIAi7LFOquJxNQNS+q7zjey9hWfJC6h1xWvOaTeYiGU1uyycYhV8Y1d0lvsD WV5A== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr9964881wib.3.1333048268834; Thu, 29 Mar 2012 12:11:08 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Thu, 29 Mar 2012 12:11:08 -0700 (PDT) In-Reply-To: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> Date: Thu, 29 Mar 2012 15:11:08 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d0444ee2d8847f204bc667cf7 Cc: Chris Morrow , "Murphy, Sandra" , "Murphy, Sandra" , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:11:14 -0000 --f46d0444ee2d8847f204bc667cf7 Content-Type: text/plain; charset=ISO-8859-1 Hang on, and notwithstanding the request for WGLC. I think the use cases are likely to be informed by protocol design, so even if they are baked, I'd argue that at best that would be only halfway baked. I have a few examples that I can think of, which would necessarily depend significantly on design choices which have been made "by default", but which may turn out to be poor choices, or where later discoveries could result in better choices. I'd prefer this to be added to a "raft" of IDs, for which there is no rush to publish until they are all completed, after which the timing would be appropriate. Here's an example of use-case, which depends on certain assumptions (which may or may not be appropriate, but which are fodder for discussion): Suppose there is an Edge-AS "E", and transit providers to "E", which would be "X" and "Y". Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing done "for her", by "X" and "Y". (Ignore for the moment that the _current_ designs don't support that, that is an entirely other rat-hole for the moment.) What "E" would want to do, is have a delegation, controlled by "E", towards both "X" and "Y" which allow "X" and "Y" to create proxy-path-signatures and proxy-originations, of "X E" and "Y E" respectively. This is about origination, is related partly to BGPSEC requirements/architecture/design/protocol, and necessarily has to do with RP validation based on ROAs. It would be, in theory, possible for _either_ X _or_ Y to completely opaquely proxy for "E", but not for "E" to maintain control, nor to have both X _and_ Y proxy, transparently or opaquely. I don't think we need to fully address this use case just yet, but rather it is an example of something that justifies putting the WGLC on hold, or at least holding it at immediate-post-WGLC state, for further revision pending other work on the protocol. Having decisions based on prior work, rather than informed experience in deployment, and subsequently locked in, is an example of "bad design" methodology. And publishing something IMHO prematurely, locks the WG into that RFC, making revising it much harder, than if it were still in-WG and not-yet-published. (It may turn out to eventually be unchanged, but we should not presuppose that. This applies not just to this doc, but pretty much all the docs. We can make progress on them and "freeze" them without publishing them piece-meal, and I think the WG output would be much better for doing so.) Brian On Thu, Mar 29, 2012 at 2:11 PM, Christopher Morrow wrote: > Alright, I'll tackle that tomorrow morning. > > -chris > (cochair) > > On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi > wrote: > > Sandy, > > Chris, > > > > The WGLC on this doc ended 09/22/2011. > > We (the authors) submitted a substantially revised version on October > 31, 2011, > > taking into careful consideration all comments that were received during > the WGLC. > > Please see Warren's note (attached below). > > The authors feel that this document is now ripe and ready for wrapping > up the WGLC. > > Thanks. > > > > Sriram > > ________________________________________ > > From: Warren Kumari [warren@kumari.net] > > Sent: Thursday, November 03, 2011 1:06 PM > > To: Sriram, Kotikalapudi > > Cc: Warren Kumari; Randy Bush; sidr@ietf.org list > > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > > > On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > > > >> In this revised version, we (authors) have made changes with careful > consideration > >> of all the comments (mostly of editorial nature) received from Warren > and Randy. > >> > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html > >> http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html > >> > >> We have also made many other edits throughout the doc to improve > >> clarity and readability. > > > > > > Thank you. > > > > I support this moving forward (which is just a formality, I supported it > before as well, this all just makes it (IMO) better).. > > > > W > > > >> > >> Sriram > >> ________________________________________ > >> > >> Title : Use Cases and Interpretation of RPKI Objects > for Issuers and Relying Parties > >> Author(s) : Terry Manderson > >> Kotikalapudi Sriram > >> Russ White > >> Filename : draft-ietf-sidr-usecases-03.txt > >> Pages : 30 > >> Date : 2011-10-31 > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt > >> > > > > _______________________________________________ > > 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 > --f46d0444ee2d8847f204bc667cf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hang on, and notwithstanding the request for WGLC.

    I think the use c= ases are likely to be informed by protocol design, so even if they are bake= d, I'd argue that at best that would be only halfway baked.

    I ha= ve a few examples that I can think of, which would necessarily depend signi= ficantly on design choices which have been made "by default", but= which may turn out to be poor choices, or where later discoveries could re= sult in better choices.

    I'd prefer this to be added to a "raft" of IDs, for which= there is no rush to publish until they are all completed, after which the = timing would be appropriate.

    Here's an example of use-case, whic= h depends on certain assumptions (which may or may not be appropriate, but = which are fodder for discussion):

    Suppose there is an Edge-AS "E", and transit providers to &qu= ot;E", which would be "X" and "Y".

    Suppose = "E" does not do BGPSEC (per se), but wants to have BGPSEC signing= done "for her", by "X" and "Y".

    (Ignore for the moment that the _current_ designs don't support tha= t, that is an entirely other rat-hole for the moment.)

    What "E&= quot; would want to do, is have a delegation, controlled by "E", = towards both "X" and "Y" which allow "X" and = "Y" to create proxy-path-signatures and proxy-originations, of &q= uot;X E" and "Y E" respectively.

    This is about origination, is related partly to BGPSEC requirements/arc= hitecture/design/protocol, and necessarily has to do with RP validation bas= ed on ROAs.

    It would be, in theory, possible for _either_ X _or_ Y t= o completely opaquely proxy for "E", but not for "E" to= maintain control, nor to have both X _and_ Y proxy, transparently or opaqu= ely.

    I don't think we need to fully address this use case just yet, but = rather it is an example of something that justifies putting the WGLC on hol= d, or at least holding it at immediate-post-WGLC state, for further revisio= n pending other work on the protocol.

    Having decisions based on prior work, rather than informed experience i= n deployment, and subsequently locked in, is an example of "bad design= " methodology.

    And publishing something IMHO prematurely, locks= the WG into that RFC, making revising it much harder, than if it were stil= l in-WG and not-yet-published.

    (It may turn out to eventually be unchanged, but we should not presuppo= se that. This applies not just to this doc, but pretty much all the docs. W= e can make progress on them and "freeze" them without publishing = them piece-meal, and I think the WG output would be much better for doing s= o.)

    Brian

    On Thu, Mar 29, 2012 at 2:11 PM= , Christopher Morrow <morrowc.lists@gmail.com> wrote:
    Alright, I'll tackle that tomorrow morning.

    -chris
    (cochair)

    On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi
    <kotikalapudi.sriram@nis= t.gov> wrote:
    > Sandy,
    > Chris,
    >
    > The WGLC on this doc ended 09/22/2011.
    > We (the authors) submitted a substantially revised version on October = 31, 2011,
    > taking into careful consideration all comments that were received duri= ng the WGLC.
    > Please see Warren's note (attached below).
    > The authors feel that this document is now ripe and ready for wrapping= up the WGLC.
    > Thanks.
    >
    > Sriram
    > ________________________________________
    > From: Warren Kumari [warren@kumar= i.net]
    > Sent: Thursday, November 03, 2011 1:06 PM
    > To: Sriram, Kotikalapudi
    > Cc: Warren Kumari; Randy Bush; sidr@i= etf.org list
    > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
    >
    > On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote:
    >
    >> In this revised version, we (authors) have made changes with caref= ul consideration
    >> of all the comments (mostly of editorial nature) received from War= ren and Randy.
    >>
    >> http://www.ietf.org/mail-archive/web/sidr/curre= nt/msg03349.html
    >> http://www.ietf.org/mail-archive/web/sidr/curre= nt/msg03306.html
    >> http://www.ietf.org/mail-archive/web/sidr/curre= nt/msg03305.html
    >> http://www.ietf.org/mail-archive/web/sidr/curre= nt/msg03304.html
    >>
    >> We have also made many other edits throughout the doc to improve >> clarity and readability.
    >
    >
    > Thank you.
    >
    > I support this moving forward (which is just a formality, I supported = it before as well, this all just makes it (IMO) better)..
    >
    > W
    >
    >>
    >> Sriram
    >> ________________________________________
    >>
    >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Use Cases and Interpret= ation of RPKI Objects for Issuers and Relying Parties
    >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Terry Manderson
    >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kotikalapudi Sr= iram
    >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Russ White
    >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-usecases-= 03.txt
    >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 30
    >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31
    >>
    >> A URL for this Internet-Draft is:
    >> http://www.ietf.org/internet-drafts/draft-i= etf-sidr-usecases-03.txt
    >>
    >
    > _______________________________________________
    > 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

    --f46d0444ee2d8847f204bc667cf7-- From christopher.morrow@gmail.com Thu Mar 29 16:21:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2D621F8534 for ; Thu, 29 Mar 2012 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5xNmdFyLp1v for ; Thu, 29 Mar 2012 16:21:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1578B21F8531 for ; Thu, 29 Mar 2012 16:21:05 -0700 (PDT) Received: by ggmi1 with SMTP id i1so36217ggm.31 for ; Thu, 29 Mar 2012 16:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hLu3bQNjkxaY1S5wAaPxx41j7xN9h2vnWgZiV2nR2/U=; b=WJlq+orZyWetx4U78mlZUSrg0WuNn2IpFOjVIu8SI3451pUArIjar6nqQVE60qHVYC PjmFpLSfqruki88cBkW7Go+mTh8WSjGbZHKNtmWvlJS3DBi/7fRMyubngUANVc7L4Rgv YOmoxErtCDdwVSv6DpfrfKSrASwHMtLi6UbODpZX/GOSsBAxl4a7jaQjkBm9cGilQwcD iEVvmXZLMSYSpiJnNDZRJaJsQQYsROP/zJOJ8xqYIzLTfcEGFLxlgggomSVxTP7L5L/a GrY17tWKCy3701atZgG0uVlqQr7Kn9irSGQkHD52zQ8Do44nv/aD3r8pERYPpczec8SJ 6RTg== MIME-Version: 1.0 Received: by 10.60.9.38 with SMTP id w6mr23289oea.41.1333063265299; Thu, 29 Mar 2012 16:21:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Thu, 29 Mar 2012 16:21:05 -0700 (PDT) In-Reply-To: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> Date: Thu, 29 Mar 2012 19:21:05 -0400 X-Google-Sender-Auth: bibpxDGDw67qjjoFD0h06_vHO00 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: Chris Morrow , "Murphy, Sandra" , "Murphy, Sandra" , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:21:07 -0000 On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson wrote: > I think the use cases are likely to be informed by protocol design, so even s/informed by protocol design/altered if the protocol design changes/ I'm not sure if the protocol design's going to change the use-cases... you're still going to want to secure a route. (not an important point) > I have a few examples that I can think of, which would necessarily depend > I'd prefer this to be added to a "raft" of IDs, for which there is no rush > to publish until they are all completed, after which the timing would be > appropriate. I'm not against this, though we've got a document hanging out post WGLC (perhaps it ought to be re-reviewed if the changes were significant... anyway) and we'll have to keep kicking it each 5.5 months to stay 'alive'. (again, not super important, and see below as well) > Here's an example of use-case, which depends on certain assumptions (which > may or may not be appropriate, but which are fodder for discussion): > > Suppose there is an Edge-AS "E", and transit providers to "E", which would > be "X" and "Y". > > Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing > done "for her", by "X" and "Y". > > (Ignore for the moment that the _current_ designs don't support that, that > is an entirely other rat-hole for the moment.) hrm, in: section-6 there's discussion of 'only sign your one prefix, do nothing else complex' which fits the model, albeit requiring the end site to run some small number of commands on their device. If they wanted to hand their private key materials to the upstreams they could do the signing, but that seems icky (to me). I don't know that, if implications are understood by the end site and configurations available for use on their side, end-sites would want to hand over control of their IP assets in this way. Running the signing on their side should be simple enough, and low/no-cost. > And publishing something IMHO prematurely, locks the WG into that RFC, > making revising it much harder, than if it were still in-WG and > not-yet-published. I think the authors said something like: "send text" where you think it is fit to be inserted... If other folks want to delay/re-review they need to speak up. Consensus so far was that the document was ready to move along. -chris From Sandra.Murphy@sparta.com Thu Mar 29 16:45:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0403F21F8611 for ; Thu, 29 Mar 2012 16:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGy4sCeE9bN4 for ; Thu, 29 Mar 2012 16:45:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 074BE21F8608 for ; Thu, 29 Mar 2012 16:45:05 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2TNj4Xs009955; Thu, 29 Mar 2012 18:45:04 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2TNj4Ux029609; Thu, 29 Mar 2012 18:45:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 19:45:04 -0400 From: "Murphy, Sandra" To: "Roque Gagliano (rogaglia)" , "sidr@ietf.org" Thread-Topic: [sidr] remote participation experience today Thread-Index: Ac0M5//f0srobMRMSzy2GLfZeuNaQQA28EKAAA/gNzE= Date: Thu, 29 Mar 2012 23:45:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6DCE80@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB4F9@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] remote participation experience today X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:45:07 -0000 I agree with the point of putting slide numbers on slides and with making t= hat a requirement got future presentations. =0A= =0A= As for webex. There are features of webex that might be useful in remote = participation - letting a remote participant manage the slides, some contro= l over remote participants asking questions, and so forth. The telecon is a= good feature for those who want to participate orally (as long as there's = a good way to get audio into the room). I am not an expert, so I do not k= now that the benefit is worth the setup cost on both ends.=0A= =0A= There is a BOF on Friday afternoon's last session "Remote Participation Sys= tem Requirements BOF" that is trying to form some ideas in this regard. Pr= oviding input to that (or just listening for ideas) would be good.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Roque Gagliano (rogaglia) [rogaglia@cisco.com]=0A= Sent: Thursday, March 29, 2012 7:51 AM=0A= To: Murphy, Sandra=0A= Cc: sidr@ietf.org=0A= Subject: Re: [sidr] remote participation experience today=0A= =0A= Sandra,=0A= =0A= I attend the meeting remotely on both Monday and Wednesday. I did not feel = the need for Webex as the audio streaming + jabber worked just fine.=0A= =0A= My only comment is to re-emphasize what was mentioned by Wes on the jabber = room, please request including page numbers on presentation decks to facili= tate the remote experience.=0A= =0A= Roque.=0A= =0A= =0A= On Mar 28, 2012, at 3:42 PM, Murphy, Sandra wrote:=0A= =0A= > The webex session on Monday failed completely, due to laptop wireless inc= apability to maintain a connection (20-50-80-100% packet loss).=0A= >=0A= > The webex session on Wednesday (this morning) seemed to work (alternate n= etworking arranged).=0A= >=0A= > But being the presentation laptop for webex, I was unable to see who (if = any) the participants were.=0A= >=0A= > If you joined the webex session today, PLEASE do comment on the list of w= hat you found worked or did not work for that experience. (Was your view o= f slides keeping up? were you listenting to webex telecon or to ietf audio= stream? could you follow the discussion amongst those in the room? audio= quality? etc.)=0A= >=0A= > It would help in figuring out the future virtual meetings.=0A= >=0A= > --Sandy=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= From iesg-secretary@ietf.org Thu Mar 29 23:50:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A969A21E808B; Thu, 29 Mar 2012 23:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EOfIajOvOg6; Thu, 29 Mar 2012 23:50:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6521E8085; Thu, 29 Mar 2012 23:50:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120330065050.6344.92536.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 23:50:50 -0700 Cc: sidr@ietf.org Subject: [sidr] SIDR Interim Meeting: April 30, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 06:50:53 -0000 The SIDR Working Group will hold an interim meeting (with virtual = attendance) on April 30, 2012. Location: Adjacent to the Dulles Airport, Reston, VA, USA 20190-4415 Time: 0900 - 1700 EDT The draft agenda will be published on the SIDR mailing list prior to the = meeting. From Sandra.Murphy@sparta.com Fri Mar 30 01:21:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5421F882C for ; Fri, 30 Mar 2012 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9fjTKIzJhWz for ; Fri, 30 Mar 2012 01:21:50 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3419221F8822 for ; Fri, 30 Mar 2012 01:21:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2U8Lmih011716; Fri, 30 Mar 2012 03:21:48 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2U8Ll5v003225; Fri, 30 Mar 2012 03:21:47 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Fri, 30 Mar 2012 04:21:47 -0400 From: "Murphy, Sandra" To: Christopher Morrow , Brian Dickson Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Thread-Index: AQHMmCOt1CW4b+qPEkuJdphkZ9jq2pWXZE2AgAREVgCAOHGKgICup3EAgAAQjACAAEXWgIAAU6pD Date: Fri, 30 Mar 2012 08:21:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Chris Morrow , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:21:52 -0000 Brian, Chris.=0A= =0A= The usecases draft was intended to describe origin validation use cases.=0A= =0A= Route leaks (and other path validation issues) might need their own usecase= s draft.=0A= =0A= But I don't think we should add those cases to this draft.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: christopher.morrow@gmail.com [christopher.morrow@gmail.com] on behalf= of Christopher Morrow [morrowc.lists@gmail.com]=0A= Sent: Thursday, March 29, 2012 7:21 PM=0A= To: Brian Dickson=0A= Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; sid= r@ietf.org list=0A= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt=0A= =0A= On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson=0A= wrote:=0A= =0A= > I think the use cases are likely to be informed by protocol design, so ev= en=0A= =0A= s/informed by protocol design/altered if the protocol design changes/=0A= =0A= I'm not sure if the protocol design's going to change the use-cases...=0A= you're still going to want to secure a route. (not an important point)=0A= =0A= > I have a few examples that I can think of, which would necessarily depend= =0A= =0A= > I'd prefer this to be added to a "raft" of IDs, for which there is no rus= h=0A= > to publish until they are all completed, after which the timing would be= =0A= > appropriate.=0A= =0A= I'm not against this, though we've got a document hanging out post=0A= WGLC (perhaps it ought to be re-reviewed if the changes were=0A= significant... anyway) and we'll have to keep kicking it each 5.5=0A= months to stay 'alive'. (again, not super important, and see below as=0A= well)=0A= =0A= > Here's an example of use-case, which depends on certain assumptions (whic= h=0A= > may or may not be appropriate, but which are fodder for discussion):=0A= >=0A= > Suppose there is an Edge-AS "E", and transit providers to "E", which woul= d=0A= > be "X" and "Y".=0A= >=0A= > Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing= =0A= > done "for her", by "X" and "Y".=0A= >=0A= > (Ignore for the moment that the _current_ designs don't support that, tha= t=0A= > is an entirely other rat-hole for the moment.)=0A= =0A= hrm, in:=0A= =0A= =0A= =0A= section-6 there's discussion of 'only sign your one prefix, do nothing=0A= else complex' which fits the model, albeit requiring the end site to=0A= run some small number of commands on their device. If they wanted to=0A= hand their private key materials to the upstreams they could do the=0A= signing, but that seems icky (to me).=0A= =0A= I don't know that, if implications are understood by the end site and=0A= configurations available for use on their side, end-sites would want=0A= to hand over control of their IP assets in this way. Running the=0A= signing on their side should be simple enough, and low/no-cost.=0A= =0A= > And publishing something IMHO prematurely, locks the WG into that RFC,=0A= > making revising it much harder, than if it were still in-WG and=0A= > not-yet-published.=0A= =0A= I think the authors said something like: "send text" where you think=0A= it is fit to be inserted... If other folks want to delay/re-review=0A= they need to speak up. Consensus so far was that the document was=0A= ready to move along.=0A= =0A= -chris=0A= From andy@arin.net Fri Mar 30 01:54:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3DA21F888B for ; Fri, 30 Mar 2012 01:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6MPHs04WuK3 for ; Fri, 30 Mar 2012 01:54:03 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 35CAC21F88A6 for ; Fri, 30 Mar 2012 01:54:01 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 49A37164F83; Fri, 30 Mar 2012 04:53:58 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id C2B50164F80; Fri, 30 Mar 2012 04:53:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 30 Mar 2012 04:53:32 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.210]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 04:53:49 -0400 From: Andy Newton To: Randy Bush Thread-Topic: [sidr] Injecting idea of "freshness of repository data" into BGP Thread-Index: AQHNDLuXo/eCXWt5vUOntXvbJn/jApaAuMoAgABqOgCAAAf8AIAABw6AgAA5RICAAARuAIAAASoAgAAEwACAAB4ZAIABOxKA Date: Fri, 30 Mar 2012 08:53:49 +0000 Message-ID: <2C74399F-D505-4FF3-BD0D-57527E87784D@arin.net> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:54:04 -0000 On Mar 29, 2012, at 4:06 PM, Randy Bush wrote: > o we could get much better rsync performance with a trivial change at > the rirs. I've learned that little related to the RPKI is trivial. Is the actual issue observed with rsync documented anywhere, along with a m= ore descriptive solution? I think I understand what is being asked, but it = would be best to have clarity before making changes. Also, the presentation given at SIDR and IEPG indicated the study was done = with only one RPKI validator. We have all three running in our lab and have= noticed differences in speed over a local network with the same repository= . Before declaring the problem a universal issue with rsync, wouldn't a tes= t with the other validators provide helpful data points? -andy= From christopher.morrow@gmail.com Fri Mar 30 02:44:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C287421F8878 for ; Fri, 30 Mar 2012 02:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN1LeRp39kqa for ; Fri, 30 Mar 2012 02:44:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F321F888C for ; Fri, 30 Mar 2012 02:44:22 -0700 (PDT) Received: by obbta17 with SMTP id ta17so870163obb.31 for ; Fri, 30 Mar 2012 02:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SB1nFFOemG44F07hl+UCctS98j5D2nESZYA3Bc0BbOw=; b=rokbsqoSn12Kkfqz6k0CYxM7jsEv7Rho3N21z/4O6XqPBkiECn6h0ZiFjtYA3kf87Y zBTkbBlUL3mfPDXorvxRt7LWkLFgWg0C2kSj3V6DhcK6t8usA4gmEJbMwptJqLHUC1n2 AxtHSXxRxi+kcpR+8/uvaobHzK1gscAePtGpz/O9+t2UTEDSZ1D0L7pkaEeTLaZ/gxB1 /memMsHn3GYHcUbGWpA4rwEx5Vc23JzeXHbdRI2p8xgwXeMMEZPI5OsJEAH7wafzJYof 6WVz48C33wWY16fiTmeIq0vykllrdhFRUaCwx8pi58hcAzcVVidwOW/1wM6xRyCIbHV8 T2Lg== MIME-Version: 1.0 Received: by 10.60.1.7 with SMTP id 7mr1686301oei.71.1333100661866; Fri, 30 Mar 2012 02:44:21 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Fri, 30 Mar 2012 02:44:21 -0700 (PDT) In-Reply-To: <2C74399F-D505-4FF3-BD0D-57527E87784D@arin.net> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> <2C74399F-D505-4FF3-BD0D-57527E87784D@arin.net> Date: Fri, 30 Mar 2012 05:44:21 -0400 X-Google-Sender-Auth: _3Yb-HwmMTniQrbGGQgVAw8aUGM Message-ID: From: Christopher Morrow To: Andy Newton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:44:23 -0000 On Fri, Mar 30, 2012 at 4:53 AM, Andy Newton wrote: > > Also, the presentation given at SIDR and IEPG indicated the study was don= e with only one RPKI validator. We have all three running in our lab and ha= ve noticed differences in speed over a local network with the same reposito= ry. Before declaring the problem a universal issue with rsync, wouldn't a t= est with the other validators provide helpful data points? > is there a way to run all three from many points on the network and gather useful stats to graph/history/etc? (is this sort of thing a good idea? watching/storing/analyzing performance over history I mean) From christopher.morrow@gmail.com Fri Mar 30 02:45:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B2F21F8878 for ; Fri, 30 Mar 2012 02:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGhw73JQVmhM for ; Fri, 30 Mar 2012 02:45:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2121F8888 for ; Fri, 30 Mar 2012 02:45:04 -0700 (PDT) Received: by obbta17 with SMTP id ta17so871207obb.31 for ; Fri, 30 Mar 2012 02:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=87ewRruSWAke85ihqh4V8Cx8mBtCkLIYvfG0FwyMjfA=; b=W5/w54YNMna7HfiBq3MDFUxoZgGulhzV2QqrEdRA1azjee7ehtQkcvKSondC913apS H4rZ3MJp962Rt41lg8JTCNXAVwGbwq29efnAaP/16xq7nWxL8GnsfqXNUG6vFs6TOyGO r/9ioiGv310sMSPBEE0jmnQGX8URFRDBpnJCAue4puvF0dinu7m5RJj8EcfhxqpIdzNa QRLLn7YNFE+PlZSX/Zy3Ql3uuVkmKPWWala85m2PeRp/0ypFrFGqPBLnjgqY2wZL3OvJ alKbnLc+A+6b/hR8xYfgHRxqRDzux20Ztd/+yntJkeHUId9Vq6+7Grug1xIf+QPnQA3s 9GcA== MIME-Version: 1.0 Received: by 10.182.85.39 with SMTP id e7mr1697248obz.51.1333100704101; Fri, 30 Mar 2012 02:45:04 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.80.137 with HTTP; Fri, 30 Mar 2012 02:45:04 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> Date: Fri, 30 Mar 2012 05:45:04 -0400 X-Google-Sender-Auth: LIBeKnG3PmNueWMOqxz3-7nP5tY Message-ID: From: Christopher Morrow To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Morrow , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:45:05 -0000 On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra wrote: > Brian, Chris. > > The usecases draft was intended to describe origin validation use cases. > > Route leaks (and other path validation issues) might need their own useca= ses draft. > > But I don't think we should add those cases to this draft. fair enough. (it seems to me) > --Sandy > > ________________________________________ > From: christopher.morrow@gmail.com [christopher.morrow@gmail.com] on beha= lf of Christopher Morrow [morrowc.lists@gmail.com] > Sent: Thursday, March 29, 2012 7:21 PM > To: Brian Dickson > Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; s= idr@ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > wrote: > >> I think the use cases are likely to be informed by protocol design, so e= ven > > s/informed by protocol design/altered if the protocol design changes/ > > I'm not sure if the protocol design's going to change the use-cases... > you're still going to want to secure a route. (not an important point) > >> I have a few examples that I can think of, which would necessarily depen= d > >> I'd prefer this to be added to a "raft" of IDs, for which there is no ru= sh >> to publish until they are all completed, after which the timing would be >> appropriate. > > I'm not against this, though we've got a document hanging out post > WGLC (perhaps it ought to be re-reviewed if the changes were > significant... anyway) and we'll have to keep kicking it each 5.5 > months to stay 'alive'. (again, not super important, and see below as > well) > >> Here's an example of use-case, which depends on certain assumptions (whi= ch >> may or may not be appropriate, but which are fodder for discussion): >> >> Suppose there is an Edge-AS "E", and transit providers to "E", which wou= ld >> be "X" and "Y". >> >> Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signin= g >> done "for her", by "X" and "Y". >> >> (Ignore for the moment that the _current_ designs don't support that, th= at >> is an entirely other rat-hole for the moment.) > > hrm, in: > > =A0 > > section-6 there's discussion of 'only sign your one prefix, do nothing > else complex' which fits the model, albeit requiring the end site to > run some small number of commands on their device. If they wanted to > hand their private key materials to the upstreams they could do the > signing, but that seems icky (to me). > > I don't know that, if implications are understood by the end site and > configurations available for use on their side, end-sites would want > to hand over control of their IP assets in this way. Running the > signing on their side should be simple enough, and low/no-cost. > >> And publishing something IMHO prematurely, locks the WG into that RFC, >> making revising it much harder, than if it were still in-WG and >> not-yet-published. > > I think the authors said something like: "send text" where you think > it is fit to be inserted... If other folks want to delay/re-review > they need to speak up. Consensus so far was that the document was > ready to move along. > > -chris From aservin@lacnic.net Fri Mar 30 03:14:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655BC21F8865 for ; Fri, 30 Mar 2012 03:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1HP3s23Hjl6 for ; Fri, 30 Mar 2012 03:14:42 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 386B421F8880 for ; Fri, 30 Mar 2012 03:14:38 -0700 (PDT) Received: from dhcp-1390.meeting.ietf.org (dhcp-1390.meeting.ietf.org [130.129.19.144]) by mail.lacnic.net.uy (Postfix) with ESMTP id D5241308432; Fri, 30 Mar 2012 07:14:21 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Fri, 30 Mar 2012 12:14:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> <2C74399F-D505-4FF3-BD0D-57527E87784D@arin.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:14:43 -0000 On 30 Mar 2012, at 11:44, Christopher Morrow wrote: > On Fri, Mar 30, 2012 at 4:53 AM, Andy Newton wrote: >>=20 >> Also, the presentation given at SIDR and IEPG indicated the study was = done with only one RPKI validator. We have all three running in our lab = and have noticed differences in speed over a local network with the same = repository. Before declaring the problem a universal issue with rsync, = wouldn't a test with the other validators provide helpful data points? >>=20 >=20 > is there a way to run all three from many points on the network and > gather useful stats to graph/history/etc? (is this sort of thing a > good idea? watching/storing/analyzing performance over history I mean) I think there is a way and it is a very good idea. We just need = some CPU donations. I think some RIRs are willing to support the idea and to do some = cross monitoring (but just speaking for myself).=20 Regards, .as =09 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From aservin@lacnic.net Fri Mar 30 03:24:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8346721F869F for ; Fri, 30 Mar 2012 03:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHUcG0GbvqjU for ; Fri, 30 Mar 2012 03:24:37 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6F821F869C for ; Fri, 30 Mar 2012 03:24:36 -0700 (PDT) Received: from dhcp-1390.meeting.ietf.org (dhcp-1390.meeting.ietf.org [130.129.19.144]) by mail.lacnic.net.uy (Postfix) with ESMTP id F033D308492; Fri, 30 Mar 2012 07:24:28 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_36FA7C5E-D645-4BE6-B30A-4AE3A652B2AD" From: Arturo Servin In-Reply-To: <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> Date: Fri, 30 Mar 2012 12:24:25 +0200 Message-Id: <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: sidr wg list Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:24:37 -0000 --Apple-Mail=_36FA7C5E-D645-4BE6-B30A-4AE3A652B2AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Rob, I think it is a bit premature to conclude that. Under the same = data set I could conclude that your network, validator and research = methodology is broken. But that is not the point, the point is that we = may have a problem, let's try to solve it and to validate how bad it is. In another email Chris Morrow suggested to measure using = different validator implementation and different locations, which I = think it is a very good idea to see how bad we are and how we can = improve. Meanwhile, as an repository operator I would love to hear your = suggestion to improve.=20 Cheers, /as On 29 Mar 2012, at 12:04, Rob Austein wrote: > In my opinion the RIRs are currently using > rsync badly, given the way they've chosen to set up their > repositories. =20 --Apple-Mail=_36FA7C5E-D645-4BE6-B30A-4AE3A652B2AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think it is a bit premature to = conclude that. Under the same data set I could conclude that your = network, validator and research methodology is broken. But that is not = the point, the point is that we may have a problem, let's try to solve = it and to validate how bad it is.

    In = another email Chris Morrow suggested to measure using different = validator implementation and different locations, which I think it is a = very good idea to see how bad we are and how we can = improve.

    Meanwhile, as an repository = operator I would love to hear your suggestion to = improve. 

    Cheers,
    /as

    On 29 Mar 2012, at 12:04, Rob Austein wrote:

     In my = opinion the RIRs are currently using
    rsync badly, given the way = they've chosen to set up their
    repositories. =  

    = --Apple-Mail=_36FA7C5E-D645-4BE6-B30A-4AE3A652B2AD-- From waehlisch@ieee.org Fri Mar 30 03:53:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9621F866D for ; Fri, 30 Mar 2012 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.85 X-Spam-Level: X-Spam-Status: No, score=-105.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Q-dg+o4vTd for ; Fri, 30 Mar 2012 03:53:09 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 131DC21F85C2 for ; Fri, 30 Mar 2012 03:53:09 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from dhcp-922d.meeting.ietf.org ([130.129.10.45] helo=mw-PC.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1SDZS6-000C2w-O2; Fri, 30 Mar 2012 12:53:06 +0200 Date: Fri, 30 Mar 2012 12:53:14 +0200 From: Matthias Waehlisch To: Arturo Servin In-Reply-To: Message-ID: References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <20120329115714.GA18393@slice> <20120329121824.GB18393@slice> <2C74399F-D505-4FF3-BD0D-57527E87784D@arin.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg list Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:53:10 -0000 On Fri, 30 Mar 2012, Arturo Servin wrote: > >> Also, the presentation given at SIDR and IEPG indicated the study > >> was done with only one RPKI validator. We have all three running in > >> our lab and have noticed differences in speed over a local network > >> with the same repository. Before declaring the problem a universal > >> issue with rsync, wouldn't a test with the other validators provide > >> helpful data points? > >> > > is there a way to run all three from many points on the network and > > gather useful stats to graph/history/etc? (is this sort of thing a > > good idea? watching/storing/analyzing performance over history I > > mean) > > I think there is a way and it is a very good idea. We just need > some CPU donations. > > I think some RIRs are willing to support the idea and to do some > cross monitoring (but just speaking for myself). > we already run Rob's validator and RIPE NCC Validator (located in Germany, connected via German NREN); BBN for testing purposes. We are open to activate performance stats. Let me know. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From carlosm3011@gmail.com Fri Mar 30 06:46:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4521F85EF for ; Fri, 30 Mar 2012 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5VtSqv8UtXp for ; Fri, 30 Mar 2012 06:46:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7435521F856A for ; Fri, 30 Mar 2012 06:46:02 -0700 (PDT) Received: by qcsq13 with SMTP id q13so437598qcs.31 for ; Fri, 30 Mar 2012 06:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:cc:subject :references:in-reply-to:content-type; bh=MBLAMrOT87QXbiHmEtr6sIuJE0f9UcYinhiwVV+B3CI=; b=fxE6Qwg0xJ32cIE9+2vYvEotyxhH3jjECwVXP6Zi+Eo0bxZP3dfMK0POovqWDlHHpC IsvgH02q7c4Ok8MxgqL4XlgrLu9C2hkYwXRK2rsyTGo/BYd0cQK47ZE/YK80rV5QLgfv uxLtMt2iEZ+3UEc4VKgF9uugMlf8THHyRTahCB/L9lATb/OQA6BvaqAoCsxI3W0xTJZ/ xKTNoirf0Qr9OmgmWj8+9xd7/HZvXCK4K24rdS2pjf/B3ibzcQSavodEQhPT4mJBsw7s t8ivQEWzf/WeMjRAQD0QyEK52FfXCCECbUxMbtkQI+HXIdxRdh+RWjbxnnYppqMtbVoP M31g== Received: by 10.224.215.10 with SMTP id hc10mr5668252qab.28.1333115161871; Fri, 30 Mar 2012 06:46:01 -0700 (PDT) Received: from europa.local ([200.7.85.168]) by mx.google.com with ESMTPS id cv8sm18347159qab.12.2012.03.30.06.45.59 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 06:46:00 -0700 (PDT) Message-ID: <4F75B916.6000807@gmail.com> Date: Fri, 30 Mar 2012 10:45:58 -0300 From: Carlos Martinez-Cagnazzo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 CC: sidr wg list References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> In-Reply-To: <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> Content-Type: multipart/alternative; boundary="------------050304050501050707060208" Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:46:03 -0000 This is a multi-part message in MIME format. --------------050304050501050707060208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, > On 29 Mar 2012, at 12:04, Rob Austein wrote: > >> In my opinion the RIRs are currently using >> rsync badly, given the way they've chosen to set up their >> repositories. > If you provide us with some guidelines on how you believe the repositories should be organized, who knows, we may be willing to try them out! Seriously, I think we all want the technology to succeed and to be widely adopted. At least on that we are on the same boat. I can't help but feel that we could be doing a much better job at cooperating. The one time you emailed me about problems with our certs and RPKI, We had them solved within a couple of days. I think we should try that approach more often. cheers! Carlos > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------050304050501050707060208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

    On 29 Mar 2012, at 12:04, Rob Austein wrote:

     In my opinion the RIRs are currently using
    rsync badly, given the way they've chosen to set up their
    repositories.  

    <all hats off, speaking only for myself>

    If you provide us with some guidelines on how you believe the repositories should be organized, who knows, we may be willing to try them out!

    Seriously, I think we all want the technology to succeed and to be widely adopted. At least on that we are on the same boat. I can't help but feel that we could be doing a much better job at cooperating.

    <hats on>

    The one time you emailed me about problems with our certs and RPKI, We had them solved within a couple of days. I think we should try that approach more often.

    cheers!

    Carlos


    _______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
    --------------050304050501050707060208-- From brian.peter.dickson@gmail.com Fri Mar 30 07:34:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB121F86D1 for ; Fri, 30 Mar 2012 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMc7wahn424x for ; Fri, 30 Mar 2012 07:34:38 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2D81F21F864B for ; Fri, 30 Mar 2012 07:34:38 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so737634wib.1 for ; Fri, 30 Mar 2012 07:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=do8yBq9afdsrqj0JKtXVAMeL6/eIyA4WWBlQHC68VWo=; b=ijltVVXUrlvQcvWaJu7rWWPEs/ADIQYmvonnqfg0NG+Z3oAHxpCVmFZSKDpeq+c6uF ujLu0cRvsjifjAu3x2lkKCr2FBjZPSoU8RVdLUoGW6gIliNNeVeLT4wKnZoNNDRnvlH/ sKD5JLUeXaulxo4qJqde/g2l1n56HWeE2cJ+FfQWkaeIcNJx/PVfVjq3yhnnxb0pMXgZ JidS6sSL14seATdFT+EuBfmcMrG7dKJDmVAIikHIADU3tGhN/7BzYE8nvK+S3r/VGaXI 9HMQE6iK+7dZfH/DubdmWJqdc4MTNSnQXovJLyJZRgBZF3jJM4JwvOqxLcYlg8ppBbs7 vqKw== MIME-Version: 1.0 Received: by 10.180.107.101 with SMTP id hb5mr7324226wib.3.1333112139427; Fri, 30 Mar 2012 05:55:39 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Fri, 30 Mar 2012 05:55:39 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> Date: Fri, 30 Mar 2012 08:55:39 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=e89a8f3bb0cf84311504bc755b4b Cc: Chris Morrow , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:34:46 -0000 --e89a8f3bb0cf84311504bc755b4b Content-Type: text/plain; charset=ISO-8859-1 Sandy, The use case example I included, is an origin validation use case. The problem is the inability to have "origination" (signed injection into BGPSEC) done by proxy, at all or especially by more than one party. The particular situation leading to the need for this, would be a stub AS whose router vendor does not support BGPSEC, or whose router hardware or code base is not included in BGPSEC support by their router vendor. (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by operators.) This is likely to be a fairly common situation _among stub AS_ and, given the current requirement for origin injection for BGPSEC, addressing this _may_ impact the use cases document, for _origin validation_. I'm just saying... Brian On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra wrote: > Brian, Chris. > > The usecases draft was intended to describe origin validation use cases. > > Route leaks (and other path validation issues) might need their own > usecases draft. > > But I don't think we should add those cases to this draft. > > --Sandy > > ________________________________________ > From: christopher.morrow@gmail.com [christopher.morrow@gmail.com] on > behalf of Christopher Morrow [morrowc.lists@gmail.com] > Sent: Thursday, March 29, 2012 7:21 PM > To: Brian Dickson > Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; > sidr@ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > wrote: > > > I think the use cases are likely to be informed by protocol design, so > even > > s/informed by protocol design/altered if the protocol design changes/ > > I'm not sure if the protocol design's going to change the use-cases... > you're still going to want to secure a route. (not an important point) > > > I have a few examples that I can think of, which would necessarily depend > > > I'd prefer this to be added to a "raft" of IDs, for which there is no > rush > > to publish until they are all completed, after which the timing would be > > appropriate. > > I'm not against this, though we've got a document hanging out post > WGLC (perhaps it ought to be re-reviewed if the changes were > significant... anyway) and we'll have to keep kicking it each 5.5 > months to stay 'alive'. (again, not super important, and see below as > well) > > > Here's an example of use-case, which depends on certain assumptions > (which > > may or may not be appropriate, but which are fodder for discussion): > > > > Suppose there is an Edge-AS "E", and transit providers to "E", which > would > > be "X" and "Y". > > > > Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing > > done "for her", by "X" and "Y". > > > > (Ignore for the moment that the _current_ designs don't support that, > that > > is an entirely other rat-hole for the moment.) > > hrm, in: > > > > section-6 there's discussion of 'only sign your one prefix, do nothing > else complex' which fits the model, albeit requiring the end site to > run some small number of commands on their device. If they wanted to > hand their private key materials to the upstreams they could do the > signing, but that seems icky (to me). > > I don't know that, if implications are understood by the end site and > configurations available for use on their side, end-sites would want > to hand over control of their IP assets in this way. Running the > signing on their side should be simple enough, and low/no-cost. > > > And publishing something IMHO prematurely, locks the WG into that RFC, > > making revising it much harder, than if it were still in-WG and > > not-yet-published. > > I think the authors said something like: "send text" where you think > it is fit to be inserted... If other folks want to delay/re-review > they need to speak up. Consensus so far was that the document was > ready to move along. > > -chris > --e89a8f3bb0cf84311504bc755b4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sandy,

    The use case example I included, is an origin val= idation use case.

    The problem is the inability to = have "origination" (signed injection into BGPSEC) done by proxy, = at all or especially by more than one party.

    The particular situation leading to the need for this, = would be a stub AS whose router vendor does not support BGPSEC, or whose ro= uter hardware or code base is not included in BGPSEC support by their route= r vendor.

    (Doing a forklift upgrade to do BGPSEC is generally see= n as #FAIL by operators.)

    This is likely to be a f= airly common situation _among stub AS_ and, given the current requirement f= or origin injection for BGPSEC, addressing this _may_ impact the use cases = document, for _origin validation_.

    I'm just saying...

    Brian
    On Fri, Mar 30, 2012 at 4:21 AM, Murphy, S= andra <San= dra.Murphy@sparta.com> wrote:
    Brian, Chris.

    The usecases draft was intended to describe origin validation use cases.
    Route leaks (and other path validation issues) might need their own usecase= s draft.

    But I don't think we should add those cases to this draft.

    --Sandy

    ________________________________________
    From: christopher.morrow@gm= ail.com [christopher.mo= rrow@gmail.com] on behalf of Christopher Morrow [morrowc.lists@gmail.com]
    Sent: Thursday, March 29, 2012 7:21 PM
    To: Brian Dickson
    Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; sidr@ietf.org list
    Subject: Re: [sidr] I-D Action: draft-ietf-sidr-us= ecases-03.txt

    On Thu, Mar 29, 2012 at 3:11 = PM, Brian Dickson
    <brian.peter.dickson@gm= ail.com> wrote:

    > I think the use cases are likely to be informed by protocol design, so= even

    s/informed by protocol design/altered if the protocol design changes/

    I'm not sure if the protocol design's going to change the use-cases= ...
    you're still going to want to secure a route. (not an important point)<= br>
    > I have a few examples that I can think of, which would necessarily dep= end
    <snip>
    > I'd prefer this to be added to a "raft" of IDs, for whic= h there is no rush
    > to publish until they are all completed, after which the timing would = be
    > appropriate.

    I'm not against this, though we've got a document hanging out post<= br> WGLC (perhaps it ought to be re-reviewed if the changes were
    significant... anyway) and we'll have to keep kicking it each 5.5
    months to stay 'alive'. (again, not super important, and see below = as
    well)

    > Here's an example of use-case, which depends on certain assumption= s (which
    > may or may not be appropriate, but which are fodder for discussion): >
    > Suppose there is an Edge-AS "E", and transit providers to &q= uot;E", which would
    > be "X" and "Y".
    >
    > Suppose "E" does not do BGPSEC (per se), but wants to have B= GPSEC signing
    > done "for her", by "X" and "Y".
    >
    > (Ignore for the moment that the _current_ designs don't support th= at, that
    > is an entirely other rat-hole for the moment.)

    hrm, in:

    =A0<http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-ops-0= 4.txt>

    section-6 there's discussion of 'only sign your one prefix, do noth= ing
    else complex' which fits the model, albeit requiring the end site to run some small number of commands on their device. If they wanted to
    hand their private key materials to the upstreams they could do the
    signing, but that seems icky (to me).

    I don't know that, if implications are understood by the end site and configurations available for use on their side, end-sites would want
    to hand over control of their IP assets in this way. Running the
    signing on their side should be simple enough, and low/no-cost.

    > And publishing something IMHO prematurely, locks the WG into that RFC,=
    > making revising it much harder, than if it were still in-WG and
    > not-yet-published.

    I think the authors said something like: "send text" where you th= ink
    it is fit to be inserted... If other folks want to delay/re-review
    they need to speak up. Consensus so far was that the document was
    ready to move along.

    -chris

    --e89a8f3bb0cf84311504bc755b4b-- From tim@ripe.net Fri Mar 30 08:08:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37A721F865D for ; Fri, 30 Mar 2012 08:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdSeEp-5bbhS for ; Fri, 30 Mar 2012 08:08:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id AC69A21F8652 for ; Fri, 30 Mar 2012 08:08:45 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SDdRR-0002yX-Lz for sidr@ietf.org; Fri, 30 Mar 2012 17:08:44 +0200 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SDdRP-0008Kv-Ko; Fri, 30 Mar 2012 17:08:41 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 17:08:27 +0200 To: "sidr@ietf.org list" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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: 784d7acfe6559f2a0b602ec6519a0719d1749e154c17d3b6e56860fb50b2a7e3 Subject: [sidr] rpki repository and validation issues X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:08:46 -0000 Hi, There are a number of separate discussions about problems with the rpki = repository and ways to mitigate those problems going on on the list at = the moment. First of all let me say: as a starting point the current system works = most of the time, but we are finding issues that I think should be = fixed, that are not trivial. So my take on this is that we've learned from operational experience and = it would now be good to (1) enumerate the problems that we see, and (2) = refine a list of requirements for improvement, and then (3) find ways = forward to address these requirements, without breaking the existing = infrastructure. As some of you know from discussions we had I do = actually have some ideas in the solution space, but.. before going there = in detail (beyond proof of concept) I think the WG should address 1 & = 2.. It may be best if we could discuss this face to face, eg at one of the = upcoming interim meetings. I am not a huge fan of interim meetings, but = I am afraid this is a difficult subject to find consensus on on the = list, and too big to discuss in a 2 hour IETF slot. My preference would = be to discuss this in the planned meeting just before the Vancouver = IETF: I am already planning to travel to that one, and I expect it will = be the easiest to attend for most people. Since I don't know if and when this will happen though, let me write = down my ideas, without going to solution space where I think face to = face or at least interactive presentations are most needed to make = progress. 1 =3D Current problems we encounter (implementing a validator and = running a publication point): =3D Updates happen while we are rsync'ing from the validator: =3D We may miss objects that are on the manifest =3D We may find objects that are not on the manifest (we actually = ignore these) =3D The CRL may be newer and revoke this MFT =3D The MFT may be newer and the CRL hash value is wrong All this makes it very difficult for the RP to make clear automated = validation decisions. And we all know that *no one* reads the logs... or even if they do, = most people won't know how to decide.. =3D PFX-validate assumes knowledge of *all* applicable ROAs, but the RP = may not get all data =3D The only way an RP can detect this is by looking at the manifest. =3D But the manifest is considered, at least by people I talk to, to = not be authoritative on this. =3D The reason why a ROA might be missing is not clear to the RP =3D A man in the middle may filter bits of information (hold back = ROA, MFT, CRL) =3D There may be a bug in the CA =3D There may be a bug or problem at the publisher (eg someone = *deleted* the ROA on disk) =3D There may be a race condition - stuff is changing while we = look, as described above =3D We need to call 'rsync' on the system (there is only one = implementation, libraries unavailable for most coding languages) =3D Forks cause cpu overhead and may (temporarily) result in = duplicating the memory usage (at least for jvm) =3D Parallel processing requiring system calls does not scale =3D We need rsync installed and on the path =3D We need to like that version =3D We need to make sense of exit codes to have useful error messages = and take action (or inform user) =3D Publication point availability =3D We don't know of any commercial CDNs that do rsync =3D Doing this ourselves by having multiple rsync servers (and eg = anycast) is not trivial =3D An RP possibly ending up on different (out of sync) mirror = servers, and getting inconsistent responses, does not help =3D To avoid load on back-ends the general advice to RPs has been to = not be too aggressive, even though they 'want' fresh data =3D Local policy knobs in validation =3D The absence of sensible defaults make it difficult to automate = validation =3D Uncertainty here, for implementers, is even worse for end user: = they really just want to know: "so, is this thing *valid*, or not?" =3D Giving them a knob confuses them and lowers the trust in this = system These are my major findings at least. There may be more. With regards to = the hierarchical repository lay-out, or absence thereof causing issues. = Our validator gets around that by having additional configuration for = the RIR TAs to do additional pre-fetching of the repositories. This = helps, so yes, either this work-around or a change in those repository = lay-outs would help RPs. Having said that, the problems that I = enumerated above remain in my opinion. Chris suggested that we do some more coordinated measurements. I think = this is an excellent idea and I would like to help with this effort. If = possible it would be very worthwhile to get some quantifiable sense of = the issues. Apart from monitoring over time, it would also be = interesting to do some aggressive testing, like load stressing a = publication point, set up a large, high churn, test repository, or set = up different validators to update far more often (like every few = minutes) and see what breaks. 2 =3D Possible requirements for moving forward: This is not a complete or final list of course. I am very interested in = your additions. Even thought there may be requirements that we're not = able to meet, there is still value in listing them and deciding.. =3D New schemes should iterate on existing infrastructure without = breaking it =3D If more than one retrieval mechanism is allowed, then *objects* = should be uniquely identifiable =3D Inconsistent data to relying parties should be prevented =3D It should be detectable for an RP if it does not get all the data a = CA intended to publish =3D Protocols should be ubiquitous with regards to support in coding = languages =3D Update semantics and protocol should allow for distributed caching =3D Local policy knobs because of validation uncertainties should be = avoided as much as possible Regards, Tim From carlosm3011@gmail.com Fri Mar 30 08:20:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D531E21F8671 for ; Fri, 30 Mar 2012 08:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqZ1Q0WN74GR for ; Fri, 30 Mar 2012 08:20:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B945421F8667 for ; Fri, 30 Mar 2012 08:20:25 -0700 (PDT) Received: by yenm5 with SMTP id m5so440106yen.31 for ; Fri, 30 Mar 2012 08:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FQmdQ2/PnJ8KhabBM84+K0GQPBOcVYntXsqtOCzDbbQ=; b=C3UL4jONgt7WPQ893fQSYrE38twGPpF1mKeChz7yfuHmS82fpFC8YFoO7skc1excPJ Om1LAqKtcr+93qlxvWR+gDJfkaqanQ8RLDAJQ9YzjYcuCYC8LooFcIN1b3kxDuoKUtQv uBqZTPYqFmZTVHsN+CDbkrWbC7/yfZLiKgW2iCD+8j2W684J0VXaP3FzSIlWTG4+Jz/p 3mgmHCw487ijSG0CXxl3o2YskWBcknG5vRmAP+X1lpnk7uOpFnfsozLRVx39PE6HfueM lqzEDytN3/Tm8TIBQktJrBXijmA3+Wg/yDl/7S6mwPLifAayOv2YINAPS300JTjNppn4 zYgQ== Received: by 10.236.170.165 with SMTP id p25mr2257648yhl.123.1333120825270; Fri, 30 Mar 2012 08:20:25 -0700 (PDT) Received: from europa.local ([200.7.85.168]) by mx.google.com with ESMTPS id q44sm13975084yhg.3.2012.03.30.08.20.22 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 08:20:24 -0700 (PDT) Message-ID: <4F75CF32.9080406@gmail.com> Date: Fri, 30 Mar 2012 12:20:18 -0300 From: Carlos Martinez-Cagnazzo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tim Bruijnzeels References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org list" Subject: Re: [sidr] rpki repository and validation issues X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:20:27 -0000 Tim, thanks for summing things up so clearly. I basically agree with you on all points, however I have one comment. When you say: > = It should be detectable for an RP if it does not get all the data a CA intended to publish I've always believed that this was the whole point of the manifest. The repository should contain exactly the same objects that are listed in the mft, otherwise the whole retrieved repo copy cannot be trusted. I understand that just discarding the whole repository can be too harsh and lead to unstable situations, but as I understand it, the mechanism for an RP to detect whether the repository was fully retrieved is already in place. As for doing shared / cooperative measurements, I'm all for it. regards Carlos On 3/30/12 12:08 PM, Tim Bruijnzeels wrote: > Hi, > > There are a number of separate discussions about problems with the rpki repository and ways to mitigate those problems going on on the list at the moment. > > First of all let me say: as a starting point the current system works most of the time, but we are finding issues that I think should be fixed, that are not trivial. > > So my take on this is that we've learned from operational experience and it would now be good to (1) enumerate the problems that we see, and (2) refine a list of requirements for improvement, and then (3) find ways forward to address these requirements, without breaking the existing infrastructure. As some of you know from discussions we had I do actually have some ideas in the solution space, but.. before going there in detail (beyond proof of concept) I think the WG should address 1 & 2.. > > It may be best if we could discuss this face to face, eg at one of the upcoming interim meetings. I am not a huge fan of interim meetings, but I am afraid this is a difficult subject to find consensus on on the list, and too big to discuss in a 2 hour IETF slot. My preference would be to discuss this in the planned meeting just before the Vancouver IETF: I am already planning to travel to that one, and I expect it will be the easiest to attend for most people. > > > Since I don't know if and when this will happen though, let me write down my ideas, without going to solution space where I think face to face or at least interactive presentations are most needed to make progress. > > > 1 = Current problems we encounter (implementing a validator and running a publication point): > > = Updates happen while we are rsync'ing from the validator: > = We may miss objects that are on the manifest > = We may find objects that are not on the manifest (we actually ignore these) > = The CRL may be newer and revoke this MFT > = The MFT may be newer and the CRL hash value is wrong > > All this makes it very difficult for the RP to make clear automated validation decisions. > And we all know that *no one* reads the logs... or even if they do, most people won't know how to decide.. > > = PFX-validate assumes knowledge of *all* applicable ROAs, but the RP may not get all data > = The only way an RP can detect this is by looking at the manifest. > = But the manifest is considered, at least by people I talk to, to not be authoritative on this. > = The reason why a ROA might be missing is not clear to the RP > = A man in the middle may filter bits of information (hold back ROA, MFT, CRL) > = There may be a bug in the CA > = There may be a bug or problem at the publisher (eg someone *deleted* the ROA on disk) > = There may be a race condition - stuff is changing while we look, as described above > > = We need to call 'rsync' on the system (there is only one implementation, libraries unavailable for most coding languages) > = Forks cause cpu overhead and may (temporarily) result in duplicating the memory usage (at least for jvm) > = Parallel processing requiring system calls does not scale > = We need rsync installed and on the path > = We need to like that version > = We need to make sense of exit codes to have useful error messages and take action (or inform user) > > = Publication point availability > = We don't know of any commercial CDNs that do rsync > = Doing this ourselves by having multiple rsync servers (and eg anycast) is not trivial > = An RP possibly ending up on different (out of sync) mirror servers, and getting inconsistent responses, does not help > = To avoid load on back-ends the general advice to RPs has been to not be too aggressive, even though they 'want' fresh data > > = Local policy knobs in validation > = The absence of sensible defaults make it difficult to automate validation > = Uncertainty here, for implementers, is even worse for end user: they really just want to know: > "so, is this thing *valid*, or not?" > = Giving them a knob confuses them and lowers the trust in this system > > > These are my major findings at least. There may be more. With regards to the hierarchical repository lay-out, or absence thereof causing issues. Our validator gets around that by having additional configuration for the RIR TAs to do additional pre-fetching of the repositories. This helps, so yes, either this work-around or a change in those repository lay-outs would help RPs. Having said that, the problems that I enumerated above remain in my opinion. > > > Chris suggested that we do some more coordinated measurements. I think this is an excellent idea and I would like to help with this effort. If possible it would be very worthwhile to get some quantifiable sense of the issues. Apart from monitoring over time, it would also be interesting to do some aggressive testing, like load stressing a publication point, set up a large, high churn, test repository, or set up different validators to update far more often (like every few minutes) and see what breaks. > > > > 2 = Possible requirements for moving forward: > > This is not a complete or final list of course. I am very interested in your additions. Even thought there may be requirements that we're not able to meet, there is still value in listing them and deciding.. > > = New schemes should iterate on existing infrastructure without breaking it > = If more than one retrieval mechanism is allowed, then *objects* should be uniquely identifiable > = Inconsistent data to relying parties should be prevented > = It should be detectable for an RP if it does not get all the data a CA intended to publish > = Protocols should be ubiquitous with regards to support in coding languages > = Update semantics and protocol should allow for distributed caching > = Local policy knobs because of validation uncertainties should be avoided as much as possible > > > > > > > Regards, > > Tim > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Fri Mar 30 08:27:12 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C209F21F84D2 for ; Fri, 30 Mar 2012 08:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHb4dMkwyII4 for ; Fri, 30 Mar 2012 08:27:12 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E97A821F84D1 for ; Fri, 30 Mar 2012 08:27:11 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 8F7A4268063; Fri, 30 Mar 2012 09:27:11 -0600 (MDT) Received: from [192.168.1.7] (134.sub-166-248-35.myvzw.com [166.248.35.134]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Fri, 30 Mar 2012 09:27:11 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=166.248.35.134; client-port=10720; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Danny McPherson In-Reply-To: <20120329081625.GA9609@slice> Date: Fri, 30 Mar 2012 11:26:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B939BBC-D24A-4A18-BF29-A9515A45C178@tcb.net> References: <20120328081939.GA19843@slice> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> To: sidr wg list X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 15:27:12 -0000 On Mar 29, 2012, at 4:16 AM, Jeffrey Haas wrote: > Just to be clear, this is not a route freshness mechanism I am > recommending. What I am recommending is a signal that a repository = has > newer data that may be needed for validation. >=20 > Given such a mechanism, we may be able to reduce the work upon the > repository mirroring system (distributed or not) by not having to = regularly > poll for new objects frequently unless the repository indicates there = is new > data present. And again, why would this not be done in the repository system (RPKI)? = It does NOT belong in the routing system. -danny From sra@hactrn.net Fri Mar 30 11:10:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3612821F8625 for ; Fri, 30 Mar 2012 11:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwHft2+Q7Mqn for ; Fri, 30 Mar 2012 11:10:22 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2928321F8622 for ; Fri, 30 Mar 2012 11:10:21 -0700 (PDT) Received: from minas-ithil.hactrn.net (ter75-1-81-57-68-77.fbx.proxad.net [81.57.68.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 1874428465 for ; Fri, 30 Mar 2012 18:10:19 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id A9BE46EFC01 for ; Fri, 30 Mar 2012 20:10:17 +0200 (CEST) Date: Fri, 30 Mar 2012 20:10:17 +0200 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4F75B916.6000807@gmail.com> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> <4F75B916.6000807@gmail.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: <20120330181017.A9BE46EFC01@minas-ithil.hactrn.net> Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:10:23 -0000 While I will admit to some astonishment that the following explanation could possibly be news to long-time participants in this WG (given how much time I've spent whining about this issue over the last five years or so both in public and in private), let me quote from the slides: * How efficient [fetching RPKI repositories using rsync] is depends heavily on how the publication repositories are organized. * In an efficiently organized repository, filesystem hierarchy follows X.509 certificate hierarchy, so that one can pick up significant subtrees with a single rsync connection. * To date, the RIRs have chosen to deploy flat hierarchies where there is no relationship at all between filesystem hierarchy within the repository and certificate hierarchy. To make that more concrete, here's an example. Let's assume we have the following trivial hierarchy: Bob and Betty are issued by Alice, Carol and Carl are issued by Bob, Dave, and Dana are issued by Carol, Dara is issued by Carl, and and all of these are hosted in a single repository. In an inefficient, "flat" repository, the publication points for objects issued by these entities would look something like this: rsync://example.org/rpki/Alice/ rsync://example.org/rpki/Betty/ rsync://example.org/rpki/Bob/ rsync://example.org/rpki/Carl/ rsync://example.org/rpki/Carol/ rsync://example.org/rpki/Dana/ rsync://example.org/rpki/Dara/ rsync://example.org/rpki/Dave/ In a hierarchical repository, the same publication points would look more like this: rsync://example.org/rpki/Alice/ rsync://example.org/rpki/Alice/Betty/ rsync://example.org/rpki/Alice/Bob/ rsync://example.org/rpki/Alice/Bob/Carl/ rsync://example.org/rpki/Alice/Bob/Carl/Dara/ rsync://example.org/rpki/Alice/Bob/Carol/ rsync://example.org/rpki/Alice/Bob/Carol/Dana/ rsync://example.org/rpki/Alice/Bob/Carol/Dave/ Assuming top-down tree walk (the normal case), retrieving objects issued by this set of entities takes eight rsync connections with the flat repository, as opposed to one rsync connection with the hierarchical repository. In practice one might want a slightly more complex structure to limit the size of individual directories, but it doesn't matter so long as the filesystem hierarchy is organized in such a way that picking up an issuer's publication point picks up a non-trivial number of its subjects' publication points automatically. It doesn't have to be perfect, just has to do enough better than the flat model to amortize the cost of setting up and tearing down the rsync connection over a significantly larger number of files. This is not about PKI, it's purely an rsync efficiency issue. Presumably there are scaling limitations to the hierarchical approach, but anecdotal evidence among the people I've asked ("I tried ... and it worked") suggests that, if the underlying networks and filesystems are in good shape, a single rsync connection ought to be able to handle up to at least 10,000 small files, perhaps a lot more than that. Note that this is just talking about rsync itself: mileage might vary significantly if the underlying networks or filesystems are seriously broken. Also note that these anecdotal estimates have not been tested in any rigorous fashion as far as I know, so that's another entry on my list of things we ought to be measuring. Hope this helps to clarify the change I've been suggesting. From kvaradhan3@gmail.com Fri Mar 30 17:14:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B1C21F86CA for ; Fri, 30 Mar 2012 17:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYJKsn5sDcVc for ; Fri, 30 Mar 2012 17:14:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40F8E21F86C3 for ; Fri, 30 Mar 2012 17:14:24 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2402627pbb.31 for ; Fri, 30 Mar 2012 17:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E+KLmAddmfmJerMV/63a20dqV96pW5KLhr9kVEktXME=; b=LBD0JWVesMKAmfksIGzL7SuWwVxxkU21DN4QUj8oITroXjvmQ8b5erzDIshB+q1xOY qV64UU9Labzj1zJSeHgtL+kk643BW9jgxKRi5/no/HHr9Ap4JQ5SU/xhenenIFTFzMTV 9XZ1Rx4iBlbNt9rYJ9LqQxnzYms+pefm13QbwE9zEuwTQOdzdtJy7h/KB194XDM8Y/a4 npSHbXta0UwPyv8tkG1dW0tNPwGgQ1wPmrSuB5mTKKt1gfJAr2FxXzv+TJPd6x0TxA15 E0QCfRw/lyR1IJfrTaUWSIx5iqGfVQa1vNtNXbiPVbTc6ocsM3lVlyLJ2ZrDTh0SR51d UPTg== Received: by 10.68.226.227 with SMTP id rv3mr1428906pbc.65.1333152864119; Fri, 30 Mar 2012 17:14:24 -0700 (PDT) Received: from [10.155.34.248] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id 6sm8396247pbh.65.2012.03.30.17.14.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 17:14:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Kannan Varadhan In-Reply-To: Date: Fri, 30 Mar 2012 17:14:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20336.45627.147578.984228@oz.mt.att.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1257) Cc: sidr wg list Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 00:14:25 -0000 On Mar 28, 2012, at 10:07 AM, Pradosh Mohapatra wrote: > Hi Jay, >=20 >=20 >>> at this afternoon's sidr ssion, i presented two open issue with >>> draft-ietf-sidr-pfx-validate-04.txt >>>=20 >>> 1 - Should updates learned via iBGP be marked? >>>=20 >>> 2 - Should updates injected into BGP on this router be marked? >>>=20 >>> i think yes because: >>> o i want support of incremental deployment >>> o i do not want to find out I am announcing garbage when my = neighbor=1B$,1ry=1B(Bs >>> NOC calls, mis-originations should be stopped at the source >>>=20 >>> there was fear that, if used at other than edge routers, this = allowed >>> creation of loops, as setting local pref etc, do. >>>=20 >>> i think there was general agreement that this was ok on edge routers >>> and the point of injection, as that is logically an edge router. >>>=20 >>> would like to see convergence on this >>=20 >>=20 >> I could not hear the discussion in the room today because the utter >> webex fail prevented my remote participation. So let me ask about >> today's discussion. >>=20 >> Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than = just >> at ingress edge routers, and if the policy is broken it can result in >> loops. It's something to watch out for when designing a policy, but = I >> am thankful that this kind of flexibility exists, because not all >> policies that manipulate attributes other than at ingress edges are >> broken. >>=20 >> Regarding pfx-validate: >>=20 >> I hope the agreement in the room was that a sane network design would >> probably involve setting a local 'origin has been checked' community >> on the first router inside the AS where that check occurred. >=20 >=20 > like draft-ietf-sidr-origin-validation-signaling ? >=20 >=20 >>=20 >> I hope the agreement was _not_ that pfx-validate implementations >> should be hard-coded to assess validation state only at the ingress >> edge router. >=20 >=20 > I couldn't go to IETF either. The argument is over what the default > behavior should be (spec'ed). My vote is that origin validation should > NOT be performed on IBGP learnt prefixes by default as there is = potential > for loops and inconsistency. For everything else, there are knobs. Given that this is trying to enable "security" hooks, I'd argue that the = default should be for a router to behave as if it would validate all = prefixes at a router, including those learned via iBGP. THis would = allow for an implementation to work in conjunction with the = origin-validation-signalling to optimize iBGP handling as appropriate. This would allow not just the incremental deployment scenarios, but also = behaves correctly if a router in the AS were misconfigured and leaked = invalidated prefixes---in those cases, only the misconfigured router is = affected, and all other routers would behave as expected. The only scenario where I see the possibility for loops or other bad = behaviors would be if a router learned of two prefixes, one known good = and one bad according to its ROA database, and some of the other routers = in the AS were not doing prefix validation. In such as case, it seems = to be a good thing to actually admit that scenario and correct for it. Kannan= From Sandra.Murphy@sparta.com Fri Mar 30 21:12:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5D21F84EA for ; Fri, 30 Mar 2012 21:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjV4Pkl0N193 for ; Fri, 30 Mar 2012 21:12:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 64BDA21F84D7 for ; Fri, 30 Mar 2012 21:12:14 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q2V4CCw0020661; Fri, 30 Mar 2012 23:12:12 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q2V4CBgE029895; Fri, 30 Mar 2012 23:12:11 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 00:12:11 -0400 From: "Murphy, Sandra" To: Brian Dickson Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Thread-Index: AQHMmCOt1CW4b+qPEkuJdphkZ9jq2pWXZE2AgAREVgCAOHGKgICup3EAgAAQjACAAEXWgIAAU6pDgACP7YCAALqctQ== Date: Sat, 31 Mar 2012 04:12:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com> References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625Hermescolumbiaa_" MIME-Version: 1.0 Cc: Chris Morrow , "Sriram, Kotikalapudi" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 04:12:25 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625Hermescolumbiaa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable speaking as regular ol' member I'm not really sure what you are talking about here. You speak of bgpsec and signing - that is not origin validation, that is pa= th validation. Origin validation is strictly and only judging whether the origin has the a= uthority to originate announcements of the prefix. Origin validation does = not ensure that the authorized AS is actually making the announcement. It is bgpsec path validation that ensures that the announcement is currentl= y and authentically being announced by the AS. That's the "signed injectio= n" you mention. --Sandy ________________________________ From: Brian Dickson [brian.peter.dickson@gmail.com] Sent: Friday, March 30, 2012 8:55 AM To: Murphy, Sandra Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr@ietf.org l= ist Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Sandy, The use case example I included, is an origin validation use case. The problem is the inability to have "origination" (signed injection into B= GPSEC) done by proxy, at all or especially by more than one party. The particular situation leading to the need for this, would be a stub AS w= hose router vendor does not support BGPSEC, or whose router hardware or cod= e base is not included in BGPSEC support by their router vendor. (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by operat= ors.) This is likely to be a fairly common situation _among stub AS_ and, given t= he current requirement for origin injection for BGPSEC, addressing this _ma= y_ impact the use cases document, for _origin validation_. I'm just saying... Brian On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra > wrote: Brian, Chris. The usecases draft was intended to describe origin validation use cases. Route leaks (and other path validation issues) might need their own usecase= s draft. But I don't think we should add those cases to this draft. --Sandy ________________________________________ From: christopher.morrow@gmail.com [ch= ristopher.morrow@gmail.com] on behalf = of Christopher Morrow [morrowc.lists@gmail.com] Sent: Thursday, March 29, 2012 7:21 PM To: Brian Dickson Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; sid= r@ietf.org list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > wrote= : > I think the use cases are likely to be informed by protocol design, so ev= en s/informed by protocol design/altered if the protocol design changes/ I'm not sure if the protocol design's going to change the use-cases... you're still going to want to secure a route. (not an important point) > I have a few examples that I can think of, which would necessarily depend > I'd prefer this to be added to a "raft" of IDs, for which there is no rus= h > to publish until they are all completed, after which the timing would be > appropriate. I'm not against this, though we've got a document hanging out post WGLC (perhaps it ought to be re-reviewed if the changes were significant... anyway) and we'll have to keep kicking it each 5.5 months to stay 'alive'. (again, not super important, and see below as well) > Here's an example of use-case, which depends on certain assumptions (whic= h > may or may not be appropriate, but which are fodder for discussion): > > Suppose there is an Edge-AS "E", and transit providers to "E", which woul= d > be "X" and "Y". > > Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing > done "for her", by "X" and "Y". > > (Ignore for the moment that the _current_ designs don't support that, tha= t > is an entirely other rat-hole for the moment.) hrm, in: section-6 there's discussion of 'only sign your one prefix, do nothing else complex' which fits the model, albeit requiring the end site to run some small number of commands on their device. If they wanted to hand their private key materials to the upstreams they could do the signing, but that seems icky (to me). I don't know that, if implications are understood by the end site and configurations available for use on their side, end-sites would want to hand over control of their IP assets in this way. Running the signing on their side should be simple enough, and low/no-cost. > And publishing something IMHO prematurely, locks the WG into that RFC, > making revising it much harder, than if it were still in-WG and > not-yet-published. I think the authors said something like: "send text" where you think it is fit to be inserted... If other folks want to delay/re-review they need to speak up. Consensus so far was that the document was ready to move along. -chris --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625Hermescolumbiaa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    speaking as regular ol' member

    I'm not really sure what you are talking about here.

    You speak of bgpsec and signing - that is not origin validation, that is pa= th validation.

    Origin validation is strictly and only judging whether the origin has the a= uthority to originate announcements of the prefix.  Origin validation = does not ensure that the authorized AS is actually making the announcement.=

    It is bgpsec path validation that ensures that the announcement is currentl= y and authentically being announced by the AS.  That's the "signe= d injection" you mention.

    --Sandy

    From: Brian Dickson [brian.peter.dickson@= gmail.com]
    Sent: Friday, March 30, 2012 8:55 AM
    To: Murphy, Sandra
    Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr@iet= f.org list
    Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

    Sandy,

    The use case example I included, is an origin validation use case.

    The problem is the inability to have "origination" (signed i= njection into BGPSEC) done by proxy, at all or especially by more than one = party.

    The particular situation leading to the need for this, would be a stub= AS whose router vendor does not support BGPSEC, or whose router hardware o= r code base is not included in BGPSEC support by their router vendor.

    (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by o= perators.)

    This is likely to be a fairly common situation _among stub AS_ and, gi= ven the current requirement for origin injection for BGPSEC, addressing thi= s _may_ impact the use cases document, for _origin validation_.

    I'm just saying...

    Brian

    On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra = <Sandra.Mu= rphy@sparta.com> wrote:
    Brian, Chris.

    The usecases draft was intended to describe origin validation use cases.
    Route leaks (and other path validation issues) might need their own usecase= s draft.

    But I don't think we should add those cases to this draft.

    --Sandy

    ________________________________________
    From: chr= istopher.morrow@gmail.com [christopher.morrow@gmail.com] on behalf of Christ= opher Morrow [= morrowc.lists@gmail.com]
    Sent: Thursday, March 29, 2012 7:21 PM
    To: Brian Dickson
    Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; sidr@ietf.org list
    Subject: Re: [sidr] I-D Action: draft-ietf-sidr-us= ecases-03.txt

    On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
    <bria= n.peter.dickson@gmail.com> wrote:

    > I think the use cases are likely to be informed by protocol design, so= even

    s/informed by protocol design/altered if the protocol design changes/

    I'm not sure if the protocol design's going to change the use-cases...
    you're still going to want to secure a route. (not an important point)

    > I have a few examples that I can think of, which would necessarily dep= end
    <snip>
    > I'd prefer this to be added to a "raft" of IDs, for which th= ere is no rush
    > to publish until they are all completed, after which the timing would = be
    > appropriate.

    I'm not against this, though we've got a document hanging out post
    WGLC (perhaps it ought to be re-reviewed if the changes were
    significant... anyway) and we'll have to keep kicking it each 5.5
    months to stay 'alive'. (again, not super important, and see below as
    well)

    > Here's an example of use-case, which depends on certain assumptions (w= hich
    > may or may not be appropriate, but which are fodder for discussion): >
    > Suppose there is an Edge-AS "E", and transit providers to &q= uot;E", which would
    > be "X" and "Y".
    >
    > Suppose "E" does not do BGPSEC (per se), but wants to have B= GPSEC signing
    > done "for her", by "X" and "Y".
    >
    > (Ignore for the moment that the _current_ designs don't support that, = that
    > is an entirely other rat-hole for the moment.)

    hrm, in:

     <http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-ops= -04.txt>

    section-6 there's discussion of 'only sign your one prefix, do nothing
    else complex' which fits the model, albeit requiring the end site to
    run some small number of commands on their device. If they wanted to
    hand their private key materials to the upstreams they could do the
    signing, but that seems icky (to me).

    I don't know that, if implications are understood by the end site and
    configurations available for use on their side, end-sites would want
    to hand over control of their IP assets in this way. Running the
    signing on their side should be simple enough, and low/no-cost.

    > And publishing something IMHO prematurely, locks the WG into that RFC,=
    > making revising it much harder, than if it were still in-WG and
    > not-yet-published.

    I think the authors said something like: "send text" where you th= ink
    it is fit to be inserted... If other folks want to delay/re-review
    they need to speak up. Consensus so far was that the document was
    ready to move along.

    -chris

    --_000_24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625Hermescolumbiaa_-- From kotikalapudi.sriram@nist.gov Sat Mar 31 13:35:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6B821F8743 for ; Sat, 31 Mar 2012 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GslT5DqXJ1kk for ; Sat, 31 Mar 2012 13:35:33 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0D21F871E for ; Sat, 31 Mar 2012 13:35:33 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 16:35:12 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sat, 31 Mar 2012 16:31:12 -0400 From: "Sriram, Kotikalapudi" To: Brian Dickson Date: Sat, 31 Mar 2012 16:31:12 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Thread-Index: AQHMmCOt1CW4b+qPEkuJdphkZ9jq2pWXZE2AgAREVgCAOHGKgICup3EAgAAQjACAAEXWgIAAU6pDgACP7YCAALqctYAA+A2i Message-ID: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com>, , <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Chris Morrow , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 20:35:34 -0000 Brian, There is a clear distinction between =93prefix-origin validation=94 (based = on ROA information)=20 and "origination (signed injection into BGPSEC)" in the SIDR working group'= s usage of these terms.=20 You seem to be attempting to use these two terms with the same connotation.= =20 Your comments clearly pertain to path signing. You seem to be especially co= ncerned about=20 path signing by a stub origin AS or by a proxy AS (e.g., the stub AS's upst= ream transit provider).=20 Draft-ietf-sidr-usecases I-D documents use cases relating only to =93prefix= -origin validation=94. A use-cases document for the path signing would be a separate document;=20 as far as I know no one is working on it at the moment.=20 So your comments seem misplaced, i.e., they appear not relevant to draft-ie= tf-sidr-usecases.=20 Please also see my response in my other post that follows this post, but wi= th the subject: stub AS and proxy signing.=20 Thank you. Sriram =20 > > To: Brian Dickson > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > From: "Murphy, Sandra" > Date: Sat, 31 Mar 2012 04:12:10 +0000 > > speaking as regular ol' member > > I'm not really sure what you are talking about here. > > You speak of bgpsec and signing - that is not origin validation, that > is path validation. > > Origin validation is strictly and only judging whether the origin has > the authority to originate announcements of the prefix. =A0Origin > validation does not ensure that the authorized AS is actually making > the announcement. > > It is bgpsec path validation that ensures that the announcement is > currently and authentically being announced by the AS. =A0That's the > "signed injection" you mention. > > --Sandy > > From: Brian Dickson [brian.peter.dickson at gmail.com] > Sent: Friday, March 30, 2012 8:55 AM > To: Murphy, Sandra > Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at > ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > Sandy, > > The use case example I included, is an origin validation use case. > > The problem is the inability to have "origination" (signed injection > into BGPSEC) done by proxy, at all or especially by more than one > party. > > The particular situation leading to the need for this, would be a stub > AS whose router vendor does not support BGPSEC, or whose router > hardware or code base is not included in BGPSEC support by their > router vendor. > > (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by oper= ators.) > > This is likely to be a fairly common situation _among stub AS_ and, > given the current requirement for origin injection for BGPSEC, > addressing this _may_ impact the use cases document, for _origin > validation_. > > I'm just saying... > > Brian > > On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra sparta.com> wrote: > Brian, Chris. > > The usecases draft was intended to describe origin validation use cases. > > Route leaks (and other path validation issues) might need their own > usecases draft. > > But I don't think we should add those cases to this draft. > > --Sandy > > ________________________________________ > From: christopher.morrow at gmail.com [christopher.morrow at > gmail.com] on behalf of Christopher Morrow [morrowc.lists at > gmail.com] > Sent: Thursday, March 29, 2012 7:21 PM > To: Brian Dickson > > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > wrote: > >> I think the use cases are likely to be informed by protocol design, so e= ven > > s/informed by protocol design/altered if the protocol design changes/ > > I'm not sure if the protocol design's going to change the use-cases... > you're still going to want to secure a route. (not an important point) > >> I have a few examples that I can think of, which would necessarily depen= d > >> I'd prefer this to be added to a "raft" of IDs, for which there is no ru= sh >> to publish until they are all completed, after which the timing would be >> appropriate. > > I'm not against this, though we've got a document hanging out post > WGLC (perhaps it ought to be re-reviewed if the changes were > significant... anyway) and we'll have to keep kicking it each 5.5 > months to stay 'alive'. (again, not super important, and see below as > well) > >> Here's an example of use-case, which depends on certain assumptions (whi= ch >> may or may not be appropriate, but which are fodder for discussion): >> >> Suppose there is an Edge-AS "E", and transit providers to "E", which wou= ld >> be "X" and "Y". >> >> Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signin= g >> done "for her", by "X" and "Y". >> >> (Ignore for the moment that the _current_ designs don't support that, th= at >> is an entirely other rat-hole for the moment.) > > hrm, in: > > =A0 > > section-6 there's discussion of 'only sign your one prefix, do nothing > else complex' which fits the model, albeit requiring the end site to > run some small number of commands on their device. If they wanted to > hand their private key materials to the upstreams they could do the > signing, but that seems icky (to me). > > I don't know that, if implications are understood by the end site and > configurations available for use on their side, end-sites would want > to hand over control of their IP assets in this way. Running the > signing on their side should be simple enough, and low/no-cost. > >> And publishing something IMHO prematurely, locks the WG into that RFC, >> making revising it much harder, than if it were still in-WG and >> not-yet-published. > > I think the authors said something like: "send text" where you think > it is fit to be inserted... If other folks want to delay/re-review > they need to speak up. Consensus so far was that the document was > ready to move along. > > -chris= From brian.peter.dickson@gmail.com Sat Mar 31 14:09:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8D21F8702 for ; Sat, 31 Mar 2012 14:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnMvdFI3Ayv3 for ; Sat, 31 Mar 2012 14:09:26 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 301A521F86F7 for ; Sat, 31 Mar 2012 14:09:26 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1071148wgb.13 for ; Sat, 31 Mar 2012 14:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKLotcoQa8UeH+BQVxWyVIPFz9o1Tk9HbAmdwIuCqUk=; b=Z8rqwgngZ31DbQetaYqhkZZKv3K8zvl+2e4x1gZRKcRO0pFnFXEVgT3fya964TgtPC 0ebN3/jtvgYYv0lka3pPcyXpJezToIyH8LseGztOa8irc71VenX9ehkf09kafSYVaoAA jj7DOBSNJtM2bl4TSD1myY2/pFsgw3g8l6VUk7zhRbe4VTYeDlVhG7TZnd+JbmLDuZjs DsxC6BtXP80VDshcuYJVoX6dA8yHncgC3OYzX+Mg1z/vtfR7s8kMxAPnSU9wDpjB51QN JXmDKouxhCeRlCFBiOOmG7vqAZrGLFjV0kwJDTQQAkKf6py25KQBhgkuFiV92ckhRDDE W4Iw== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr11673754wib.3.1333228165317; Sat, 31 Mar 2012 14:09:25 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Sat, 31 Mar 2012 14:09:25 -0700 (PDT) In-Reply-To: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com> Date: Sat, 31 Mar 2012 17:09:25 -0400 Message-ID: From: Brian Dickson To: "Sriram, Kotikalapudi" Content-Type: multipart/alternative; boundary=f46d04426f1432c35304bc905fdd Cc: Chris Morrow , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 21:09:28 -0000 --f46d04426f1432c35304bc905fdd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sriram, and Sandy, Yes, and no, on the question of whether this is an origin-validation or path-validation issue. Actually, that is where the problem originates, if you forgive the double meaning. Both the protocol spec (for bgpsec) and the use-cases, and all of the particulars of the RPKI design, require all the pertinent details to be aligned. If you consider what the current draft of the protocol spec says, specifically on sections 4.1 and 5.1, about originating, and validating origination, it specifically references ROA from RPKI. What this means is, that any change to where bgpsec "begins" signatures, will necessarily require revisiting ROA components or structures or whatever, which then require revisiting anything that refers to those ROAs, which includes pretty much everything on the origin-validation front. It is all fine and well to do origin-validation based on BGP origination, but since the current design of bgpsec is anchored to (vanilla, non-sec) BGP origination as well, this means identifying affected elements when challenging the bgpsec design. And, what I'm suggesting is, that restricting bgpsec deployment to only origin AS operators who deploy bgpsec (i.e. excluding proxy injection into bgpsec from non-bgpsec origins), is not something the operator community is likely to accept with open arms. There are too many edge ASNs today, using too many vendors' equipment with too many varieties of equipment within vendors, and too varied code base, to believe rapid uptake or critical mass is feasible in the timeline the WG participants might like to believe. And I don't believe the opinions of participants in the WG is sufficient to say yay or nay to the current assumption. So, it is only a consequence of other decisions, that use-cases is touched on. However, that it is, is provable by simple classic logic. A->B and B->C, when combined with !C, means !B, means !A. Here, C is edge-ASNs doing BGPSEC, B is ROAs exclusively tied to BGP origin ASNs, and A is use-cases as currently enumerated. The document, other than the corner cases such as this (proxy origination on the bgpsec side), is fine. Brian On Sat, Mar 31, 2012 at 4:31 PM, Sriram, Kotikalapudi < kotikalapudi.sriram@nist.gov> wrote: > Brian, > > There is a clear distinction between =93prefix-origin validation=94 (base= d on > ROA information) > and "origination (signed injection into BGPSEC)" in the SIDR working > group's usage of these terms. > You seem to be attempting to use these two terms with the same connotatio= n. > Your comments clearly pertain to path signing. You seem to be especially > concerned about > path signing by a stub origin AS or by a proxy AS (e.g., the stub AS's > upstream transit provider). > Draft-ietf-sidr-usecases I-D documents use cases relating only to > =93prefix-origin validation=94. > A use-cases document for the path signing would be a separate document; > as far as I know no one is working on it at the moment. > So your comments seem misplaced, i.e., they appear not relevant to > draft-ietf-sidr-usecases. > Please also see my response in my other post that follows this post, but > with the subject: > stub AS and proxy signing. > Thank you. > > Sriram > > > > > To: Brian Dickson > > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > From: "Murphy, Sandra" > > Date: Sat, 31 Mar 2012 04:12:10 +0000 > > > > speaking as regular ol' member > > > > I'm not really sure what you are talking about here. > > > > You speak of bgpsec and signing - that is not origin validation, that > > is path validation. > > > > Origin validation is strictly and only judging whether the origin has > > the authority to originate announcements of the prefix. Origin > > validation does not ensure that the authorized AS is actually making > > the announcement. > > > > It is bgpsec path validation that ensures that the announcement is > > currently and authentically being announced by the AS. That's the > > "signed injection" you mention. > > > > --Sandy > > > > From: Brian Dickson [brian.peter.dickson at gmail.com] > > Sent: Friday, March 30, 2012 8:55 AM > > To: Murphy, Sandra > > Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at > > ietf.org list > > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > > > Sandy, > > > > The use case example I included, is an origin validation use case. > > > > The problem is the inability to have "origination" (signed injection > > into BGPSEC) done by proxy, at all or especially by more than one > > party. > > > > The particular situation leading to the need for this, would be a stub > > AS whose router vendor does not support BGPSEC, or whose router > > hardware or code base is not included in BGPSEC support by their > > router vendor. > > > > (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by > operators.) > > > > This is likely to be a fairly common situation _among stub AS_ and, > > given the current requirement for origin injection for BGPSEC, > > addressing this _may_ impact the use cases document, for _origin > > validation_. > > > > I'm just saying... > > > > Brian > > > > On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra > sparta.com> wrote: > > Brian, Chris. > > > > The usecases draft was intended to describe origin validation use cases= . > > > > Route leaks (and other path validation issues) might need their own > > usecases draft. > > > > But I don't think we should add those cases to this draft. > > > > --Sandy > > > > ________________________________________ > > From: christopher.morrow at gmail.com [christopher.morrow at > > gmail.com] on behalf of Christopher Morrow [morrowc.lists at > > gmail.com] > > Sent: Thursday, March 29, 2012 7:21 PM > > To: Brian Dickson > > > > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson > > wrote: > > > >> I think the use cases are likely to be informed by protocol design, so > even > > > > s/informed by protocol design/altered if the protocol design changes/ > > > > I'm not sure if the protocol design's going to change the use-cases... > > you're still going to want to secure a route. (not an important point) > > > >> I have a few examples that I can think of, which would necessarily > depend > > > >> I'd prefer this to be added to a "raft" of IDs, for which there is no > rush > >> to publish until they are all completed, after which the timing would = be > >> appropriate. > > > > I'm not against this, though we've got a document hanging out post > > WGLC (perhaps it ought to be re-reviewed if the changes were > > significant... anyway) and we'll have to keep kicking it each 5.5 > > months to stay 'alive'. (again, not super important, and see below as > > well) > > > >> Here's an example of use-case, which depends on certain assumptions > (which > >> may or may not be appropriate, but which are fodder for discussion): > >> > >> Suppose there is an Edge-AS "E", and transit providers to "E", which > would > >> be "X" and "Y". > >> > >> Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC > signing > >> done "for her", by "X" and "Y". > >> > >> (Ignore for the moment that the _current_ designs don't support that, > that > >> is an entirely other rat-hole for the moment.) > > > > hrm, in: > > > > > > > > section-6 there's discussion of 'only sign your one prefix, do nothing > > else complex' which fits the model, albeit requiring the end site to > > run some small number of commands on their device. If they wanted to > > hand their private key materials to the upstreams they could do the > > signing, but that seems icky (to me). > > > > I don't know that, if implications are understood by the end site and > > configurations available for use on their side, end-sites would want > > to hand over control of their IP assets in this way. Running the > > signing on their side should be simple enough, and low/no-cost. > > > >> And publishing something IMHO prematurely, locks the WG into that RFC, > >> making revising it much harder, than if it were still in-WG and > >> not-yet-published. > > > > I think the authors said something like: "send text" where you think > > it is fit to be inserted... If other folks want to delay/re-review > > they need to speak up. Consensus so far was that the document was > > ready to move along. > > > > -chris > --f46d04426f1432c35304bc905fdd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Sriram, and Sandy,

    Yes, and no, on the question of = whether this is an origin-validation or path-validation issue.
    Actually, that is where the problem originates, if you forgive= the double meaning.

    Both the protocol spec (for bgpsec) and the use-cases, = and all of the particulars of the RPKI design,
    require all the pe= rtinent details to be aligned.

    If you consider wha= t the current draft of the protocol spec says, specifically on sections 4.1= and 5.1,
    about originating, and validating origination, it specifically referen= ces ROA from RPKI.

    What this means is, that any ch= ange to where bgpsec "begins" signatures, will necessarily requir= e
    revisiting ROA components or structures or whatever, which then requir= e revisiting anything that
    refers to those ROAs, which includes p= retty much everything on the origin-validation front.

    It is all fine and well to do origin-validation based on BGP originati= on, but since the current design
    of bgpsec is anchored to (vanill= a, non-sec) BGP origination as well, this means identifying affected
    elements when challenging the bgpsec design.

    = And, what I'm suggesting is, that restricting bgpsec deployment to only= origin AS operators who deploy
    bgpsec (i.e. excluding proxy inje= ction into bgpsec from non-bgpsec origins), is not something the operator
    community is likely to accept with open arms.

    There are too many edge ASNs today, using too many vendors' equipment = with too many varieties
    of equipment within vendors, and too vari= ed code base, to believe rapid uptake or critical mass is
    feasible in the timeline the WG participants might like to believe.

    And I don't believe the opinions of participants= in the WG is sufficient to say yay or nay to the current assumption.

    So, it is only a consequence of other decisions, that u= se-cases is touched on. However, that it is, is provable
    by simpl= e classic logic.

    A->B and B->C, when combine= d with !C, means !B, means !A.
    Here, C is edge-ASNs doing BGPSEC, B is ROAs exclusively tied to BGP o= rigin ASNs, and A is use-cases as currently enumerated.

    The document, other than the corner cases such as this (proxy origina= tion on the bgpsec side), is fine.

    Brian

    On Sat, Mar 3= 1, 2012 at 4:31 PM, Sriram, Kotikalapudi <kotikalapudi.sriram@n= ist.gov> wrote:
    Brian,

    There is a clear distinction between =93prefix-origin validation=94 (based = on ROA information)
    and "origination (signed injection into BGPSEC)" in the SIDR work= ing group's usage of these terms.
    You seem to be attempting to use these two terms with the same connotation.=
    Your comments clearly pertain to path signing. You seem to be especially co= ncerned about
    path signing by a stub origin AS or by a proxy AS (e.g., the stub AS's = upstream transit provider).
    Draft-ietf-sidr-usecases I-D documents use cases relating only to =93prefix= -origin validation=94.
    A use-cases document for the path signing would be a separate document;
    as far as I know no one is working on it at the moment.
    So your comments seem misplaced, i.e., they appear not relevant to draft-ie= tf-sidr-usecases.
    Please also see my response in my other post that follows this post, but wi= th the subject:
    stub AS and proxy signing.
    Thank you.

    Sriram

    >
    > To: Brian Dickson <brian.peter.dickson at gmail.com>
    > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
    > From: "Murphy, Sandra" <Sandra.Murphy at sparta.com>
    > Date: Sat, 31 Mar 2012 04:12:10 +0000
    >
    > speaking as regular ol' member
    >
    > I'm not really sure what you are talking about here.
    >
    > You speak of bgpsec and signing - that is not origin validation, that<= br> > is path validation.
    >
    > Origin validation is strictly and only judging whether the origin has<= br> > the authority to originate announcements of the prefix. =A0Origin
    > validation does not ensure that the authorized AS is actually making > the announcement.
    >
    > It is bgpsec path validation that ensures that the announcement is
    > currently and authentically being announced by the AS. =A0That's t= he
    > "signed injection" you mention.
    >
    > --Sandy
    >
    > From: Brian Dickson [brian.peter.dickson at gmail.com]
    > Sent: Friday, March 30, 2012 8:55 AM
    > To: Murphy, Sandra
    > Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr= at
    > ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
    >
    > Sandy,
    >
    > The use case example I included, is an origin validation use case.
    >
    > The problem is the inability to have "origination" (signed i= njection
    > into BGPSEC) done by proxy, at all or especially by more than one
    > party.
    >
    > The particular situation leading to the need for this, would be a stub=
    > AS whose router vendor does not support BGPSEC, or whose router
    > hardware or code base is not included in BGPSEC support by their
    > router vendor.
    >
    > (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by o= perators.)
    >
    > This is likely to be a fairly common situation _among stub AS_ and, > given the current requirement for origin injection for BGPSEC,
    > addressing this _may_ impact the use cases document, for _origin
    > validation_.
    >
    > I'm just saying...
    >
    > Brian
    >
    > On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <Sandra.Murph= y at
    > sparta.com>= ; wrote:
    > Brian, Chris.
    >
    > The usecases draft was intended to describe origin validation use case= s.
    >
    > Route leaks (and other path validation issues) might need their own > usecases draft.
    >
    > But I don't think we should add those cases to this draft.
    >
    > --Sandy
    >
    > ________________________________________
    > From: christopher.morrow at gmail.com [christopher.morrow at
    > gmail.com] on behal= f of Christopher Morrow [morrowc.lists at
    > gmail.com]
    > Sent: Thursday, March 29, 2012 7:21 PM
    > To: Brian Dickson
    >
    > On Thu, Mar 29, 2012 at 3:11 PM, Brian Dickson
    > <brian.peter.dickson at gmail.com> wrote:
    >
    >> I think the use cases are likely to be informed by protocol design= , so even
    >
    > s/informed by protocol design/altered if the protocol design changes/<= br> >
    > I'm not sure if the protocol design's going to change the use-= cases...
    > you're still going to want to secure a route. (not an important po= int)
    >
    >> I have a few examples that I can think of, which would necessarily= depend
    > <snip>
    >> I'd prefer this to be added to a "raft" of IDs, for = which there is no rush
    >> to publish until they are all completed, after which the timing wo= uld be
    >> appropriate.
    >
    > I'm not against this, though we've got a document hanging out = post
    > WGLC (perhaps it ought to be re-reviewed if the changes were
    > significant... anyway) and we'll have to keep kicking it each 5.5<= br> > months to stay 'alive'. (again, not super important, and see b= elow as
    > well)
    >
    >> Here's an example of use-case, which depends on certain assump= tions (which
    >> may or may not be appropriate, but which are fodder for discussion= ):
    >>
    >> Suppose there is an Edge-AS "E", and transit providers t= o "E", which would
    >> be "X" and "Y".
    >>
    >> Suppose "E" does not do BGPSEC (per se), but wants to ha= ve BGPSEC signing
    >> done "for her", by "X" and "Y".
    >>
    >> (Ignore for the moment that the _current_ designs don't suppor= t that, that
    >> is an entirely other rat-hole for the moment.)
    >
    > hrm, in:
    >
    > =A0<http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-o= ps-04.txt>
    >
    > section-6 there's discussion of 'only sign your one prefix, do= nothing
    > else complex' which fits the model, albeit requiring the end site = to
    > run some small number of commands on their device. If they wanted to > hand their private key materials to the upstreams they could do the > signing, but that seems icky (to me).
    >
    > I don't know that, if implications are understood by the end site = and
    > configurations available for use on their side, end-sites would want > to hand over control of their IP assets in this way. Running the
    > signing on their side should be simple enough, and low/no-cost.
    >
    >> And publishing something IMHO prematurely, locks the WG into that = RFC,
    >> making revising it much harder, than if it were still in-WG and >> not-yet-published.
    >
    > I think the authors said something like: "send text" where y= ou think
    > it is fit to be inserted... If other folks want to delay/re-review
    > they need to speak up. Consensus so far was that the document was
    > ready to move along.
    >
    > -chris

    --f46d04426f1432c35304bc905fdd-- From kotikalapudi.sriram@nist.gov Sat Mar 31 14:34:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DDE21F8741 for ; Sat, 31 Mar 2012 14:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2jWcb+G-Ub6 for ; Sat, 31 Mar 2012 14:34:52 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75521F8746 for ; Sat, 31 Mar 2012 14:34:51 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 17:34:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sat, 31 Mar 2012 17:34:50 -0400 From: "Sriram, Kotikalapudi" To: Brian Dickson Date: Sat, 31 Mar 2012 17:30:30 -0400 Thread-Topic: stub AS and proxy signing Thread-Index: AQHND4IwlHQhAkmrCky/DL61Gg8hLg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Chris Morrow , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] stub AS and proxy signing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 21:34:53 -0000 Brian, I hope you agree with me and Sandy that your questions (in the thread re: d= raft-ietf-sidr-usecases-03)=20 were really about proxy signing for the stub origin AS, and not about use c= ases for=20 =93prefix-origin validation=94.=20 That is why I have started this different thread (with changed subject line= ).=20 The author team (and contributors) of draft-ietf-sidr-bgpsec-protocol docum= ent discussed stub ASs and proxy signing by transit provider (upstream AS) at length, and= those discussions=20 are documented in: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01 Please see sections 6.5 and 6.6. Also, please see Section 6 (Considerations for Edge Sites) in the bgpsec-op= s document http://tools.ietf.org/html/draft-ymbk-bgpsec-ops-01 =93Thus a smallish edge router may hold only its own signing key(s) and sign it's announcement but not receive signed announcements and therefore not need to deal with the majority of the RPKI.=94 Sharing the stub=92s private key with the upstream transit provider is cons= idered a bad practice. Instead, the stub can simply only sign its prefix(es) to the upstream AS an= d receive only unsigned updates from that upstream AS.=20 This requires minimal SW upgrade, and no HW upgrade in stub ASs. =20 I hope this helps address your questions. Sriram > From: Brian Dickson [brian.peter.dickson at gmail.com] > Sent: Friday, March 30, 2012 8:55 AM > To: Murphy, Sandra > Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at > ietf.org list > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt > > Sandy, > > The use case example I included, is an origin validation use case. > > The problem is the inability to have "origination" (signed injection > into BGPSEC) done by proxy, at all or especially by more than one > party. > > The particular situation leading to the need for this, would be a stub > AS whose router vendor does not support BGPSEC, or whose router > hardware or code base is not included in BGPSEC support by their > router vendor. > > (Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by oper= ators.) > > This is likely to be a fairly common situation _among stub AS_ and, > given the current requirement for origin injection for BGPSEC, > addressing this _may_ impact the use cases document, for _origin > validation_. > > I'm just saying... > > Brian From kotikalapudi.sriram@nist.gov Sat Mar 31 15:30:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395F21F8694 for ; Sat, 31 Mar 2012 15:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8TSMwW+I0uf for ; Sat, 31 Mar 2012 15:30:57 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5E21F8685 for ; Sat, 31 Mar 2012 15:30:57 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 31 Mar 2012 18:30:45 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sat, 31 Mar 2012 18:26:36 -0400 From: "Sriram, Kotikalapudi" To: Brian Dickson Date: Sat, 31 Mar 2012 18:26:35 -0400 Thread-Topic: stub AS and proxy signing Thread-Index: AQHND4IwlHQhAkmrCky/DL61Gg8hLpaE703m Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: Chris Morrow , "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] stub AS and proxy signing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 22:30:58 -0000 Brian, I am addressing your new questions (which still are about stub AS and proxy signing) under the new thread. >It is all fine and well to do origin-validation based on BGP origination, but since the >current design of bgpsec is anchored to (vanilla, non-sec) BGP origination as well, >this means identifying affected elements when challenging the bgpsec design. The design of BGPSEC assumes that all participating ASs are BGPSEC capable. The stub AS is assumed (required) at the minimum to be capable of signing the prefix(es) it originates. Vanilla, non-sec stub ASs are not part of BGPSEC islands. They join BGPSEC islands when they make an arrangement with their upstream at least to sign towards them even though they may agree to receive only unsigned updates from their upstream. >And, what I'm suggesting is, that restricting bgpsec deployment to only origin AS >operators who deploy bgpsec (i.e. excluding proxy injection into bgpsec from >non-bgpsec origins), is not something the operator >community is likely to accept with open arms. If a stub AS operator trusts the upstream transit provider and hands her private key to the upstream AS operator, that cannot be ruled out since it is a private arrangement. But the BGPSEC protocol need not specify the same (i.e., arrangement of proxy injection) as it can always be done by consenting parties. >There are too many edge ASNs today, using too many vendors' equipment >with too many varieties of equipment within vendors, and too varied code base, >to believe rapid uptake or critical mass is feasible >in the timeline the WG participants might like to believe. Interestingly, the same arguments that you use above were used to include support for simplex BGPSEC in the design for accommodating stub ASs (the small, not very resourceful AS operator). Again, quoting from bgpsec-ops document: Section 6. Considerations for Edge Sites An edge site which does not provide transit and trusts its upstream(s) SHOULD only originate a signed prefix announcement and need not validate received announcements. BGPsec protocol capability negotiation provides for a speaker signing the data it sends but being unable to accept signed data. Thus a smallish edge router may hold only its own signing key(s) and sign it's announcement but not receive signed announcements and therefore not need to deal with the majority of the RPKI. As the vast majority (84%) of ASs are stubs, and they announce the majority of prefixes, this allows for simpler and cheaper early incremental deployment. It may also mean that edge sites concerned with routing security will be attracted to upstreams which support BGPsec. Sriram