From yaronf@checkpoint.com Sat Aug 1 23:54:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D263A6781 for ; Sat, 1 Aug 2009 23:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm+c8P+H0pT0 for ; Sat, 1 Aug 2009 23:54:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9E3E53A68F7 for ; Sat, 1 Aug 2009 23:54:37 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 651BE200E09; Sun, 2 Aug 2009 09:54:57 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1CB6A200409; Sun, 2 Aug 2009 09:54:57 +0300 (IDT) X-CheckPoint: {4A75369E-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n726sc3d014429; Sun, 2 Aug 2009 09:54:38 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 2 Aug 2009 09:54:38 +0300 From: Yaron Sheffer To: Yaron Sheffer , Paul Hoffman , "secdir@ietf.org" Date: Sun, 2 Aug 2009 09:54:37 +0300 Thread-Topic: [secdir] Paper on RSA 1024 and ECC Thread-Index: AcoPbau2jgp56SdURcC5hhjddg0CBAADPB6gANbODBA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557CD9F@il-ex01.ad.checkpoint.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0149_01CA12EB.B1EEC430" MIME-Version: 1.0 Subject: Re: [secdir] Paper on RSA 1024 and ECC X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 06:54:39 -0000 ------=_NextPart_000_0149_01CA12EB.B1EEC430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And, as we speak, a yet newer attack on AES-256. http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Thanks, Yaron > -----Original Message----- > From: Yaron Sheffer > Sent: Tuesday, July 28, 2009 13:58 > To: 'Paul Hoffman'; secdir@ietf.org > Subject: RE: [secdir] Paper on RSA 1024 and ECC > > And the AES-256 related-key attack: > http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html > > Thanks, > Yaron > > > -----Original Message----- > > From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf > > Of Paul Hoffman > > Sent: Tuesday, July 28, 2009 12:25 > > To: secdir@ietf.org > > Subject: [secdir] Paper on RSA 1024 and ECC > > > > From today's lunch: > > > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0149_01CA12EB.B1EEC430 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDgwMTE5MDQ0NFowIwYJKoZIhvcNAQkEMRYEFGvIr/KjzswP 4V7RphuWH4NXy+4aMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA f0ZDRuUFpbKLikoDdqyQsf9hLDee04ar/5UuLTeIE17uzw6whaN2kzc1f+Ml0UH4sKJaYAzFBQjS pUTqiBK4blWyxKCrzp9qq/Q68y5+onPPj4kPWLIbZndA29GUr8qAXP3kM10V6uKVRwDZVF9JcWvW U7YANVQ7PFc1+YAb9KSOa8OYEpItNubc9rheDiSaifGxc6uDwjPf1LE+jz4vsMYUuufk0PUmcelp JmRU143Fr4s3tQrWRYptpH5OdfOJGayxc2CI33pnUf7aI78jOjCNtZaWp7avSXrZQwE3I+05fKfT bw367T/5RKZByqv24uAF+Xytec03cgd4afQOywAAAAAAAA== ------=_NextPart_000_0149_01CA12EB.B1EEC430-- From Pasi.Eronen@nokia.com Mon Aug 3 00:21:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E843F3A6C1D for ; Mon, 3 Aug 2009 00:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.867 X-Spam-Level: ** X-Spam-Status: No, score=2.867 tagged_above=-999 required=5 tests=[AWL=-9.134, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, URIBL_BLACK=20] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 444CiwdJGwhU for ; Mon, 3 Aug 2009 00:21:05 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 89B5128B56A for ; Mon, 3 Aug 2009 00:21:05 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n736JxYa022036; Mon, 3 Aug 2009 01:20:36 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:20:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:20:36 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 3 Aug 2009 08:20:35 +0200 From: To: , Date: Mon, 3 Aug 2009 08:20:33 +0200 Thread-Topic: [secdir] Discussion from the Security Directorate Thread-Index: AcoRDPEbss5hqVVZRuqkV++RcjIqBQC9P3lQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72001863@NOK-EUMSG-01.mgdnok.nokia.com> References: <633E561F-48D1-42DE-A310-9E77DB0A87F1@cisco.com> <4A6D98AC.4060100@bogus.com> <5AECC74E-90A0-45DA-9D23-7DE64F3488CB@cisco.com> <04f701ca102f$3e6d2c90$7958404e@china.huawei.com> <4C4D74B8-10FA-458E-93E4-37EE48F9D386@cisco.com> <50F560B9-787C-4B90-903B-28F27E67CF85@huawei.com> <132FFEDA-A10E-4CF2-9090-B2BBD274F6BA@huawei.com> <85C22B4D-F60E-47C4-95A1-2AFCB3917114@cisco.com> In-Reply-To: <85C22B4D-F60E-47C4-95A1-2AFCB3917114@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2009 06:20:36.0509 (UTC) FILETIME=[83AC7CD0:01CA1402] X-Nokia-AV: Clean Cc: 6man-chairs@tools.ietf.org, jabley@ca.afilias.info, 6man-ads@tools.ietf.org, secdir@ietf.org, kurtis@kurtis.pp.se, joelja@bogus.com, behave-chairs@tools.ietf.org, v6ops-ads@tools.ietf.org, softwire-ads@tools.ietf.org, behave-ads@tools.ietf.org, softwire-chairs@tools.ietf.org Subject: Re: [secdir] Discussion from the Security Directorate X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 07:21:07 -0000 Fred, Joel, Tina, and others: It seems there was some misunderstanding or miscommunication about=20 the slides ("Recommendation of IPv6 security work") somewhere,=20 perhaps because the cover page didn't have anyone's name on it. These are Tina's slides, and represent her opinions only. They do=20 not come from the security directorate, have not been discussed=20 there, and I have not seen them before. If I understand correctly, they were intended as starting points for discussions; however, SecDir is not the right place for those discussions, as the mailing list is by invitation only (although the archives are public) and SecDir does not have proper meetings either (only informal lunch). Best regards, Pasi > -----Original Message----- > From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On > Behalf Of ext Fred Baker > Sent: 30 July, 2009 14:57 > To: Tina > Cc: 6man Chairs; Joel Jaeggli; 6man-ads@tools.ietf.org; > secdir@ietf.org; behave-ads@tools.ietf.org; Behave Chairs; Kurt Erik > Lindqvist; Joe Abley; Softwire Chairs; v6ops-ads@tools.ietf.org; > softwire-ads@tools.ietf.org > Subject: Re: [secdir] Discussion from the Security Directorate >=20 > who is "we"? >=20 > I would suggest that you make your request to the chairs of the > various working groups doing the work. These include 6man (designated > custodian of all things IPv6 and therefore of RFCs 3053, 3056, 4213, > and 5214), behave (translation), and softwire (tunnels). >=20 > On Jul 29, 2009, at 8:45 PM, Tina wrote: >=20 > > Hi again:) > > Some clarifications for the slides. > > > > a. security assessment, to evaluate the security of a transition > > technology. What aspects do we need to judge and consider? > > b. function recommendation, to reduce the security threat of some > > kind of transition technology. When deploy this technology, what > > functionalities should the device need to have? > > > > > > B. R. > > Tina > > http://tinatsou.weebly.com/contact.html > > > > > > > > On Jul 29, 2009, at 5:23 PM, Tina wrote: > > > >> Hi Fred and David, > >> The slides were sent to OPS ADs, and we discussed it a bit in OPS- > >> DIR work lunch on Monday. According to the suggestion from Dan, I > >> forwarded the slides to the WG chairs of v6ops and opsec. > >> > >> Then Fred forwarded to SEC-DIR. > >> > >> I mentioned Fred's email during SEC-DIR work lunch on Tuesday. > >> There was discussion. > >> > >> I went to Tuesday v6ops session before my slides were taken. Then I > >> left for some personal emergency reasons. Therefore I was not able > >> to present the slides. But Fred did it. > >> > >> The slides will be presented in OPS Area Opening meeting in the > >> Large Stage between 15:10 to 16:10. > >> > >> > >> B. R. > >> Tina > >> http://tinatsou.weebly.com/contact.html > >> > >> > >> On Jul 29, 2009, at 5:04 PM, Fred Baker wrote: > >> > >>> It was presented to the ops directorate as "from the security > >>> directorate" on Monday, and shipped off to my working group. > >>> > >>> OK, Tina, over to you... > >>> > >>> On Jul 29, 2009, at 11:30 AM, David Harrington wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a question. > >>>> I am a member of the Security Directorate, and I do not remember > >>>> any > >>>> discussion leading to this powerpoint presentation or request. I > >>>> may > >>>> have missed a SECDIR session. I didn't find discussion of this > >>>> powerpoint presentation in the secdir archives prior to this week. > >>>> > >>>> Is this a "Discussion from the Security Directorate"? If so, when > >>>> was > >>>> this discussed? Has the SECDIR reviewed this powerpoint slide > >>>> deck and > >>>> approved it being sent to working groups? > >>>> > >>>> David Harrington > >>>> dbharrington@comcast.net > >>>> ietfdbh@comcast.net > >>>> dharrington@huawei.com > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: secdir-bounces@ietf.org > >>>>> [mailto:secdir-bounces@ietf.org] On Behalf Of Fred Baker > >>>>> Sent: Tuesday, July 28, 2009 10:49 PM > >>>>> To: Joel Jaeggli > >>>>> Cc: 6man Chairs; 6man-ads@tools.ietf.org; secdir@ietf.org; > >>>>> Kurt Erik Lindqvist; Joe Abley; Softwire Chairs; > >>>>> v6ops-ads@tools.ietf.org; softwire-ads@tools.ietf.org; Tina > >>>>> TSOU; behave-ads@tools.ietf.org; Behave Chairs > >>>>> Subject: Re: [secdir] Discussion from the Security Directorate > >>>>> > >>>>> I'm not arguing against the request. I'm asking what it is > >>>>> requesting, > >>>>> as I have no idea... > >>>>> > >>>>> I think I know what a threat analysis is. > >>>>> > >>>>> What is a "security assessment" apart from a "threat > >>>>> assessment"? I > >>>> > >>>>> told v6ops (which does not develop transition technologies, by > >>>>> charter, and therefore is the absolute wrong place to send > >>>>> this) that > >>>>> I thought it might mean an assessment of how we might mitigate > the > >>>>> threats. Absent any answers from the Security Directorate > >>>>> responsive > >>>> > >>>>> to the question, I have no idea whether I was correct. > >>>>> > >>>>> And what on God's Green Earth is a "function recommendation"? I > >>>>> have > >>>> > >>>>> no idea what you want. > >>>>> > >>>>> Nobody from the Security Directorate was there today to deliver > >>>>> the > >>>> > >>>>> message. If I were developing a threat assessment of that > >>>>> protocol... > >>>>> let's see: delivered to the wrong WG by someone who didn't know > >>>>> what > >>>> > >>>>> the message was supposed to be using slides he didn't understand > >>>>> and > >>>> > >>>>> the security directorate didn't take the time to explain... > >>>>> > >>>>> On Jul 27, 2009, at 2:08 PM, Joel Jaeggli wrote: > >>>>> > >>>>>> I'd probably tune the slides a bit still: > >>>>>> > >>>>>> Security problems show up in deployment and use, these > cannot > >>>> be > >>>>>> thought out at all when designing the protocols > >>>>>> > >>>>>> Is an assertion you'll get pushback on. we have signficant > >>>>> operational > >>>>>> experience with variations on many of the proposed or deployed > >>>>>> transition mechanisms. necessarily that experience informs both > >>>> our > >>>>>> current thinking and the desirability of any particular > approach. > >>>>>> > >>>>>> bump in the wire type transition technologies certainly are an > >>>> area > >>>>>> potential concern for opsec > >>>>>> > >>>>>> Fred Baker wrote: > >>>>>>> Thanks, Tina. I will add this to the IPv6 Operations > >>>>> agenda, probably > >>>>>>> during our second session Tuesday. > >>>>>>> > >>>>>>> You will note that I am copying the chairs and ADs from several > >>>>>>> working > >>>>>>> groups. The reason is that the primary thrust of the > >>>>> comments you are > >>>>>>> making apply to work being done in those working groups. Slide > 5 > >>>>>>> specifically requests a threat analysis, security assessment, > >>>>>>> and > >>>>>>> "function recommendation" on each transition technology; > >>>>> these are in > >>>>>>> fact being done in behave and softwires. I mention 6man because > >>>>>>> marketing blather from the IPv6 form makes security claims > >>>>> for IPv6, > >>>>>>> which it would be good if that working group clarified. > >>>>>>> > >>>>>>> I do have to ask specifically what the Security > >>>>> Directorate hopes to > >>>>>>> find in the three documents that have been requested for each > of > >>>> > >>>>>>> these > >>>>>>> various technologies. What, specifically, is a "function > >>>>>>> recommendation"? A threat analysis is a statement that > >>>>> there exist > >>>>>>> a set > >>>>>>> of possible threats. Is a security assessment a statement about > >>>> how > >>>>>>> those threats are responded to? What, if the WGs don't > >>>>> produce it, is > >>>>>>> going to leave the Security Directorate feeling ill-used? > >>>>>>> > >>>>>>> On Jul 27, 2009, at 12:56 PM, Tina TSOU wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> B. R. > >>>>>>>> ">http://tinatsou.weebly.com/contact.html > >>>>>>> > >>>>>>>> Begin forwarded message: > >>>>>>>> > >>>>>>>>> From: "Romascanu, Dan (Dan)" > >>>>>>>>> Date: July 27, 2009 7:52:20 AM GMT+02:00 > >>>>>>>>> To: Ron Bonica > >>>>>>>>> Cc: Tina TSOU > >>>>>>>>> Subject: FW: [OPS-DIR] Reminder: OPS-DIR working lunch > >>>>>>>>> > >>>>>>>>> Ron, > >>>>>>>>> > >>>>>>>>> This looks more like an opsec (who are not meeting this > >>>>> time) or > >>>>>>>>> v6ops > >>>>>>>>> subject. > >>>>>>>>> > >>>>>>>>> Dan > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Tina TSOU [mailto:tena@huawei.com] > >>>>>>>>> Sent: Monday, July 27, 2009 12:02 AM > >>>>>>>>> To: Romascanu, Dan (Dan) > >>>>>>>>> Subject: Re: [OPS-DIR] Reminder: OPS-DIR working lunch > >>>>>>>>> > >>>>>>>>> Hi Dan, > >>>>>>>>> Could this be discussed at OPS-DIR working lunch? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> secdir mailing list > >>>>> secdir@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/secdir > >>>>> > >>>> > >>> > >> > > >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From dave.cridland@isode.com Mon Aug 3 03:50:31 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF1328C101; Mon, 3 Aug 2009 03:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV1ehyc7biAc; Mon, 3 Aug 2009 03:50:30 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A0C023A6BC7; Mon, 3 Aug 2009 03:50:29 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 3 Aug 2009 11:50:14 +0100 X-SMTP-Protocol-Errors: NORDNS References: <27466.1243333725.022789@puncture> In-Reply-To: <27466.1243333725.022789@puncture> Message-Id: <11157.1249296517.082568@puncture> Date: Mon, 03 Aug 2009 11:48:37 +0100 From: Dave Cridland To: Security Area Directorate , The IESG , Bruce Lowekamp , MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="11157.1249296517.082405@puncture" Subject: [secdir] Security Review of draft-ietf-behave-nat-behavior-discovery-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 10:50:31 -0000 --11157.1249296517.082405@puncture Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" I have re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Original review and response are attached, I omitted to copy the secdir mailing list the first time. For -07, the document addresses the security concerns of the protocol extensions involved adequately. In particular: On Tue May 26 11:28:45 2009, Dave Cridland wrote: > The Security Considerations section is reasonably complete, as far > as I can tell, however it is not terribly clear that it suggests > authentication of the clients (it says "preexisting credentials") - > I think this could be clearer. The description of > XOR-RESPONSE-TARGET also doesn't include this, it's mentioned most > clearly in Section 6.1. This has since been clarified in -07, having been addressed by a clear, point-by-point mitigation guide. Dave. --11157.1249296517.082405@puncture Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Security Review of draft-ietf-behave-nat-behavior-discovery-06 Subject: Security Review of draft-ietf-behave-nat-behavior-discovery-06 MIME-Version: 1.0 Message-Id: <27466.1243333725.022789@puncture> Date: Tue, 26 May 2009 11:28:45 +0100 From: Dave Cridland To: IETF-Discussion , , , Bruce Lowekamp Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. (I note there is expected to be a new version coming for this draft). Security Issues: The Security Considerations section is reasonably complete, as far as I can tell, however it is not terribly clear that it suggests authentication of the clients (it says "preexisting credentials") - I think this could be clearer. The description of XOR-RESPONSE-TARGET also doesn't include this, it's mentioned most clearly in Section 6.1. General comments: I have a strong suspicion that this document is Experimental purely because it failed to gain sufficient consensus to be Standards-Track. It's not clear to me why this is not Informational, or why all the extensions described in the document are within the same document. I'm dubious that they're all of similar quality. If there is an experiment here, then it's in the usage of these extensions to determine whether, at least in some cases, NAT behaviour is sufficiently stable as to be useful, and moreover, whether taking advantage of this is practical. The extensions themselves clearly seem suitable for discovering whether this is so. As such, section 2.3 seems somewhat contrived and grasping. This isn't to say that the hypothesis being tested is not valid, but the experiment, as defined, seems like a matter of form rather than a useful test of the hypothesis as outlined. Editorial Issues: The use of the term "aprocyphal" is interesting, but conjures up connotations that seem to be somewhat self-defeating. Perhaps "anecdotal" would be more fitting, or "controversial". (It is this evidence, after all, that forms the hypothesis mentioned above, and the hypothesis itself is surely not aprocypha). IANA section requests registration of CHANGE-REQUEST, but this is already registered - the registration needs changing, as per section 6.1, where the situation is detailed more clearly. Typographical Errors: Extraneous "}" in section 9.4. --11157.1249296517.082405@puncture Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Re: Security Review of draft-ietf-behave-nat-behavior-discovery-06 Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.5a0) with LMTP; Wed, 08 Jul 2009 03:39:35 +0100 (BST) Received: from mail-bw0-f206.google.com ([209.85.218.206]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Wed, 8 Jul 2009 03:39:34 +0100 Received: by bwz2 with SMTP id 2so4735805bwz.23 for ; Tue, 07 Jul 2009 19:39:33 -0700 (PDT) Received: by 10.223.108.210 with SMTP id g18mr3102669fap.38.1247020773786; Tue, 07 Jul 2009 19:39:33 -0700 (PDT) In-Reply-To: <27466.1243333725.022789@puncture> References: <27466.1243333725.022789@puncture> Date: Tue, 7 Jul 2009 22:39:33 -0400 Message-ID: Subject: Re: Security Review of draft-ietf-behave-nat-behavior-discovery-06 From: Bruce Lowekamp To: Dave Cridland Cc: IETF-Discussion , behave-chairs , derek , behave@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave, Thanks for the feedback. Responses inline. On Tue, May 26, 2009 at 6:28 AM, Dave Cridland wro= te: > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. =C2=A0Th= ese > comments were written primarily for the benefit of the security area > directors. =C2=A0Document editors and WG chairs should treat these commen= ts just > like any other last call comments. > > (I note there is expected to be a new version coming for this draft). > > Security Issues: > > The Security Considerations section is reasonably complete, as far as I c= an > tell, however it is not terribly clear that it suggests authentication of > the clients (it says "preexisting credentials") - I think this could be > clearer. The description of XOR-RESPONSE-TARGET also doesn't include this= , > it's mentioned most clearly in Section 6.1. I made a lot of edits around XOR-RESPONSE-TARGET, in the process I actually removed the phrase "pre-existing credentials", just leaving it as authenticated. However, the term comes from 5389, which only defines mechanisms for using "pre-existing credentials" for authentication, meaning credentials that are obtained through a mechanism outside STUN itself. > > General comments: > > I have a strong suspicion that this document is Experimental purely becau= se > it failed to gain sufficient consensus to be Standards-Track. It's not cl= ear > to me why this is not Informational, or why all the extensions described = in > the document are within the same document. I'm dubious that they're all o= f > similar quality. > > If there is an experiment here, then it's in the usage of these extension= s > to determine whether, at least in some cases, NAT behaviour is sufficient= ly > stable as to be useful, and moreover, whether taking advantage of this is > practical. The extensions themselves clearly seem suitable for discoverin= g > whether this is so. > > As such, section 2.3 seems somewhat contrived and grasping. This isn't to > say that the hypothesis being tested is not valid, but the experiment, as > defined, seems like a matter of form rather than a useful test of the > hypothesis as outlined. Section 2.3 doesn't describe an experiment, it describes conditions for experimental success. Section 2.2 has been greatly expanded and now describes in much more detail how such an application might work. However, it's not the only application that could satisfy the conditions. > > Editorial Issues: > > The use of the term "aprocyphal" is interesting, but conjures up > connotations that seem to be somewhat self-defeating. Perhaps "anecdotal" > would be more fitting, or "controversial". (It is this evidence, after al= l, > that forms the hypothesis mentioned above, and the hypothesis itself is > surely not aprocypha). Another reviewer also brought this up. Technically, "aprocryphal" could be interpreted as being contrary to IETF dogma, but I think you're right that anecdotal is clearer here. > > IANA section requests registration of CHANGE-REQUEST, but this is already > registered - the registration needs changing, as per section 6.1, where t= he > situation is detailed more clearly. > Numerous attempts by myself and others to determine the right way to handle this have indicated that this is the appropriate way to handle this, as the original registration has been obsoleted. But I'm always open for advice as to the best way to handle it. Bruce --11157.1249296517.082405@puncture-- From weiler+secdir@watson.org Mon Aug 3 07:04:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69283A6E1B for ; Mon, 3 Aug 2009 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7QFmSSgMefQ for ; Mon, 3 Aug 2009 07:04:22 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7ECF03A6DFD for ; Mon, 3 Aug 2009 07:03:42 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n73E3h56073072 for ; Mon, 3 Aug 2009 10:03:43 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n73E3hHC073069 for ; Mon, 3 Aug 2009 10:03:43 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 3 Aug 2009 10:03:43 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Mon, 03 Aug 2009 10:03:44 -0400 (EDT) Subject: [secdir] README: Change in review deadlines X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:04:23 -0000 Summary: please complete last call reviews by the end of the last call. Details: based on feedback from doc authors and the IESG, the ADs announced in Stockholm that they would prefer our initial reviews be sent by the end of IETF last call. That way, our comments can be processed along with any other last call comments and aren't an unpleasant late surprise to doc editors. We previously asked for reviews within seven days, though most of us were in the habit of letting that slip, often until the doc appeared on telechat. Most last calls are at least two weeks and often four weeks. Depending on how the last call announcement and assignment cycles interact, this means that we should have at least one week and usually more to get the review done. To facilitate this, we have added a deadline field to the review assignment messages. This should list the last call end date (or, for docs scheduled on an IESG telechat, the Tuesday before the telechat), but there may be errors in some of the dates, especially for older documents. Feel free to check the last call announcement to be certain. Also, since there were no assignments made during the Stockholm meeting, some of you are getting assignments of docs with last calls ending in the next few days. Knowing that this is a change in practice, feel free to take a week to get those done. I may also be shifting the assignment schedule somewhat to allow more time for reviews. Expect to see some variation. If you'd like more visibility into your secdir assignments and history, I can give you access to the review assignment tool. Just drop me a note. (Despite an announcement about this at San Francisco, we didn't open the tool up for experimentation then.) And we're adding a few new members: Tina TSOU is on the list now, and Russ Mundy will be joining us soon. As always, let me know when you're going to be offline for an extended period, particularly if you're in the next few names in the rotation. -- Sam From weiler+secdir@watson.org Mon Aug 3 07:05:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15033A6E28 for ; Mon, 3 Aug 2009 07:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-HTtEHadpY3 for ; Mon, 3 Aug 2009 07:05:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D96BB3A6E08 for ; Mon, 3 Aug 2009 07:05:47 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n73E5nxe073448 for ; Mon, 3 Aug 2009 10:05:49 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n73E5nV5073445 for ; Mon, 3 Aug 2009 10:05:49 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 3 Aug 2009 10:05:49 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Mon, 03 Aug 2009 10:05:50 -0400 (EDT) Subject: [secdir] Assignments (next telechat: August 13th) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:05:55 -0000 Stephen Farrell is next in the rotation. As described in the previous message, please try to complete last call reviews by the end of the last call. The deadline field below should list the last call end date, though it may have some errors, especially for older documents. In the transition to this new schedule, there may be some documents with a last call end date in the next few days. If you're getting a new assignment of one of those, feel free to take a week (as before) to get the review done. The deadline for telechat rechecks is, as before, the Tuesday before the telechat. Once a document is scheduled for telechat, the deadline field will show that date, even if the last call ends sooner. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview (The deadline guidance there has not yet been updated.) -- Sam For telechat 2009-08-13 Reviewer Deadline Draft Alan DeKok T 2009-08-11 draft-ietf-mpls-ldp-end-of-lib-03 Tobias Gondrom T 2009-08-11 draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker T 2009-08-11 draft-ietf-nea-pb-tnc-04 Steve Hanna T 2009-08-11 draft-ietf-netconf-partial-lock-09 Paul Hoffman TR2009-08-11 draft-iana-rfc3330bis-07 Chris Newman T 2009-08-11 draft-ietf-mpls-tp-requirements-09 Radia Perlman T 2009-08-11 draft-ietf-pwe3-mpls-transport-04 For telechat 2009-08-27 Reviewer Deadline Draft Glen Zorn T 2009-08-25 draft-ietf-ntp-dhcpv6-ntp-opt-04 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2009-08-14 draft-ietf-pkix-authorityclearanceconstraints-02 Rob Austein 2009-08-05 draft-ietf-opsawg-syslog-alarm-02 Richard Barnes 2009-08-11 draft-ietf-pkix-other-certs-04 Pat Cain 2009-08-10 draft-ietf-tls-extractor-06 Ran Canetti 2009-08-17 draft-ietf-vcarddav-webdav-mkcol-05 Dave Cridland 2009-08-17 draft-turner-clearancesponsor-attribute-01 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Donald Eastlake 2009-08-19 draft-zorn-radius-pkmv1-05 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-02 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman 2009-06-29 draft-ietf-ipsecme-ikev2-redirect-12 Julien Laganier 2009-01-22 draft-ietf-sip-certs-08 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-19 Sandy Murphy 2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Vidya Narayanan 2009-06-04 draft-ietf-enum-3761bis-04 Vidya Narayanan 2009-07-10 draft-ietf-opsawg-syslog-snmp-03 Eric Rescorla 2009-06-04 draft-ietf-enum-iax-05 Eric Rescorla 2009-07-16 draft-ietf-simple-xcap-diff-13 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Joe Salowey 2009-07-16 draft-ietf-sipping-service-identification-03 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-07-25 draft-ietf-pkix-ta-format-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2009-08-04 draft-ietf-dime-diameter-qos-10 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Nico Williams 2009-08-04 draft-ietf-dime-nai-routing-02 Tom Yu 2009-08-05 draft-ietf-dime-pmip6-02 Kurt Zeilenga 2009-08-03 draft-ietf-hokey-key-mgm-08 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-03 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04 From Radia.Perlman@sun.com Mon Aug 3 07:52:53 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005C83A6DF7; Mon, 3 Aug 2009 07:52: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azRy2oSH4yyi; Mon, 3 Aug 2009 07:52:52 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 4FB3E3A6E08; Mon, 3 Aug 2009 07:52:52 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KNT00J002NUIQ10@mail-mta.sfvic.sunlabs.com>; Mon, 03 Aug 2009 07:52:42 -0700 (PDT) Received: from [192.168.29.100] ([173.64.135.7]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KNT00FDM2NUX571@mail.sunlabs.com>; Mon, 03 Aug 2009 07:52:42 -0700 (PDT) Date: Mon, 03 Aug 2009 07:53:07 -0700 From: Radia Perlman To: secdir@ietf.org, iesg@ietf.org, stbryant@cisco.com, mmorrow@cisco.com, swallow@cisco.com, tom.nadeau@bt.com Message-id: <4A76F9D3.3080806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Subject: [secdir] secdir review of draft-ietf-pwe3-mpls-transport-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:52:53 -0000 This document describes how to make an MPLS-TP path one one party (party A) appear to be an MPLS-TP link of another (party B), in other words, tunneling party B's MPLS-TP information over party A's -provided path. As noted in the security considerations section, there are no new security issues raised by using this already-existing mechanism for this purpose. One comment: Rao Cherukuri's email address seems to be missing from "authors' addresses". A couple of questions, really...it looks like the term "Transport" is used in the MPLS/ITU context to mean more like layer 3, rather than end-to-end layer 4 (like TCP). Although this always seemed a much more natural use of the term "transport" (since layer 3 and layer 2 really do transport things and layer 4 doesn't), why is it is called "TP" here? And in the security considerations section it mentions the problem of static configuration having the possibility of a forwarding loop. Again just a comment -- admittedly a packet can go round the loop a few times before the TTL expires, but given that there is a TTL, it seems like a looping MPLS path might not be too bad. Especially if part of the static configuration would be the TTL to initiate packets on, for a particular MPLS path. But as for the document being reviewed -- no security issues. Radia From stbryant@cisco.com Mon Aug 3 08:37:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A3B3A6DF6; Mon, 3 Aug 2009 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjhJmtlWU5Wn; Mon, 3 Aug 2009 08:37:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E72DB3A6E47; Mon, 3 Aug 2009 08:37:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,315,1246838400"; d="scan'208";a="46355798" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Aug 2009 15:37:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n73Fb6hK007113; Mon, 3 Aug 2009 17:37:06 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73Fb6tY019640; Mon, 3 Aug 2009 15:37:06 GMT Received: from dhcp-gpk02-vlan300-64-103-65-48.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n73Fb5D13738; Mon, 3 Aug 2009 16:37:05 +0100 (BST) Message-ID: <4A770420.1040402@cisco.com> Date: Mon, 03 Aug 2009 16:37:04 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Radia Perlman References: <4A76F9D3.3080806@sun.com> In-Reply-To: <4A76F9D3.3080806@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2357; t=1249313826; x=1250177826; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-pwe3- mpls-transport-04 |Sender:=20; bh=bO2T5a77kwdWJzAIviBRO0SfVInUJRd//DJSwvyQUjg=; b=rD9XUUzAPfNp3G+mmOEZQRpe0G3Ccx4zbK5fDPOc2XIgr8tEUWyQdlFSoY qRUQp2HQKPE0DfjyRkwWaEwAr77rGkLudF0z+3/lindRs93gX7dxMEVwcRfC Y/+vM+r+5E; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: swallow@cisco.com, tom.nadeau@bt.com, mmorrow@cisco.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pwe3-mpls-transport-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:37:06 -0000 Radia Thank you for the review. Radia Perlman wrote: > This document describes how to make an MPLS-TP path one one party > (party A) > appear to be an MPLS-TP link of another (party B), in other words, > tunneling > party B's MPLS-TP information over party A's -provided path. > > As noted in the security considerations section, there are no new > security > issues raised by using this already-existing mechanism for this purpose. > > One comment: Rao Cherukuri's email address seems to be missing > from "authors' addresses". > > A couple of questions, really...it looks like the term "Transport" is > used > in the MPLS/ITU context to mean more like layer 3, rather than end-to-end > layer 4 (like TCP). Although this always seemed a much more natural use > of the term "transport" (since layer 3 and layer 2 really do transport > things > and layer 4 doesn't), why is it is called "TP" here? Yes we are using the term transport in the way that ITU-T SG15 use the term. I would say that we are defining it the same way, but that do not seem to have a crisp definition themselves :) in other words we are designing a replacement for SDH and similar methods of providing long distance physical connectivity The term MPLS-TP stands for MPLS Transport Profile. This is the subset of the MPLS protocol suite needed to provide Transport Network Connectivity. > > And in the security considerations section it mentions the problem of > static configuration having the possibility of a forwarding loop. > Again just > a comment -- admittedly a packet can go round the loop a few times before > the TTL expires, but given that there is a TTL, it seems like a > looping MPLS > path might not be too bad. Transport networks are traffic engineered rather than best effort so the impact is that the packet consumes remaining TTL times the budgeted capacity, which effects the bandwidth/delay provided to other services. > Especially if part of the static configuration would > be the TTL to initiate packets on, for a particular MPLS path. An interesting thought, which I would like to ponder. It turns out that we often know the TTL since we use TTL expiry to deliver OAM messages to MIPS. > > But as for the document being reviewed -- no security issues. > > Radia > > Thanks Stewart > > From jsalowey@cisco.com Mon Aug 3 21:06:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CA33A68B2; Mon, 3 Aug 2009 21:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpTBpV1wF5QV; Mon, 3 Aug 2009 21:06:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5047B3A6F02; Mon, 3 Aug 2009 21:06:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP9Qd0qrR7PD/2dsb2JhbAC8JYgpjxoFgjIBgWU X-IronPort-AV: E=Sophos;i="4.43,318,1246838400"; d="scan'208";a="359785180" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 04:06:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7446k16018983; Mon, 3 Aug 2009 21:06:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7446jQ2028535; Tue, 4 Aug 2009 04:06:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 21:06:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 21:06:44 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-sipping-service-identification-03 Thread-Index: AcoUuPrL24p3k07XRa6+EYrM2OnQvQ== From: "Joseph Salowey (jsalowey)" To: , , , , X-OriginalArrivalTime: 04 Aug 2009 04:06:45.0850 (UTC) FILETIME=[FB70EBA0:01CA14B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1506; t=1249358806; x=1250222806; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Secdir=20review=20of=20draft-ietf-sipping-servi ce-identification-03 |Sender:=20; bh=b4+ehHvzCV0Hmd6AoKpfctzCtF8LhoIXlJA0UzTsmT0=; b=dOX7QlKDGO9pWU5c5SACfI8ALuzjxPG2o1iXtsiMnwHxXUw9SgzcsKM/Kb R5lxu2hLrViNmi1Qa03YlKhGIevmAFroj9Q0vtRoYFgNGxIqiDfcnzt2IZT3 bgrM9qyoqK; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [secdir] Secdir review of draft-ietf-sipping-service-identification-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 04:06:44 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document describes the reason why implicit service identification is preferable of explicit service identification. From a security point of view I agree with this since explicit identification introduces a mapping layer which can be a place where security vulnerabilities can creep in. I thought the security considerations were a bit light since implicit identification still requires the participants to validate, perhaps authenticate and authorize, the signaling information that they are using to identify the service. The secure validation of SIP signaling should be covered in other documents, perhaps a reference to their security consideration should be included. For example, the document mentions that the URI can be a critical piece in determining the service identity: what document describes how to authenticate and authorize this URI down to the level of granularity needed to differentiate service identity? I don't think it is necessary to provide links to means for validating every possible piece of signaling information, but links to the main mechanisms used in across different scenarios would be good.=20 From paul.hoffman@vpnc.org Thu Aug 6 13:24:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0228F3A6E3E for ; Thu, 6 Aug 2009 13:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFyro5LdSXCX for ; Thu, 6 Aug 2009 13:24:55 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 215843A6B14 for ; Thu, 6 Aug 2009 13:24:39 -0700 (PDT) Received: from [192.168.1.101] ([70.158.103.10]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n76KOGTu006772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Aug 2009 13:24:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 6 Aug 2009 00:37:07 -0400 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: leo.vegoda@icann.org, michelle.cotton@icann.org Subject: [secdir] Secdir review of draft-iana-rfc3330bis-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:24:56 -0000 The security considerations that I had on the -06 draft have been fixed in the -07 draft. --Paul Hoffman, Director --VPN Consortium From weiler+secdir@watson.org Thu Aug 6 14:25:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E629D3A694E for ; Thu, 6 Aug 2009 14:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxlKRtYcSmTf for ; Thu, 6 Aug 2009 14:25:25 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id F3F423A687F for ; Thu, 6 Aug 2009 14:25:24 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n76LPRuM019952 for ; Thu, 6 Aug 2009 17:25:27 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n76LPQnW019949 for ; Thu, 6 Aug 2009 17:25:27 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 6 Aug 2009 17:25:26 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Thu, 06 Aug 2009 17:25:27 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 21:25:26 -0000 Steve Hanna is next in the rotation. As described in my messages Monday, please try to complete last call reviews by the end of the last call. I'll be on holiday next week; if there's anything urgent, please contact the ADs. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-08-13 Reviewer Deadline Draft Alan DeKok T 2009-08-11 draft-ietf-mpls-ldp-end-of-lib-03 Tobias Gondrom T 2009-08-11 draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker T 2009-08-11 draft-ietf-nea-pb-tnc-04 Steve Hanna T 2009-08-11 draft-ietf-netconf-partial-lock-09 Vidya Narayanan T 2009-08-11 draft-ietf-opsawg-syslog-snmp-04 Chris Newman T 2009-08-11 draft-ietf-mpls-tp-requirements-09 Brian Weis T 2009-08-11 draft-ietf-dime-diameter-qos-11 For telechat 2009-08-27 Reviewer Deadline Draft Rob Austein T 2009-08-25 draft-ietf-opsawg-syslog-alarm-02 Stephen Farrell T 2009-08-25 draft-ietf-ippm-multimetrics-11 Tobias Gondrom T 2009-08-25 draft-ietf-mext-aero-reqs-04 Glen Zorn T 2009-08-25 draft-ietf-ntp-dhcpv6-ntp-opt-04 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2009-08-14 draft-ietf-pkix-authorityclearanceconstraints-02 Richard Barnes 2009-08-11 draft-ietf-pkix-other-certs-04 Pat Cain 2009-08-10 draft-ietf-tls-extractor-06 Ran Canetti 2009-08-17 draft-ietf-vcarddav-webdav-mkcol-05 Dave Cridland 2009-08-17 draft-turner-clearancesponsor-attribute-01 Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Donald Eastlake 2009-08-19 draft-zorn-radius-pkmv1-05 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-02 Phillip Hallam-Baker 2009-08-18 draft-ietf-pmol-sip-perf-metrics-03 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman 2009-06-29 draft-ietf-ipsecme-ikev2-redirect-13 Julien Laganier 2009-01-22 draft-ietf-sip-certs-08 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-19 Sandy Murphy 2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Vidya Narayanan 2009-06-04 draft-ietf-enum-3761bis-04 Eric Rescorla 2009-06-04 draft-ietf-enum-iax-05 Eric Rescorla 2009-07-16 draft-ietf-simple-xcap-diff-13 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-07-25 draft-ietf-pkix-ta-format-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Nico Williams 2009-08-04 draft-ietf-dime-nai-routing-02 Tom Yu 2009-08-05 draft-ietf-dime-pmip6-02 Kurt Zeilenga 2009-08-03 draft-ietf-hokey-key-mgm-08 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-03 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu 2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04 From rja@extremenetworks.com Thu Aug 6 09:40:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75FB3A6A82; Thu, 6 Aug 2009 09:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzZvcLtTUm5i; Thu, 6 Aug 2009 09:40:18 -0700 (PDT) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by core3.amsl.com (Postfix) with ESMTP id 79D483A6B15; Thu, 6 Aug 2009 09:39:09 -0700 (PDT) Received: from [10.30.20.71] ([70.104.193.39]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KNY00K9ORKE9Z00@vms173015.mailsrvcs.net>; Thu, 06 Aug 2009 11:38:44 -0500 (CDT) Message-id: From: RJ Atkinson To: Hilarie Orman In-reply-to: <200907201957.n6KJvjQv016672@localhost.localdomain> Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit MIME-version: 1.0 (Apple Message framework v936) Date: Thu, 06 Aug 2009 12:38:33 -0400 References: <200907201957.n6KJvjQv016672@localhost.localdomain> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Thu, 06 Aug 2009 22:16:15 -0700 Cc: "secdir@ietf.org" , "mjbarnes@cisco.com" , "mfanto@aegisdatasecurity.com" , "tony.li@tony.li" , "iesg@ietf.org" , "acee@redback.com" , "manav@alcatel-lucent.com" , "akr@cisco.com" , "riw@cisco.com" Subject: Re: [secdir] Review of draft-ietf-ospf-hmac-sha-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:40:19 -0000 Hilarie, Thank you very much for your careful review. Thanks to your efforts, several errors were caught and have been corrected. A detailed response to your review follows in-line. Earlier, Hilarie Orman wrote: % Review of draft-ietf-ospf-hmac-sha-05.txt % %"Introduction % The creation of this addition to OSPFv2 was driven by operator % requests that they be able to use the NIST SHS family of % algorithms in the NIST HMAC mode, instead of being forced % to use the Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic % Authentication." % % A reference (minutes of a NANOG meeting?) would be helpful. We do not know of a crisp reference that can be cited here. Several of the authors have heard interest from operators; operators are also present in OSPF WG meetings. This draft has been discussed in more than one OSPF WG meeting. % Section 3 gives SHA-1 a "should". Why? I can see a "should" % on MD5 for backward compatibility, but SHA-1 should have died % aborning. Changing this would reduce WG Consensus, so we have kept the current text. % Section 3.1 says that the combining method is described in section % 3.2, but 3.3 is the actual location. This correction has been made. % Section 3.2, in the paragraph about authentication keys, refers % to "K in section 3.2 above". This makes no sense; the reference % should probably be deleted. That sentence has been corrected to read: This is noted as "K" in Section 3.3 below. % In section 3.3: "K is the selected OSPFv2 key". The % statement should use the terminology of section 3.2 and % say "K is the authentication key for the OSPFv2 security % association". That correction has been made. % Section 3.3: "B is the block size of H, measured in octets, % rather than bits". % Two problems: 1. the indentation format is irregular, % 2. nothing has suggested measuring in bits, so the % "rather than" is gratuitous. The same holds for the comment % regarding the length of L. Changing the text would reduce WG Consensus. It is believed that the current text is more clear than the proposed edits would make the text. % Section 4, Security Considerations. % % The second paragraph, while correct in the sense that it % says nothing wrong, does not do a good job of explaining % the numerous "concerns". There should be a plausible argument % about the value of switching to the SHA family, and a little % more about the value of HMAC over prepended key. The current text represents a compromise within the WG, and is strictly correct. Most importantly, it makes no claims that are not supported by a reference to the literature. Changing the text would reduce consensus in the WG. Moving to the SHA family is primarily driven by operators with local policy preferences for SHA (e.g. US/UK Governments). % Is there a reference for the US govmt's preference % for the SHA family? The authors do not know of a specific reference to cite, but are happy to accept the word of the Security AD. At least one author has heard this directly from USG employees. % I don't think the section does justice to the problem of replay. % It's my (perhaps flawed) understanding that RFC2838 strongly % recommends using a random initial sequence number, so the % comments about always starting from zero seem wrong (unless % there is some reason to believe that implementations do not % adhere to the RFC2838 guidance). At least some implementations have not adhered to that RFC-2328 guidance. It is difficult to ascertain if those implementations are in active use at present, as the OSPF installed base is quite large. % Further, a passive observer of two sessions can insert replay % packets, with appropriate sequence numbers, at any time, % because the authentication key is static. Yes, provided the OSPF SA never changes, that is true. It is at least conceivable that an operator would use implementation-specific methods (e.g. a provisioning script built around Tcl/Expect, SSH, and a particular implementation's CLI) to create and remove OSPF SAs. We do not discuss that approach in this draft because it is inherently non-standard and this is a standards- track document. % RFC2838 seems to mandate a tear-down on any sequence % number mismatch. Tearing down the OSPF Security Association would cause the OSPF routers to be unable to communicate, and interior routing would fail. This is considered strongly undesirable in the operational world. Changing the OSPF behaviour to mandate such a tear-down would greatly reduce consensus within the OSPF WG. % Altogether, this seems more serious to me than the % MD5 collisions. At least one author (me) agrees with the reviewer, but some other authors are known to believe that use of MD5 is the greater vulnerability. The existing text is, therefore, a compromise. In any event, in reaction to the preceding 4 comments, portions of the Security Considerations text have been revised to read as follows: This mechanism is vulnerable to a replay attack by any on-link node. An on-link node could record a legitimate OSPF packet sent on the link, then replay that packet at the next time the recorded OSPF packet's sequence number is valid. This replay attack could cause significant routing disruptions within the OSPF domain. Ideally, for example to prevent the preceding attack, each OSPF Security Association would be replaced by a new and different OSPF Security Association before any sequence number were reused. As of the date this document was published, no form of automated key management has been standardised for OSPF. So, as of the date this document was published, common operational practice has been to use the same OSPF authentication key for very long periods of time. This operational practice is undesirable for many reasons. Therefore, it is clearly desirable to develop and standardise some automated key management mechanism for OSPF. We further note that the IETF KMART effort has the subject of the last paragraph above firmly within its sights. There is no obvious benefit to delaying this document until the KMART process has finished its work. % I think that a stronger statement about IPsec (I think that % is what is meant by the penultimate paragraph in section 4; % there is no reference) could be made. We have edited that paragraph to read: Because of implementation considerations, including the need for backwards compatibility, this specification uses the same mechanism as specified in RFC 2328 and limits itself to adding support for additional cryptographic hash functions. Also, some large network operators have indicated they prefer to retain the basic mechanism defined in RFC 2328, rather than migrate to IP Security, due to deployment and operational considerations.[RFC 4301] If all the OSPFv2 routers supported IPsec, then IPsec tunnels could be used in lieu of this mechanism. This would, however, relegate the topology to point-to-point adjacencies over the mesh of IPsec tunnels. % I'm not sure that "full digital signatures" would be a stronger % authentication method. That paragraph currently reads: If a stronger authentication were believed to be required, then the use of a full digital signature [RFC 2154] would be an approach that should be seriously considered. Use of full digital signatures would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, in addition to eliminating the replay issue that was noted above. (Aside: The longish author list is the result of merging 2 drafts together. There is both IESG and RFC-Editor precedent for longish author lists in such a case.) Yours, Ran Atkinson rja@extremenetworks.com (Active document editor) From canetti@post.tau.ac.il Sun Aug 9 21:54:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B5C3A6AA1; Sun, 9 Aug 2009 21:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZppMLI9W+LZr; Sun, 9 Aug 2009 21:54:35 -0700 (PDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id ACBD23A6D32; Sun, 9 Aug 2009 21:54:33 -0700 (PDT) Received: from [192.168.1.47] (unknown [96.237.134.182]) by doar.tau.ac.il (Postfix) with ESMTP id EAAA3BEF5; Mon, 10 Aug 2009 07:54:33 +0300 (IDT) Message-ID: <4A7FA802.9040106@post.tau.ac.il> Date: Mon, 10 Aug 2009 00:54:26 -0400 From: Ran Canetti User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: secdir , iesg@ietf.org, cyrus@daboo.name Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] [Fwd: SECDIR review of draft-ietf-vcarddav-webdav-mkcol-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 04:54:36 -0000 *** I have reviewed this document as part of the security directorate's *** ongoing effort to review all IETF documents being processed by the *** IESG. These comments were written primarily for the benefit of the *** security area directors. Document editors and WG chairs should treat *** these comments just like any other last call comments. The draft describes an update for the MKCOL request in WebDAV. The update essentially allows for establishing a generic collection on the server (in XML), thus reducing the need for creating additional methods. The document states that this generalization has no security implications. I'm far from being a WebDAV or XML expert, and it might well be the case that the document is correct in this assertion. But, at least on the face of things, it seems that allowing clients to make generic XML MKCOL requests might make it harder for servers to protect against compromise by malicious clients. (At least some of the curbs that were put before, by forcing specific MKCOL requests per application, may now be removed.) It might be good to discuss this potential concern and clarify its relevance/irrelevance. Best, Ran From shanna@juniper.net Mon Aug 10 07:32:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C1A28C124; Mon, 10 Aug 2009 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuYtHh2wtuaB; Mon, 10 Aug 2009 07:32:24 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 4B64F3A6DA9; Mon, 10 Aug 2009 07:32:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSoAveFd+N+ZJT7bOxLIRRYIWNlqSYZq2@postini.com; Mon, 10 Aug 2009 07:32:28 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 10 Aug 2009 07:29:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 10 Aug 2009 10:29:25 -0400 From: Stephen Hanna To: "iesg@ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-partial-lock@tools.ietf.org" Date: Mon, 10 Aug 2009 10:28:38 -0400 Thread-Topic: secdir review of draft-ietf-netconf-partial-lock-09.txt Thread-Index: AcoPYx3URs99g7Z4T5WHm8QuiidkTgKXveKA 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:32:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines optional partial-lock and partial-unlock operations to be added to the NETCONF protocol. These operations are used to lock only part of a configuration datastore, allowing multiple management sessions to modify the configuration of a device at a single time. The Security Considerations section of the document highlights the risk that a malicious party might employ partial locks to impede access to a device's configuration. Therefore, it states "Only an authenticated and authorized user can request a partial lock." Unfortunately, I cannot find any normative text (MUST) that supports this statement. The NETCONF spec (RFC 4741) says "NETCONF connections must be authenticated" but this is not clearly normative. Perhaps a NETCONF expert can point to some normative text requiring authentication and authorization for any party requesting a partial lock. If not, I suggest that such normative text be added to the partial-lock specification. Another security concern that I have related to the partial-lock operation is that the configuration might become inconsistent if one manager changes one part of a datastore at the same time that another manager changes another part. The resulting inconsistency could have security implications. For example, an organization might have a rule that either the firewall or the intrusion detection features must be enabled on a device. If one manager might lock intrusion detection configuration, check that the firewall is enabled, and then disable intrusion detection. Another manager might lock the firewall configuration, check that intrusion detection is enabled, and then disable the firewall. If those operations were interleaved, they could result in a violation of policy. To address this concern, I suggest that the draft contain a warning that parallel operations are tricky and should be carefully considered. Sometimes, it may be necessary to lock a portion of the datastore that will not be modified, just to ensure the datastore remains consistent and compliant with policy. Of course, a human administrator using a GUI could easily run into this same problem if the human does not have the ability to control configuration locks. The human might look at the firewall configuration to make sure that it's enabled and then switch to another section of the display to disable the intrusion detection function. If the management console only locks the datastore to execute the administrator's request to disable intrusion detection, overlapping operations from another administrator could result in a bad configuration. This problem can arise even without the partial lock operation. Probably the best that can be done here is to include language warning of this sort of problem. Warning human administrators that someone else is also editing the device should help and giving these administrators the ability to easily communicate with each other to coordinate their work would also probably help. Here are a few minor issues: * At the end of section 2.1.1.2, the comma in the last sentence is superfluous. * In section 2.1.1.3 in the sentence "Manager A terminates it's session", the apostrophe should be removed. * In section 2.4.1, I think that the sentence that begins with "If someone later creates a new interface" would be clearer if the second comma was changed to "so". * Later in section 2.4.1, the sentence that begins with "A NETCONF server MUST" should instead start with "A NETCONF server that supports partial locks MUST". I think that paragraph should end with "all of the overlapping locks are released" not "all of the locks are released". From aland@deployingradius.com Mon Aug 10 08:22:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B29D3A6BA8; Mon, 10 Aug 2009 08:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc4HWKVSfAOO; Mon, 10 Aug 2009 08:22:01 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 725523A6D07; Mon, 10 Aug 2009 08:22:01 -0700 (PDT) Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 6D4F11234593; Mon, 10 Aug 2009 17:22:04 +0200 (CEST) Message-ID: <4A803B1C.3040007@deployingradius.com> Date: Mon, 10 Aug 2009 17:22:04 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: secdir@ietf.org, IESG IESG , draft-ietf-mpls-ldp-end-of-lib-03@tools.ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-mpls-ldp-end-of-lib-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 15:22:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an mechanism to signal "end of label" advertisement to an LDP peer. It uses pre-existing security mechanisms in LDP to protect the LDP traffic. As such, it appears to have no additional security issues over and above those in LDP. Alan DeKok. From Kurt.Zeilenga@Isode.com Mon Aug 10 09:49:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725283A6E79; Mon, 10 Aug 2009 09:49:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC-6VhtUWRgl; Mon, 10 Aug 2009 09:49:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 65AA128C18A; Mon, 10 Aug 2009 09:49:03 -0700 (PDT) Received: from [172.16.2.183] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Aug 2009 17:49:05 +0100 Message-Id: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> From: Kurt Zeilenga To: secdir@ietf.org, iesg@ietf.org Date: Mon, 10 Aug 2009 09:49:02 -0700 X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: draft-ietf-hokey-key-mgm@tools.ietf.org Subject: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:49:39 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The security consideration starts by saying: This section provides security requirements and an analysis on transporting EAP keying material using an AAA protocol. While 6.1 appears to provide the former, 6.2 (the remaining section) seems to discuss a particular concern in transporting EAP keying material in an APP protocol. That is, the "analysis" appears to be limited to a particular concern. Is this the only concern? I would like to see the Security Consideration section to incorporate by informative references general discussions of security considerations for key technologies (e.g., EAP). Beyond this, I'm afraid I do not have sufficient experience in the key technologies to be able to determine if security considerations are well covered or not. Regards, Kurt From glenzorn@comcast.net Mon Aug 10 10:29:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F413A6824 for ; Mon, 10 Aug 2009 10:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1iLIiM-7B3T for ; Mon, 10 Aug 2009 10:29:46 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 9312F3A6EFB for ; Mon, 10 Aug 2009 10:29:46 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Sf0u1c00k0EPchoA6hVrXJ; Mon, 10 Aug 2009 17:29:51 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id ShVp1c00M01ae1j8MhVqUh; Mon, 10 Aug 2009 17:29:51 +0000 From: "Glen Zorn" To: "'Kurt Zeilenga'" , , References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> In-Reply-To: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> Date: Mon, 10 Aug 2009 10:29:24 -0700 Message-ID: <00bf01ca19e0$1b703e70$5250bb50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZ2pSXOn6w+gMtQGqXmDoKX4ZQ2QAA7NIw Content-Language: en-us Cc: draft-ietf-hokey-key-mgm@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:29:47 -0000 Kurt Zeilenga [mailto://Kurt.Zeilenga@Isode.com] writes: ... > The security consideration starts by saying: > This section provides security requirements and an analysis on > transporting EAP keying material using an AAA protocol. > While 6.1 appears to provide the former, 6.2 (the remaining section) > seems to discuss a particular concern in transporting EAP keying > material in an APP protocol. No. AFAIK, the only existing protocols in which EAP key transport take place are AAA. > That is, the "analysis" appears to be > limited to a particular concern. What the double quotes? ? Is this the only concern? I would assume so; does that need to be spelled out? > I would like to see the Security Consideration section to incorporate > by informative references general discussions of security > considerations for key technologies (e.g., EAP). Why? The EAP (or ERP) authentication is by definition complete by the time any keys are exported by the EAP method, so it's hard to see how those considerations are relevant. > Beyond this, I'm afraid I do not have sufficient experience in the key > technologies to be able to determine if security considerations are > well covered or not. > Regards, Kurt > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From pcain2@mail2.coopercain.com Mon Aug 10 11:02:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AA13A6359; Mon, 10 Aug 2009 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74TgCXgxbcua; Mon, 10 Aug 2009 11:02:38 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id 7D1123A6E72; Mon, 10 Aug 2009 11:02:38 -0700 (PDT) Received: from familyroom (familyroom8.bc.edu [136.167.27.78]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id n7AG1HWB001594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 11:01:58 -0500 Received: from familyroom by familyroom (PGP Universal service); Mon, 10 Aug 2009 12:01:59 -0500 X-PGP-Universal: processed; by familyroom on Mon, 10 Aug 2009 12:01:59 -0500 From: "pat cain" To: , , Date: Mon, 10 Aug 2009 12:01:17 -0400 Message-ID: <078f01ca19d3$ce6e7620$6b4b6260$@coopercain.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZ08Jv4fKiOlQZThuonAZ7QwbYVA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-tls-extractor-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:02:39 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. The document looks alright to me. Pat Cain From Kurt.Zeilenga@Isode.com Mon Aug 10 11:34:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD383A6EBF; Mon, 10 Aug 2009 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNcxddvNgVjW; Mon, 10 Aug 2009 11:34:39 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id D9BF33A6F10; Mon, 10 Aug 2009 11:33:44 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n7AIXZt3082374; Mon, 10 Aug 2009 18:33:36 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: From: Kurt Zeilenga To: Glen Zorn In-Reply-To: <00bf01ca19e0$1b703e70$5250bb50$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 11:33:34 -0700 References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> X-Mailer: Apple Mail (2.936) Cc: draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:34:39 -0000 On Aug 10, 2009, at 10:29 AM, Glen Zorn wrote: > Kurt Zeilenga [mailto://Kurt.Zeilenga@Isode.com] writes: > > ... > >> The security consideration starts by saying: >> This section provides security requirements and an analysis on >> transporting EAP keying material using an AAA protocol. >> While 6.1 appears to provide the former, 6.2 (the remaining section) >> seems to discuss a particular concern in transporting EAP keying >> material in an APP protocol. > > No. AFAIK, the only existing protocols in which EAP key transport > take > place are AAA. My point that Section 6 description of what section 6.2 provides seems not equate (to me) to what 6.2 actually provides. 6.2 seems to discuss a particular issue in "transporting EAP keying material using an AAA protocol" as opposed to a more comprehensive "analysis on transporting EAP keying material using an AAA protocol". > ? Is this the only concern? > > I would assume so; does that need to be spelled out? Not necessarily. > >> I would like to see the Security Consideration section to incorporate >> by informative references general discussions of security >> considerations for key technologies (e.g., EAP). > > Why? The EAP (or ERP) authentication is by definition complete by > the time > any keys are exported by the EAP method, so it's hard to see how those > considerations are relevant. As the document discusses use of KDE in ERP, it would seem to me that ERP security considerations would have some relevance. I find statements such as: ERP security considerations are discussed in [RFCxxxx]. EAP security considerations are discussed in [RFCyyyy]. useful as they further encourage the reader to consider security considerations of key technologies. > >> Beyond this, I'm afraid I do not have sufficient experience in the >> key >> technologies to be able to determine if security considerations are >> well covered or not. >> Regards, Kurt >> >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > From dave.cridland@isode.com Mon Aug 10 13:53:37 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C793A68BF; Mon, 10 Aug 2009 13:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHJmhk09s+CR; Mon, 10 Aug 2009 13:53:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6E6F63A62C1; Mon, 10 Aug 2009 13:53:36 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Aug 2009 21:53:23 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <8048.1249937599.500468@puncture> Date: Mon, 10 Aug 2009 21:53:19 +0100 From: Dave Cridland To: Security Area Directorate , The IESG , MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [secdir] Security Directorate Review of draft-turner-clearancesponsor-attribute X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:53:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. (I would note for the record that I roped in Kurt Zeilenga to check certain issues, but I nevertheless take full credit for any errors). This is a straighforward definition of an attribute suitable for X.509 certificates (either public key or attribute) or X.500/LDAP directory entries which carries the name of the clearance sponsor, that is, the entity which initiated and maintains the assignment of the clearance. I note that recent cases where a DirectoryName has been used with X.509 for authentication - in particular usage of the CommonName of the Subject Name - have been subjected to attacks using embedded NULs. Whilst presumably using the correct equality matching rule prevents this, it'd be nice to see that called out. (If the equality matching rule does not prevent this case, that's obviously more serious). Mandating that NUL is not a valid codepoint in this attribute would probably be useful, too. General notes: It's not entirely clear to me why one would want to consider this as part of an authorization check, unless one was attempting to match the name of the sponsor against a list of "known good" sponsors - that is, if a sponsor was subsequently revoked as a whole as being a suitable sponsor, one might want the sponsored clearances to be pulled as well. (It might be useful to note *why* one might want to do this, within the draft). However, it occurs to me that this kind of matching might be better done against an OID, such as one from the Enterprise arc, rather than a simple string, which might prove to be subject to human foibles. Dave. -- From glenzorn@comcast.net Mon Aug 10 18:24:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14263A6F82 for ; Mon, 10 Aug 2009 18:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwxllSJ-vLKr for ; Mon, 10 Aug 2009 18:24:30 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 30F3928C181 for ; Mon, 10 Aug 2009 18:23:53 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id SlBA1c0050lTkoCA3pPxtA; Tue, 11 Aug 2009 01:23:57 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id SpPv1c00d01ae1j8QpPw3c; Tue, 11 Aug 2009 01:23:57 +0000 From: "Glen Zorn" To: "'Kurt Zeilenga'" References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> In-Reply-To: Date: Mon, 10 Aug 2009 18:23:30 -0700 Message-ID: <004f01ca1a22$56af4de0$040de9a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZ6RjwgdOHSJLUTSaXyXUToQZhhgAKfEsg Content-Language: en-us Cc: gwz@net-zen.net, draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:24:30 -0000 Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com] writes: > On Aug 10, 2009, at 10:29 AM, Glen Zorn wrote: > > > Kurt Zeilenga [mailto://Kurt.Zeilenga@Isode.com] writes: > > > > ... > > > >> The security consideration starts by saying: > >> This section provides security requirements and an analysis on > >> transporting EAP keying material using an AAA protocol. > >> While 6.1 appears to provide the former, 6.2 (the remaining section) > >> seems to discuss a particular concern in transporting EAP keying > >> material in an APP protocol. > > > > No. AFAIK, the only existing protocols in which EAP key transport > > take > > place are AAA. > > My point that Section 6 description of what section 6.2 provides seems > not equate (to me) to what 6.2 actually provides. 6.2 seems to > discuss a particular issue in "transporting EAP keying material using > an AAA protocol" as opposed to a more comprehensive "analysis on > transporting EAP keying material using an AAA protocol". OK. Can you be a little more specific about what needs to be changed? ... > >> I would like to see the Security Consideration section to > incorporate > >> by informative references general discussions of security > >> considerations for key technologies (e.g., EAP). > > > > Why? The EAP (or ERP) authentication is by definition complete by > > the time > > any keys are exported by the EAP method, so it's hard to see how > those > > considerations are relevant. > > As the document discusses use of KDE in ERP, it would seem to me that > ERP security considerations would have some relevance. Thanks for pointing that out. In fact, the document should _not_ talk about the use of KDE in ERP, since it doesn't exist ;-). Re-re-re-reading ;-) section 6 (which is what I think you are talking about?), I noticed A couple of other errors, too. For example, section 3 says "Here, EAP-Initiate and EAP-Finish messages are exchanged between the peer and the home AAA server, with the bootstrapping flag in the EAP-Initiate message set"; unfortunately, this is impossible, since the peer and AAA server do not speak the same protocol. Another example of the same kind of fuzzy writing is in the second paragraph of the same section: "In this case, the local ER server requesting the DSRK MUST include a KDE-Request message in the first EAP-Response message from the peer". This _should_ say " In this case, the local ER server requesting the DSRK MUST include a KDE-Request message in the AAA packet encapsulating the first EAP-Response message from the peer" in order to agree with RFC 5296 (in fact, though, there's no need for the local ERP server to be involved in this at all, except that that is (erroneously, I think) specified in 5296). ... From Kurt.Zeilenga@Isode.com Mon Aug 10 18:35:32 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153D23A6B47; Mon, 10 Aug 2009 18:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ld0Yms0V0jK; Mon, 10 Aug 2009 18:35:31 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CC8923A6C35; Mon, 10 Aug 2009 18:35:30 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 11 Aug 2009 02:35:32 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <96E918F7-9D6D-4985-841E-5C170C7CF9F4@Isode.com> From: Kurt Zeilenga To: Glen Zorn In-Reply-To: <004f01ca1a22$56af4de0$040de9a0$@net> Date: Mon, 10 Aug 2009 18:35:23 -0700 References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: gwz@net-zen.net, draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:35:32 -0000 On Aug 10, 2009, at 6:23 PM, Glen Zorn wrote: > Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com] writes: > >> On Aug 10, 2009, at 10:29 AM, Glen Zorn wrote: >> >>> Kurt Zeilenga [mailto://Kurt.Zeilenga@Isode.com] writes: >>> >>> ... >>> >>>> The security consideration starts by saying: >>>> This section provides security requirements and an analysis on >>>> transporting EAP keying material using an AAA protocol. >>>> While 6.1 appears to provide the former, 6.2 (the remaining >>>> section) >>>> seems to discuss a particular concern in transporting EAP keying >>>> material in an APP protocol. >>> >>> No. AFAIK, the only existing protocols in which EAP key transport >>> take >>> place are AAA. >> >> My point that Section 6 description of what section 6.2 provides >> seems >> not equate (to me) to what 6.2 actually provides. 6.2 seems to >> discuss a particular issue in "transporting EAP keying material using >> an AAA protocol" as opposed to a more comprehensive "analysis on >> transporting EAP keying material using an AAA protocol". > > OK. Can you be a little more specific about what needs to be changed? The following change would align the text of 6 with the content of its two subsections: OLD: This section provides security requirements and an analysis on transporting EAP keying material using an AAA protocol. NEW: This section provides security requirements and a discussion of distributing RK without peer consent. -- Kurt From glenzorn@comcast.net Mon Aug 10 18:39:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF3F3A6980 for ; Mon, 10 Aug 2009 18:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P69Ye2yXQtpQ for ; Mon, 10 Aug 2009 18:39:39 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id 50C933A68E9 for ; Mon, 10 Aug 2009 18:39:39 -0700 (PDT) Received: from OMTA22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id SpMU1c0091vN32cABpfE0q; Tue, 11 Aug 2009 01:39:14 +0000 Received: from gwzPC ([71.231.55.1]) by OMTA22.emeryville.ca.mail.comcast.net with comcast id Spj31c00101ae1j8ipj3eU; Tue, 11 Aug 2009 01:43:04 +0000 From: "Glen Zorn" To: "'Kurt Zeilenga'" References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> <96E918F7-9D6D-4985-841E-5C170C7CF9F4@Isode.com> In-Reply-To: <96E918F7-9D6D-4985-841E-5C170C7CF9F4@Isode.com> Date: Mon, 10 Aug 2009 18:39:16 -0700 Message-ID: <005501ca1a24$8a9cd800$9fd68800$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoaJAlC365MupZRTZGfP8CG2whQZAAAE9qA Content-Language: en-us Cc: gwz@net-zen.net, draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:39:40 -0000 Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com] writes: ... > >> My point that Section 6 description of what section 6.2 provides > >> seems > >> not equate (to me) to what 6.2 actually provides. 6.2 seems to > >> discuss a particular issue in "transporting EAP keying material > using > >> an AAA protocol" as opposed to a more comprehensive "analysis on > >> transporting EAP keying material using an AAA protocol". > > > > OK. Can you be a little more specific about what needs to be > changed? > > The following change would align the text of 6 with the content of its > two subsections: > > OLD: > This section provides security requirements and an analysis on > transporting EAP keying material using an AAA protocol. > NEW: > > This section provides security requirements and a discussion of > distributing RK without peer consent. Thanks! > > -- Kurt From derek@ihtfp.com Tue Aug 11 13:53:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AAF3A6FBA; Tue, 11 Aug 2009 13:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObnArGOW+CfC; Tue, 11 Aug 2009 13:53:23 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 692973A6FAE; Tue, 11 Aug 2009 13:53:23 -0700 (PDT) Received: from pgpdev.ihtfp.org (PGPDEV.IHTFP.ORG [204.107.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 81FC1BD8441; Tue, 11 Aug 2009 15:49:35 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n7BJnWQ8022146; Tue, 11 Aug 2009 15:49:32 -0400 To: iesg@ietf.org, secdir@ietf.org From: Derek Atkins Date: Tue, 11 Aug 2009 15:49:32 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pkix-chairs@tools.ietf.org, SChokhani@cygnacom.com Subject: [secdir] sec-dir review of draft-ietf-pkix-authorityclearanceconstraints-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 20:53:24 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), CA public key certificates, and an Attribute Authority (AA) public key certificate in a public key certification path constrain the effective Clearance of the subject. As with all certificate attributes (in particular constraints), it's always a question of when to use them and what to do when the attribute doesn't exist. In this case the mere presence of an attribute could release classified information, but luckily this is briefly mentioned in the Security Considerations section. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From khoeper@motorola.com Tue Aug 11 15:10:08 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A063A6DB6; Tue, 11 Aug 2009 15:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r8MdI5jnrdS; Tue, 11 Aug 2009 15:10:07 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 67B6A3A6AC9; Tue, 11 Aug 2009 15:10:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-12.tower-55.messagelabs.com!1250028067!93405119!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27373 invoked from network); 11 Aug 2009 22:01:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2009 22:01:07 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7BM17D9005711; Tue, 11 Aug 2009 15:01:07 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n7BM16CJ008504; Tue, 11 Aug 2009 17:01:06 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n7BM16P2008499; Tue, 11 Aug 2009 17:01:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 18:00:44 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06555C0E@de01exm68.ds.mot.com> In-Reply-To: <005501ca1a24$8a9cd800$9fd68800$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [secdir] SECDIR review of draft-ietf-hokey-key-mgm thread-index: AcoaJAlC365MupZRTZGfP8CG2whQZAAAE9qAACqFDpA= References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> <96E918F7-9D6D-4985-841E-5C170C7CF9F4@Isode.com> <005501ca1a24$8a9cd800$9fd68800$@net> From: "Hoeper Katrin-QWKN37" To: "Glen Zorn" , "Kurt Zeilenga" X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 11 Aug 2009 15:25:00 -0700 Cc: gwz@net-zen.net, draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 22:10:08 -0000 Hi Kurt, Thank you for your comments. I agree that the sentence in Section 6 is misleading and will make the changes you proposed. Best regards, Katrin=20 > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] > Sent: Monday, August 10, 2009 8:39 PM > To: 'Kurt Zeilenga' > Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-hokey-key- > mgm@tools.ietf.org; gwz@net-zen.net > Subject: RE: [secdir] SECDIR review of draft-ietf-hokey-key-mgm >=20 > Kurt Zeilenga [mailto:Kurt.Zeilenga@Isode.com] writes: >=20 > ... >=20 > > >> My point that Section 6 description of what section 6.2 provides > > >> seems > > >> not equate (to me) to what 6.2 actually provides. 6.2 seems to > > >> discuss a particular issue in "transporting EAP keying material > > using > > >> an AAA protocol" as opposed to a more comprehensive "analysis on > > >> transporting EAP keying material using an AAA protocol". > > > > > > OK. Can you be a little more specific about what needs to be > > changed? > > > > The following change would align the text of 6 with the content of its > > two subsections: > > > > OLD: > > This section provides security requirements and an analysis on > > transporting EAP keying material using an AAA protocol. > > NEW: > > > > This section provides security requirements and a discussion of > > distributing RK without peer consent. >=20 > Thanks! >=20 > > > > -- Kurt From bew@cisco.com Tue Aug 11 18:31:09 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D215E3A68AF; Tue, 11 Aug 2009 18:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-7ztyCMR6Bg; Tue, 11 Aug 2009 18:31:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 984223A6782; Tue, 11 Aug 2009 18:31:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADK4gUqrR7MV/2dsb2JhbAC6S4grNQEBBgGQLQWCMw0MAQGBSw X-IronPort-AV: E=Sophos;i="4.43,364,1246838400"; d="scan'208";a="226690502" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 01:29:27 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7C1TRnl001683; Tue, 11 Aug 2009 18:29:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7C1TRFQ029075; Wed, 12 Aug 2009 01:29:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 18:29:26 -0700 Received: from dhcp-128-107-163-100.cisco.com ([128.107.163.100]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Aug 2009 18:29:26 -0700 Message-Id: <8A566855-FDC1-4907-BCBB-55871F805374@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 11 Aug 2009 18:29:24 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 01:29:26.0644 (UTC) FILETIME=[548A6340:01CA1AEC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5968; t=1250040567; x=1250904567; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Secdir=20review=20of=20draft-ietf-dime-diameter -qos-11.txt |Sender:=20; bh=iglckixita6xpO9mOge4GoNqb5OPfTZruEl9tnxywS0=; b=PAlGpmndedK0VSCzeuhpT/815KP4wILJB7bznissGEdNgGkNsPlk6zOpxv y2TGyd/5fgGHupKqFlpkm0Ll8LyqGkmolfHuOlPM5qLRhHnk8/MKK9M/sRdt XEUVa0e9RQWc2YprtV7EWTxoUiHtZyHwfV8Gm3QhNsf93TqQIIkz4=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-diameter-qos@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-dime-diameter-qos-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 01:31:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a Diameter Quality of Service (QoS) application, which allows network elements to interact with Diameter servers when allocating QoS resources in the network. It re-uses the Diameter Base Protocol (RFC 3588) packet formats for this new application. New message flows between Network Elements (acting as Diameter Clients) and Authorizing Entities (acting as Diameter Servers) are defined. Examples are given as to how the new flows fit into various QoS methods. This document seems to be mature. I have some detailed comments/ questions, but they are primarily suggesting additional topics for the Security Considerations section and a suggestion to better clarify how "identities" are used. The Security Considerations section of this document describes various threats to Diameter messaging, which are accurate, but more precisely apply to the Base Protocol rather than the use case presented in this I-D. That is, the need for authentication, authorization, integrity and confidentiality is no different for this I-D than for RFC 3588. I see no problem with the existing text, but a statement that the Security Considerations in RFC 3588 also apply would also be appropriate (especially as that document discusses mitigations to the threats described here). I don't believe there is a sufficient discussion in the Security Considerations regarding the threats to the QoS application itself. Let me try to explain. If I'm not mistaken, the traditional Diameter Base Protocol use case consists of a login service on an access port and a Diameter Client that provide no access to the user until the Diameter Server returns positive results. As such, mitigating threats to the messages (using some form of transport security) is the primary consideration to the Base Protocol -- it is understood that the actual device trying to access the network is being denied access by the login service until the Diameter exchange finishes. However, the QoS application brings two new dynamic actors into the solution: the Resource Requesting Entity (RRE) (using unspecified and possibly unsecured QoS request protocols), and a potential man-in-the-middle actor between the RRE and the Network Element. I understand that how those messages are protected between an RRE and a Network Element is outside the scope of this document, but because the Network Element/ Diameter Client acts on those messages there are additional threats to the QoS application that should be described. Here are some threats that occur to me: 1. In some (if not all) cases, the the Diameter Client translates information provided by the RRE (as shown in Figure 3), and includes it in a QoS-Request (described in Section 5.1) sent to the Diameter Server. In particular, the the QoS-Request may include a number of identification fields that, if blindly accepted from an RRE QoS Request message, could be cause the Diameter QoS service to allow authorizations that it should not (or conversely, deny authorizations unnecessarily). Of course, the same is true for the QoS parameters. I would expect the security consideration section to discuss the risks of the Network Element acting on these fields. For example, recommending that adequate transport security be used between the RRE and the Network Element to mitigate the man-in-the-middle threat. 2. A Token-based Three Party Scheme (Figure 4) may mitigate the threat of an RRE lying about its own identity. However, I see no means described by which the Diameter Client can have assurance that the RRE presenting the token was actually the RRE given that particular token. Perhaps there is an assumption that the Network Client will have previously authenticated the RRE and can verify the Username in a token to a Username associated with an access port. A discussion of how the Network Element maps the token to an identity would be useful. Here are a few comments on the rest of the document: 3. Figures 3, 4, and 5 show a "financial settlement" line between an an "Entity authorizing resource request" and a Network Element. It is odd to think of a Network Element (e.g., router) participating in a financial transaction. Wouldn't it be more likely that the "Entity authorizing resource request" would be a proxy device in the home network that speaks back-end protocols for both authorization and financial settlement to a visited network device? 4. Section 3.4 includes requirements titled "Identity-based Routing" and "Associating QoS Reservations and Application State", which essential require that the Diameter Server must be given identities that it trusts. Comments 1 and 2 above really are questioning how this requirement is actually met. Since this is a critical point, it would be worth adding some discussion in the text regarding how accurate identities can be obtained by the Diameter Client. By the way, what identity types does the Diameter QoS application expect to use? Username, IP address, and/or Hostname? Is mapping an IP address to a Username important? This might be valuable discussion to add. 5. Section 4.2.3. The term "Diameter QoS application node" is used exclusively in this section. Does it refer to a Diameter QoS client, server, or both? Clarifying this would be good. Thanks, Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From gwz@net-zen.net Tue Aug 11 20:43:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C2B3A66B4 for ; Tue, 11 Aug 2009 20:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=1.796, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8wcYN6eFEky for ; Tue, 11 Aug 2009 20:43:37 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 60B313A6947 for ; Tue, 11 Aug 2009 20:43:37 -0700 (PDT) Received: (qmail 30295 invoked from network); 12 Aug 2009 03:42:28 -0000 Received: from unknown (71.231.55.1) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 12 Aug 2009 03:42:27 -0000 From: "Glen Zorn" To: "'Hoeper Katrin-QWKN37'" , "'Glen Zorn'" , "'Kurt Zeilenga'" References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> <3A241A6B234BE948B8B474D261FEBC2F06555C24@de01exm68.ds.mot.com> In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F06555C24@de01exm68.ds.mot.com> Date: Tue, 11 Aug 2009 20:42:00 -0700 Organization: Network Zen Message-ID: <010e01ca1afe$d9c82b70$8d588250$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoZ6RjwgdOHSJLUTSaXyXUToQZhhgAKfEsgAC8KAkAAC4hLEA== Content-Language: en-us Cc: draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 03:43:38 -0000 Hoeper Katrin-QWKN37 [mailto:khoeper@motorola.com] writes: ... > > Thanks for pointing that out. In fact, the document should _not_ > talk > > about > > the use of KDE in ERP, since it doesn't exist ;-). Re-re-re-reading > ;-) > > section 6 (which is what I think you are talking about?), I noticed > > A couple of other errors, too. For example, section 3 says "Here, > > EAP-Initiate and EAP-Finish messages are exchanged between the peer > and > > the > > home AAA server, with the bootstrapping flag in the EAP-Initiate > message > > set"; unfortunately, this is impossible, since the peer and AAA > server > do > > not speak the same protocol. Another example of the same kind of > fuzzy > > writing is in the second paragraph of the same section: "In this > case, > the > > local ER server requesting the DSRK MUST include a KDE-Request > message > in > > the first EAP-Response message from the peer". This _should_ say " > In > > this case, the local ER server requesting the DSRK MUST include a > > KDE-Request message in the AAA packet encapsulating the first > EAP-Response > > message from the peer" in order to agree with RFC 5296 (in fact, > though, > > there's no need for the local ERP server to be involved in this at > all, > > except that that is (erroneously, I think) specified in 5296). > > > > ... > > > [KH] Glen, I think you are talking about Section 5 not 3, are you > looking at the current version > (http://ietfreport.isoc.org/all-ids/draft-ietf-hokey-key-mgm-09.txt)? > > Could you please re-check? I am sure your comments still apply, but I'd > like to know which parts are affected. Yes, you're right. I really hate it when people change documents in the middle of reviews. It's really annoying, especially since I just did it myself a couple of days ago ;-). > > AFAIK, Section 5 is in complete alignment with RFC 5296 and uses the > same terminology and same protocol description. I understand that there > are some problems in RFC 5296 and there is a request for errata > (http://www.rfc-editor.org/errata_search.php?rfc=5296&eid=1825). > > Should I wait until this (and possibly other) errata has been approved > and then modify the key management draft accordingly? If I make changes > now, with the current RFC 5296, we would have a description on how to > use KDE with ERP that does not match the description in RFC 5296. The problem is that RFC 5296 says to do things that just aren't possible, so we have a situation where we can either continue to create incorrect specifications or correctly specify behavior that contradicts a published RFC. Personally, I'd go for the latter: change the draft to specify what the authors of 5296 obviously _meant_ to say & update 5296 later. From khoeper@motorola.com Tue Aug 11 15:28:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D65428C0D7; Tue, 11 Aug 2009 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQlfut2+xEYn; Tue, 11 Aug 2009 15:28:15 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 1CED03A68DA; Tue, 11 Aug 2009 15:28:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1250029656!16981706!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16205 invoked from network); 11 Aug 2009 22:27:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2009 22:27:37 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n7BMRab2009183; Tue, 11 Aug 2009 15:27:36 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n7BMRaQM016535; Tue, 11 Aug 2009 17:27:36 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n7BMRZhx016528; Tue, 11 Aug 2009 17:27:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2009 18:27:14 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06555C24@de01exm68.ds.mot.com> In-Reply-To: <004f01ca1a22$56af4de0$040de9a0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [secdir] SECDIR review of draft-ietf-hokey-key-mgm thread-index: AcoZ6RjwgdOHSJLUTSaXyXUToQZhhgAKfEsgAC8KAkA= References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> From: "Hoeper Katrin-QWKN37" To: "Glen Zorn" , "Kurt Zeilenga" X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 11 Aug 2009 23:22:46 -0700 Cc: gwz@net-zen.net, draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 22:28:16 -0000 Please find my reply to Glen's comments in-line. Katrin > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] > Sent: Monday, August 10, 2009 8:24 PM > To: 'Kurt Zeilenga' > Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-hokey-key- > mgm@tools.ietf.org; gwz@net-zen.net > Subject: RE: [secdir] SECDIR review of draft-ietf-hokey-key-mgm >=20 > Thanks for pointing that out. In fact, the document should _not_ talk > about > the use of KDE in ERP, since it doesn't exist ;-). Re-re-re-reading ;-) > section 6 (which is what I think you are talking about?), I noticed > A couple of other errors, too. For example, section 3 says "Here, > EAP-Initiate and EAP-Finish messages are exchanged between the peer and > the > home AAA server, with the bootstrapping flag in the EAP-Initiate message > set"; unfortunately, this is impossible, since the peer and AAA server do > not speak the same protocol. Another example of the same kind of fuzzy > writing is in the second paragraph of the same section: "In this case, the > local ER server requesting the DSRK MUST include a KDE-Request message in > the first EAP-Response message from the peer". This _should_ say " In > this case, the local ER server requesting the DSRK MUST include a > KDE-Request message in the AAA packet encapsulating the first EAP-Response > message from the peer" in order to agree with RFC 5296 (in fact, though, > there's no need for the local ERP server to be involved in this at all, > except that that is (erroneously, I think) specified in 5296). >=20 > ... >=20 [KH] Glen, I think you are talking about Section 5 not 3, are you looking at the current version (http://ietfreport.isoc.org/all-ids/draft-ietf-hokey-key-mgm-09.txt)? =20 Could you please re-check? I am sure your comments still apply, but I'd like to know which parts are affected. AFAIK, Section 5 is in complete alignment with RFC 5296 and uses the same terminology and same protocol description. I understand that there are some problems in RFC 5296 and there is a request for errata (http://www.rfc-editor.org/errata_search.php?rfc=3D5296&eid=3D1825). Should I wait until this (and possibly other) errata has been approved and then modify the key management draft accordingly? If I make changes now, with the current RFC 5296, we would have a description on how to use KDE with ERP that does not match the description in RFC 5296. =20 From mnot@mnot.net Wed Aug 12 02:44:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B541A3A635F for ; Wed, 12 Aug 2009 02:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=-2.852, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLsuc40FwMj1 for ; Wed, 12 Aug 2009 02:44:24 -0700 (PDT) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by core3.amsl.com (Postfix) with ESMTP id 9955C3A68BE for ; Wed, 12 Aug 2009 02:44:07 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id DD72A2FD7A9 for ; Wed, 12 Aug 2009 05:40:48 -0400 (EDT) Received: from [192.168.1.6] (unknown [118.208.160.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 70A2522E1F1; Wed, 12 Aug 2009 05:40:15 -0400 (EDT) Message-Id: <6E228B34-B441-404E-8DDD-8CE46CEAED5E@mnot.net> From: Mark Nottingham To: Sean Turner In-Reply-To: <4A7161C0.4040007@ieca.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 19:40:11 +1000 References: <4A7161C0.4040007@ieca.com> X-Mailer: Apple Mail (2.936) Cc: draft-nottingham-http-link-header@tools.ietf.org, "Julian F. F. Reschke" , Lisa Dusseault , secdir Subject: Re: [secdir] secdir review of draft-nottingham-http-link-header X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 09:44:24 -0000 Thanks, Sean. I'm not sure how to incorporate your suggestion into the document; did you have specific mechanisms in mind, and/or specific placement in the draft? Cheers, On 30/07/2009, at 7:02 PM, Sean Turner wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > Document: draft-nottingham-http-link-header-06.txt > Reviewer: Sean Turner > Review Date: 2009-07-30 > IETF LC End Date: 2009-08-11 > IESG Telechat date: N/A > > Summary: This document specifies relation types for Web links, and > defines a registry for them. It also defines how to send such links > in HTTP headers with the Link header-field. > > Comments: The security considerations are pretty clear: the content > of the fields aren't secured in any way. I think some text should be > added that says something like "[Mechanism XYZ] can be combined with > [protocol ABC] to provide the following security service: 1, 2, 3." > > spt -- Mark Nottingham http://www.mnot.net/ From khoeper@motorola.com Wed Aug 12 07:51:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714123A6A59; Wed, 12 Aug 2009 07:51: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9viCqFLXKpj; Wed, 12 Aug 2009 07:51:35 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 478523A67D9; Wed, 12 Aug 2009 07:51:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1250088453!1202750!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 18164 invoked from network); 12 Aug 2009 14:47:34 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-15.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Aug 2009 14:47:34 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n7CElX4a026403; Wed, 12 Aug 2009 07:47:33 -0700 (MST) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n7CElS1Y019924; Wed, 12 Aug 2009 09:47:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 10:47:06 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06555DF9@de01exm68.ds.mot.com> In-Reply-To: <010e01ca1afe$d9c82b70$8d588250$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [secdir] SECDIR review of draft-ietf-hokey-key-mgm thread-index: AcoZ6RjwgdOHSJLUTSaXyXUToQZhhgAKfEsgAC8KAkAAC4hLEAAXTyvg References: <369289D9-6E39-4673-B50E-0090BBBB6EB2@Isode.com> <00bf01ca19e0$1b703e70$5250bb50$@net> <004f01ca1a22$56af4de0$040de9a0$@net> <3A241A6B234BE948B8B474D261FEBC2F06555C24@de01exm68.ds.mot.com> <010e01ca1afe$d9c82b70$8d588250$@net> From: "Hoeper Katrin-QWKN37" To: "Glen Zorn" , "Glen Zorn" , "Kurt Zeilenga" Cc: draft-ietf-hokey-key-mgm@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-hokey-key-mgm X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:51:36 -0000 To sum up the previous discussion, here my proposed 3 changes to draft-ietf-hokey-key-mgm-09.txt to address Kurt's and Glen's comments. Please let me know if the changes are sufficient. 1. OLD (Section 5, second paragraph) In this case, the local ER server requesting the DSRK MUST include a KDE-Request message in the first EAP-Response message from the peer. NEW=20 In this case, the local ER server requesting the DSRK MUST include a KDE-Request message in the AAA packet encapsulating the first EAP-Response message from the peer. =20 2. OLD (Section 5, third paragraph) Here, EAP-Initiate and EAP-Finish messages are exchanged between the peer and the home AAA server, with the bootstrapping flag in the EAP-Initiate message set. In this case, the local ER server (acting as KRS) MUST include a KDE-Request message in the AAA message that carries an EAP-Initiate message with the bootstrapping flag turned on. =20 NEW=20 Here, the peer sends an EAP-Initiate message with the bootstrapping flag turned on. The local ER server (acting as KRS) MUST include a KDE-Request message in the AAA message that carries the peer's EAP-Initiate message and sends it to the peer's home AAA server. 3. OLD (Section 6, first paragraph)=20 This section provides security requirements and an analysis on transporting EAP keying material using an AAA protocol. NEW This section provides security requirements and a discussion of distributing RK without peer consent. Best regards, Katrin > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net] > Sent: Tuesday, August 11, 2009 10:42 PM > To: Hoeper Katrin-QWKN37; 'Glen Zorn'; 'Kurt Zeilenga' > Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-hokey-key- > mgm@tools.ietf.org > Subject: RE: [secdir] SECDIR review of draft-ietf-hokey-key-mgm >=20 > Hoeper Katrin-QWKN37 [mailto:khoeper@motorola.com] writes: >=20 > ... >=20 > > > Thanks for pointing that out. In fact, the document should _not_ > > talk > > > about > > > the use of KDE in ERP, since it doesn't exist ;-). Re-re-re-reading > > ;-) > > > section 6 (which is what I think you are talking about?), I noticed > > > A couple of other errors, too. For example, section 3 says "Here, > > > EAP-Initiate and EAP-Finish messages are exchanged between the peer > > and > > > the > > > home AAA server, with the bootstrapping flag in the EAP-Initiate > > message > > > set"; unfortunately, this is impossible, since the peer and AAA > > server > > do > > > not speak the same protocol. Another example of the same kind of > > fuzzy > > > writing is in the second paragraph of the same section: "In this > > case, > > the > > > local ER server requesting the DSRK MUST include a KDE-Request > > message > > in > > > the first EAP-Response message from the peer". This _should_ say " > > In > > > this case, the local ER server requesting the DSRK MUST include a > > > KDE-Request message in the AAA packet encapsulating the first > > EAP-Response > > > message from the peer" in order to agree with RFC 5296 (in fact, > > though, > > > there's no need for the local ERP server to be involved in this at > > all, > > > except that that is (erroneously, I think) specified in 5296). > > > > > > ... > > > > > [KH] Glen, I think you are talking about Section 5 not 3, are you > > looking at the current version > > (http://ietfreport.isoc.org/all-ids/draft-ietf-hokey-key-mgm-09.txt)? > > > > Could you please re-check? I am sure your comments still apply, but I'd > > like to know which parts are affected. >=20 > Yes, you're right. I really hate it when people change documents in the > middle of reviews. It's really annoying, especially since I just did it > myself a couple of days ago ;-). >=20 > > > > AFAIK, Section 5 is in complete alignment with RFC 5296 and uses the > > same terminology and same protocol description. I understand that there > > are some problems in RFC 5296 and there is a request for errata > > (http://www.rfc-editor.org/errata_search.php?rfc=3D5296&eid=3D1825). > > > > Should I wait until this (and possibly other) errata has been approved > > and then modify the key management draft accordingly? If I make changes > > now, with the current RFC 5296, we would have a description on how to > > use KDE with ERP that does not match the description in RFC 5296. >=20 > The problem is that RFC 5296 says to do things that just aren't possible, > so > we have a situation where we can either continue to create incorrect > specifications or correctly specify behavior that contradicts a published > RFC. Personally, I'd go for the latter: change the draft to specify what > the authors of 5296 obviously _meant_ to say & update 5296 later. From turners@ieca.com Wed Aug 12 11:25:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D03B3A69C7 for ; Wed, 12 Aug 2009 11:25: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM1FXNAY-cMQ for ; Wed, 12 Aug 2009 11:25:02 -0700 (PDT) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id B686C3A67DB for ; Wed, 12 Aug 2009 11:25:01 -0700 (PDT) Received: (qmail 66705 invoked from network); 12 Aug 2009 18:17:00 -0000 Received: from unknown (HELO thunderfish.local) (turners@71.191.12.61 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 12 Aug 2009 18:16:59 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: TaS.2g8VM1lm9DFFweMt8ZOoe5StoBPzMpfdMalYmNjytwuyQCSepYp6SxRMeCYEUn0rG4yp7jhYLOCCZVavhu4MzIEt601zp_swQqhyXs0a.KZ5Rb670LHxeWwcv5d6gJFGNXNCw7p9UvTQIabKKqfDJL99s5zZPDh5Bg8cyDHlbRUDBJHvfcZXwGHg_QxCe7ZpXRbbh5HvOtPpVkwwZhTXeSMFvxgf614y_01YKAyaMD_Wt0ar33lQ7_ijO8iQkd5Wsh3MhoSazYmnQauktdkE6q7zTrM_6BDdNAEJIy3bbmz42u8guQdyKvZdyw16gjy7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A83071B.2060705@ieca.com> Date: Wed, 12 Aug 2009 14:16:59 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dave Cridland References: <8048.1249937599.500468@puncture> In-Reply-To: <8048.1249937599.500468@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-turner-clearancesponsor-attribute@tools.ietf.org, The IESG , Security Area Directorate Subject: Re: [secdir] Security Directorate Review of draft-turner-clearancesponsor-attribute X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:25:02 -0000 Dave, Thanks for your review. Responses inline. spt Dave Cridland wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > (I would note for the record that I roped in Kurt Zeilenga to check > certain issues, but I nevertheless take full credit for any errors). > > This is a straighforward definition of an attribute suitable for X.509 > certificates (either public key or attribute) or X.500/LDAP directory > entries which carries the name of the clearance sponsor, that is, the > entity which initiated and maintains the assignment of the clearance. > > I note that recent cases where a DirectoryName has been used with X.509 > for authentication - in particular usage of the CommonName of the > Subject Name - have been subjected to attacks using embedded NULs. > Whilst presumably using the correct equality matching rule prevents > this, it'd be nice to see that called out. (If the equality matching > rule does not prevent this case, that's obviously more serious). > > Mandating that NUL is not a valid codepoint in this attribute would > probably be useful, too. Good point! I'll add that the DirectoryString MUST NOT be NULL. > General notes: > > It's not entirely clear to me why one would want to consider this as > part of an authorization check, unless one was attempting to match the > name of the sponsor against a list of "known good" sponsors - that is, > if a sponsor was subsequently revoked as a whole as being a suitable > sponsor, one might want the sponsored clearances to be pulled as well. > (It might be useful to note *why* one might want to do this, within the > draft). I'll move the last sentence in the 1st para in the intro to a new paragraph and add some examples: This attribute may be used in authorization decisions. For example, a web server deciding whether to allow a user access could check that the clearance sponsor present in the user's certificate is on an "approved" list. The web server could also check that the included clearance sponsor is on an "approved" list to issue the included clearance. > However, it occurs to me that this kind of matching might be better done > against an OID, such as one from the Enterprise arc, rather than a > simple string, which might prove to be subject to human foibles. Fat fingering is a concern but some people really like "human readable." I'm certainly hoping that for people that use this there's a check to make sure that what they put in the string is only from an allowable list. > Dave. From kurt.zeilenga@isode.com Wed Aug 12 12:03:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A103A6984; Wed, 12 Aug 2009 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69ywOIKBZavi; Wed, 12 Aug 2009 12:03:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 653FB3A6838; Wed, 12 Aug 2009 12:03:21 -0700 (PDT) Received: from [172.16.2.185] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 12 Aug 2009 20:01:45 +0100 Message-Id: <884C7D12-0619-403B-B6CE-E62AB1B6A2AA@isode.com> From: Kurt Zeilenga To: Sean Turner In-Reply-To: <4A83071B.2060705@ieca.com> Date: Wed, 12 Aug 2009 12:01:41 -0700 References: <8048.1249937599.500468@puncture> <4A83071B.2060705@ieca.com> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: Security Area Directorate , draft-turner-clearancesponsor-attribute@tools.ietf.org, The IESG Subject: Re: [secdir] Security Directorate Review of draft-turner-clearancesponsor-attribute X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 19:03:22 -0000 On Aug 12, 2009, at 11:16 AM, Sean Turner wrote: > Dave, > > Thanks for your review. Responses inline. > > spt > > Dave Cridland wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should >> treat these comments just like any other last call comments. >> (I would note for the record that I roped in Kurt Zeilenga to check >> certain issues, but I nevertheless take full credit for any errors). >> This is a straighforward definition of an attribute suitable for X. >> 509 certificates (either public key or attribute) or X.500/LDAP >> directory entries which carries the name of the clearance sponsor, >> that is, the entity which initiated and maintains the assignment of >> the clearance. >> I note that recent cases where a DirectoryName has been used with X. >> 509 for authentication - in particular usage of the CommonName of >> the Subject Name - have been subjected to attacks using embedded >> NULs. Whilst presumably using the correct equality matching rule >> prevents this, it'd be nice to see that called out. (If the >> equality matching rule does not prevent this case, that's obviously >> more serious). >> Mandating that NUL is not a valid codepoint in this attribute would >> probably be useful, too. > > Good point! I'll add that the DirectoryString MUST NOT be NULL. DirectoryString is not defined by your I-D but by reference, as is the caseIgnoreMatch rule. The security consideration is applicable to all protocols using DirectoryString and caseIgnoreMatch. I think what you ought to say, in the Security Considerations section of this I-D, is something like: While values of DirectoryString can include the NUL (U+0000) code point, values used to represent clearance sponsors typically would not. Implementations of the caseIgnoreMatch rule must, per X.501, consider all of the assertion value and attribute value in matching and hence protect against truncation attacks. -- Kurt From secdir-bounces@mit.edu Wed Aug 12 13:22:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C343A6CCC for ; Wed, 12 Aug 2009 13:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=1.257, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2Ik-hOauO7o for ; Wed, 12 Aug 2009 13:22:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id D6B093A6B5E for ; Wed, 12 Aug 2009 13:22:20 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7CKLXmA028773 for ; Wed, 12 Aug 2009 16:21:33 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7CKLVq6028755 for ; Wed, 12 Aug 2009 16:21:31 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7CKLQee010034 for ; Wed, 12 Aug 2009 16:21:27 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 541EB1A9304D for ; Wed, 12 Aug 2009 16:21:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu with ESMTP id YQRK2jEA6FzIOud4 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 12 Aug 2009 16:21:26 -0400 (EDT) X-Barracuda-Envelope-From: hartmans@mit.edu Received-SPF: softfail (mit.edu: domain of transitioning hartmans@mit.edu does not designate 69.25.196.178 as permitted sender) receiver=mit.edu; client_ip=69.25.196.178; envelope-from=hartmans@mit.edu; Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 41EBB51C6; Wed, 12 Aug 2009 16:21:22 -0400 (EDT) To: secdir@MIT.EDU From: Sam Hartman Date: Wed, 12 Aug 2009 16:21:22 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: secdir-bounces@MIT.EDU Errors-To: secdir-bounces@MIT.EDU Subject: [secdir] Security participation in the LISP WG appreciated X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:22:21 -0000 --=-=-= I'm chairing LISP. I opened an issue (http://trac.tools.ietf.org/wg/lisp/trac/ticket/2 ) that one of our existing security mechanisms doesn't meet IETF security requirements. I suggested TLS over TCP as a good fit for what I think we're trying to do, but enumerated a number of other solutions that will also meet reasonable security requirements. The editors of the spec continue to believe that statically configured RFC 2402 AH with md5 is a good solution for a mechanism that needs to scale to thousands of peers. Here is the reply below. I think having some additional participation in the discussion would be useful. Participants need to be able to work without a written threat model or well defined security analysis. Yes, some of that will come by the time we're all done--some of our work is even blocking on it. However it's not there now, and it would be disasterous to wait until all that work is done before starting to look at mechanisms. Forming consensus to change the documents in this group proves fairly challenging. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 12 Aug 2009 12:58:07 -0400 X-Sieve: CMU Sieve 2.2 Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suchdamage.org (Postfix) with ESMTP id E726820221 for ; Wed, 12 Aug 2009 12:58:04 -0400 (EDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7CGw3vU002188 for ; Wed, 12 Aug 2009 12:58:03 -0400 (EDT) Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7CGvvWe016022 for ; Wed, 12 Aug 2009 12:57:58 -0400 (EDT) Received: from sj-iport-1.cisco.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6001523B744D for ; Wed, 12 Aug 2009 12:57:57 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mit.edu with ESMTP id eIsENipgIbYJ7Wr4 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 12 Aug 2009 12:57:57 -0400 (EDT) Received-SPF: pass (mit.edu: domain of dino@cisco.com designates 171.71.176.70 as permitted sender) receiver=mit.edu; client_ip=171.71.176.70; envelope-from=dino@cisco.com; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP+QgkqrR7MV/2dsb2JhbAC6RYgrkRAFhBmBUYhG X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="227048390" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 16:57:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGvuoh016141; Wed, 12 Aug 2009 09:57:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGvung003839; Wed, 12 Aug 2009 16:57:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:56 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:55 -0700 Cc: lisp@ietf.org Message-Id: <55688DEC-6581-471A-9B00-68D6D429B9C5@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism Date: Wed, 12 Aug 2009 09:57:55 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:57:55.0707 (UTC) FILETIME=[09BACCB0:01CA1B6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1000; t=1250096276; x=1250960276; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20=20management=20and=20securit y=20mechanism |Sender:=20; bh=WcoAY2xaqUAnEmUmXQO6V0MpFCMxpHMyviltffG1eDI=; b=vG4Go5TrxHo2zsxAQ3Inhq8jpE5+0L83DxPCMU8xdenyYlEwf6A8VOUfSv 0S+eau1PtOJtRbWZW5AuLdhc6gwIOgXFG3KYDZlEfAQExGVwh3Fi5+86wOQi Rmq62IuwqVSYcQwEkLbzlCNL7zWcFVaKGoy+yMorkgvF+3MDAOiAA=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Aug 12 12:58:07 2009 X-DSPAM-Confidence: 0.8422 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4a82f49f108274342417856 X-DSPAM-Factors: 27, From*Dino Farinacci , 0.00010, To*Sam+Hartman, 0.00015, To*Sam, 0.00016, To*Hartman+, 0.00543, References*mit.edu>, 0.00543, Received*Aug+2009, 0.99415, Received*Aug+2009, 0.99415, Date*Aug+2009, 0.99409 MIME-Version: 1.0 > * IPsec (IKEV2 + esp null) > > May interact poorly with other uses of IPsec on the same device. > Fairly difficult to standardize; there are a lot of tricky bits to > specify. May end up involving more state than TLS between the PAD > entry, the SPD entry, and the SAD entry. > > I can't think of any success stories with this approach. OSPF V3 does > this, but I think both the security community and the routing > community were vaguely unhappy with the results. Well I am happy with the results we have on our test LISP network. It is: (1) Easy to configure (2) Stateless (3) No overhead (i.e. no TCP connections to keep up) (4) Easy to rekey at any point. (5) No chit-chat before getting the data you need to get from the ETR to the map-server. That is, using HMACs transmitted in AH headers. It is simple and it works. We have running code that proves it. There is no reason to change it. We need to focus on other more important issues with LISP. Dino --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir --=-=-=-- From hartmans@mit.edu Wed Aug 12 13:22:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDC828C0EA for ; Wed, 12 Aug 2009 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id navDG3pWG1eL for ; Wed, 12 Aug 2009 13:22:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 6904D28C0E1 for ; Wed, 12 Aug 2009 13:22:29 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2C8E51C6; Wed, 12 Aug 2009 16:21:55 -0400 (EDT) To: secdir@ietf.org From: Sam Hartman User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Date: Wed, 12 Aug 2009 16:21:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [secdir] Security participation in the LISP WG appreciated X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:22:30 -0000 --=-=-= I'm chairing LISP. I opened an issue (http://trac.tools.ietf.org/wg/lisp/trac/ticket/2 ) that one of our existing security mechanisms doesn't meet IETF security requirements. I suggested TLS over TCP as a good fit for what I think we're trying to do, but enumerated a number of other solutions that will also meet reasonable security requirements. The editors of the spec continue to believe that statically configured RFC 2402 AH with md5 is a good solution for a mechanism that needs to scale to thousands of peers. Here is the reply below. I think having some additional participation in the discussion would be useful. Participants need to be able to work without a written threat model or well defined security analysis. Yes, some of that will come by the time we're all done--some of our work is even blocking on it. However it's not there now, and it would be disasterous to wait until all that work is done before starting to look at mechanisms. Forming consensus to change the documents in this group proves fairly challenging. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 12 Aug 2009 12:58:07 -0400 X-Sieve: CMU Sieve 2.2 Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suchdamage.org (Postfix) with ESMTP id E726820221 for ; Wed, 12 Aug 2009 12:58:04 -0400 (EDT) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7CGw3vU002188 for ; Wed, 12 Aug 2009 12:58:03 -0400 (EDT) Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7CGvvWe016022 for ; Wed, 12 Aug 2009 12:57:58 -0400 (EDT) Received: from sj-iport-1.cisco.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 6001523B744D for ; Wed, 12 Aug 2009 12:57:57 -0400 (EDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mit.edu with ESMTP id eIsENipgIbYJ7Wr4 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 12 Aug 2009 12:57:57 -0400 (EDT) Received-SPF: pass (mit.edu: domain of dino@cisco.com designates 171.71.176.70 as permitted sender) receiver=mit.edu; client_ip=171.71.176.70; envelope-from=dino@cisco.com; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP+QgkqrR7MV/2dsb2JhbAC6RYgrkRAFhBmBUYhG X-IronPort-AV: E=Sophos;i="4.43,368,1246838400"; d="scan'208";a="227048390" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2009 16:57:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7CGvuoh016141; Wed, 12 Aug 2009 09:57:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7CGvung003839; Wed, 12 Aug 2009 16:57:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:56 -0700 Received: from [192.168.1.3] ([10.21.148.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 09:57:55 -0700 Cc: lisp@ietf.org Message-Id: <55688DEC-6581-471A-9B00-68D6D429B9C5@cisco.com> From: Dino Farinacci To: Sam Hartman In-Reply-To: Subject: Re: [lisp] [#2] LISP MS specification needs mandatory key management and security mechanism Date: Wed, 12 Aug 2009 09:57:55 -0700 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 12 Aug 2009 16:57:55.0707 (UTC) FILETIME=[09BACCB0:01CA1B6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1000; t=1250096276; x=1250960276; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20[#2]=20LISP=20MS=20specificati on=20needs=20mandatory=20key=20=20management=20and=20securit y=20mechanism |Sender:=20; bh=WcoAY2xaqUAnEmUmXQO6V0MpFCMxpHMyviltffG1eDI=; b=vG4Go5TrxHo2zsxAQ3Inhq8jpE5+0L83DxPCMU8xdenyYlEwf6A8VOUfSv 0S+eau1PtOJtRbWZW5AuLdhc6gwIOgXFG3KYDZlEfAQExGVwh3Fi5+86wOQi Rmq62IuwqVSYcQwEkLbzlCNL7zWcFVaKGoy+yMorkgvF+3MDAOiAA=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Aug 12 12:58:07 2009 X-DSPAM-Confidence: 0.8422 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4a82f49f108274342417856 X-DSPAM-Factors: 27, From*Dino Farinacci , 0.00010, To*Sam+Hartman, 0.00015, To*Sam, 0.00016, To*Hartman+, 0.00543, References*mit.edu>, 0.00543, Received*Aug+2009, 0.99415, Received*Aug+2009, 0.99415, Date*Aug+2009, 0.99409 MIME-Version: 1.0 > * IPsec (IKEV2 + esp null) > > May interact poorly with other uses of IPsec on the same device. > Fairly difficult to standardize; there are a lot of tricky bits to > specify. May end up involving more state than TLS between the PAD > entry, the SPD entry, and the SAD entry. > > I can't think of any success stories with this approach. OSPF V3 does > this, but I think both the security community and the routing > community were vaguely unhappy with the results. Well I am happy with the results we have on our test LISP network. It is: (1) Easy to configure (2) Stateless (3) No overhead (i.e. no TCP connections to keep up) (4) Easy to rekey at any point. (5) No chit-chat before getting the data you need to get from the ETR to the map-server. That is, using HMACs transmitted in AH headers. It is simple and it works. We have running code that proves it. There is no reason to change it. We need to focus on other more important issues with LISP. Dino --=-=-=-- From tlyu@MIT.EDU Wed Aug 12 17:41:04 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02303A6AD7; Wed, 12 Aug 2009 17:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPT6Y9k7e1ZL; Wed, 12 Aug 2009 17:41:03 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id C47583A67F3; Wed, 12 Aug 2009 17:41:02 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7D0eIbB013157; Wed, 12 Aug 2009 20:40:18 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n7D0eFYj023226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Aug 2009 20:40:16 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n7D0eFTe007577; Wed, 12 Aug 2009 20:40:15 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, dime-chairs@tools.ietf.org, jouni@gmail.com, julien.bournelle@orange-ftgroup.com, kchowdhury@starentnetworks.com, amuhanna@nortel.com, meyer@umic.rwth-aachen.de From: Tom Yu Date: Wed, 12 Aug 2009 20:40:15 -0400 Message-ID: Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-ietf-dime-pmip6-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:41:05 -0000 The Security Considerations section states: The security considerations of the Diameter Base protocol [RFC3588], Diameter EAP application [RFC4072], Diameter NASREQ application [RFC4005] and Diameter Mobile IPv6 integrated scenario bootstrapping [RFC5447] are applicable to this document. Should a reference to RFC 4832 (Security Threats to NETLMM) be included here? There appear to be no obvious additional security considerations beyond those mentioned in the above documents. (if including the suggested additional citation) In general, the Diameter messages may be transported between the HA and the Diameter server via one or more AAA brokers or Diameter agents. In this case the HA to the Diameter server AAA communication rely on the security properties of the intermediate AAA brokers and Diameter agents (such as proxies). "HA" as used above is not defined in the document, and is used nowhere else in the document. Is it a Home Agent? (which is not really otherwise mentioned in this document) Editorial: "DER" and "DEA" are not defined. I am fairly sure that "DER" does not mean "Distinguished Encoding Rules" in this document. The caption for Figure 4 crosses a page break, making it appear truncated. The term "Local Mobility Anchor" is confusing to me, because it seems to imply an entity that is local to the Mobile Node, but the term appears well-established in earlier documents. draft-ietf-netlmm-pmip6-ipv4-support is now on revision #14, but is cited as "-11". From secdir-bounces@mit.edu Wed Aug 12 17:43:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9147E3A67F3 for ; Wed, 12 Aug 2009 17:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFsKj7hG948c for ; Wed, 12 Aug 2009 17:43:01 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 870DF3A6D14 for ; Wed, 12 Aug 2009 17:43:01 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7D0gboC011524 for ; Wed, 12 Aug 2009 20:42:37 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7D0gZ84011521 for ; Wed, 12 Aug 2009 20:42:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7D0gPYQ011379 for ; Wed, 12 Aug 2009 20:42:25 -0400 (EDT) Received: from mx11.bbn.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 3DF0D1B28C4A for ; Wed, 12 Aug 2009 20:42:25 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu with ESMTP id VucUYpPqo3mDlKdj for ; Wed, 12 Aug 2009 20:42:24 -0400 (EDT) Received-SPF: pass (mit.edu: domain of rbarnes@bbn.com designates 128.33.0.80 as permitted sender) receiver=mit.edu; client_ip=128.33.0.80; envelope-from=rbarnes@bbn.com; Received: from [128.89.254.244] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MbNSV-00071H-Ea; Wed, 12 Aug 2009 19:42:19 -0400 Message-ID: <4A83616C.1030506@bbn.com> Date: Wed, 12 Aug 2009 20:42:20 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: IESG , SECDIR , IETF Discussion , draft-ietf-pkix-other-certs@tools.ietf.org X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] SECDIR review of draft-ietf-pkix-other-certs-04 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:43:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This documents creates a certificate extension that allows the issuer of a certificate to assert that the subject of the certificate is the same as that of a set of other certificates (i.e., that the same entity holds all the corresponding private keys). This extension clearly creates some impersonation risks, but the document provides sufficient advice to CAs to mitigate these risks. Overall, I think the document is basically ready for publication. Some comments, mostly editorial, follow below. --Richard ----- Section 1, Paragraph 2 s/assoicate/associate/ Section 1, Paragraph 3 To be clear here and decouple this paragraph from the last, I would replace the phrase "... supports such linkage" to something like "... allows a certificate issuer to attest that the end entity that holds the private key for the certificate in question also holds other private keys corresponding to other certificates." This change also clarifies why you refer to "end entities" below instead of just "subjects". Section 2, Paragraph 3 Change "... change CA when renewing its certificate" to "... change CA when replacing its certificate". Renewal only happens with the same CA. Section 3, ASN.1 fragment Change "::==" to "::=". Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para) The first sentence in this paragraph seems very vague -- what does it mean for a use of this extension to be "safe"? Suggest replacing with a requirement that is notably absent from this paragraph, namely that "CAs MUST issue a certificate containing this extension only after they have validated that the holder of the private key for the certificate also holds the private keys for linked certificates." Section 3, Paragraph 6 (same as above) Do you mean to have both requirements in the final sentence as "SHOULD NOT"? It might be helpful here to note how the "purpose" a certificate might be determined, e.g., via CP or EKU OIDs. Setion 3, Paragraph 10 The validation procedure in RFC 5280 requires an RP to verify that a certificate has not been revoked (Section 6.1.3, step (a)(3)), so the initial conditional can be omitted. This requirement is really important for this extension, since one reason that certificates get revoked is private key compromise, in which case a party other than the intended subject has possession of the private key (by definition). This situation would allow the attacker to obtain linked certificates even from a CA that complies with this document. Section 3, Paragraph 12 It would be helpful to clarify why this restriction is in place, e.g., "Since CA certificates are only used for certificate validation, and this extension has no effect on the validation procedure, this extension is meaningless for CA certificates." Section 5 It's not clear that this section belongs in this document. It would not reduce the clarity of the document to remove it. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From shanna@juniper.net Thu Aug 13 03:58:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBCC3A67FF; Thu, 13 Aug 2009 03:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHnrLigzoW5K; Thu, 13 Aug 2009 03:58:21 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id B15EC3A6811; Thu, 13 Aug 2009 03:58:16 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSoPxcGQxoSYHA4Pu8mb+vqDA5g93pmXF@postini.com; Thu, 13 Aug 2009 03:58:25 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 Aug 2009 03:54:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 13 Aug 2009 06:54:19 -0400 From: Stephen Hanna To: Tom.Petch , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-partial-lock@tools.ietf.org" Date: Thu, 13 Aug 2009 06:53:21 -0400 Thread-Topic: secdir review of draft-ietf-netconf-partial-lock-09.txt Thread-Index: Acob/8PGxyneIihVSXS1LcqzmbNBbAAAilfA Message-ID: References: <016701ca1bf7$400ac480$0601a8c0@allison> In-Reply-To: <016701ca1bf7$400ac480$0601a8c0@allison> 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: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:58:22 -0000 Tom, Thanks for responding to my comments. Allow me to respond. You wrote: > As a participant in netconf, I see authorization as one of those topics > which the Working Group sees as necessary but cannot be tackled just > yet. As RFC4741 says, > " This document does not specify an authorization scheme, as such a > scheme should be tied to a meta-data model or a data model." > and as yet, there is no data model; hence, no authorization, not yet, > nor, IMHO, for some time to come. This is just the sort of background information that a WG participant would know but that a secdir reviewer would not. Please allow me to ask a clarifying question. You say that there is no authorization yet. I think that could mean several things: 1) Existing NETCONF implementations implement authorization, ensuring that each user gets an appropriate and perhaps different level of access to the database. However, there are no standards for the manner in which authorization is performed or configured. 2) Existing NETCONF implementations require authentication but generally just give complete read-write access to the database to all authenticate= d users. 3) Existing NETCONF implementations do not require authentication. Anyone with network access has complete, unfettered access to the database and can modify it at will. Could you tell me which of these meanings is most accurate? Of course, it could be a mix of these but I'd like to get your real-world assessment of the state of the NETCONF world. If the answer is 3), we have a serious problem! If the answer is 1) or 2), that's acceptable in my view. Now on to the language in the draft. My comment was relating to this quote from the Security Considerations: > "Only an authenticated and authorized user can request a partial > lock." I'm afraid that this statement is not justified if there is no normative text requiring implementations to comply. I suggest that normative text be added to at least require authentication. With such text, the statement above could be justified. Requiring that levels of authorization be implemented is less important in this application. And standardizing the manner in which authorization is performed or configured (which I think is your concern with respect to the lack of a data model) is really not important at all unless NETCONF customers or vendors decide that it is. Standardizing an authorization policy format is a tremendously challenging task for any protocol and often not necessary. I hope that this helps you address my comments in a reasonable and achievable manner. The intent of secdir comments is not to impose unreasonable requirements. It is to point out issues that might not be evident to someone who is not a security expert. Thanks, Steve > -----Original Message----- > From: Tom.Petch [mailto:sisyphus@dial.pipex.com]=20 > Sent: Thursday, August 13, 2009 4:00 AM > To: Stephen Hanna; secdir@ietf.org; ietf@ietf.org;=20 > draft-ietf-netconf-partial-lock@tools.ietf.org > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt >=20 > ----- Original Message ----- > From: "Stephen Hanna" > To: ; ; ; > > Sent: Monday, August 10, 2009 4:28 PM >=20 > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs=20 > should treat > > these comments just like any other last call comments. > > > > This document defines optional partial-lock and partial-unlock > > operations to be added to the NETCONF protocol. These operations > > are used to lock only part of a configuration datastore, allowing > > multiple management sessions to modify the configuration of a > > device at a single time. > > > > The Security Considerations section of the document highlights > > the risk that a malicious party might employ partial locks to > > impede access to a device's configuration. Therefore, it states > > "Only an authenticated and authorized user can request a partial > > lock." Unfortunately, I cannot find any normative text (MUST) > > that supports this statement. The NETCONF spec (RFC 4741) says > > "NETCONF connections must be authenticated" but this is not > > clearly normative. Perhaps a NETCONF expert can point to some > > normative text requiring authentication and authorization for > > any party requesting a partial lock. If not, I suggest that > > such normative text be added to the partial-lock specification. > > > As a participant in netconf, I see authorization as one of=20 > those topics > which the Working Group sees as necessary but cannot be tackled just > yet. As RFC4741 says, > " This document does not specify an authorization scheme, as such a > scheme should be tied to a meta-data model or a data model." > and as yet, there is no data model; hence, no authorization, not yet, > nor, IMHO, for some time to come. In the light of this, I am not sure > what adding a normative statement to this I-D would do; delay > publication sine die? >=20 > Tom Petch >=20 >=20 >=20 >=20 > > Another security concern that I have related to the partial-lock > > operation is that the configuration might become inconsistent if > > one manager changes one part of a datastore at the same time that > > another manager changes another part. The resulting inconsistency > > could have security implications. For example, an organization might > > have a rule that either the firewall or the intrusion detection > > features must be enabled on a device. If one manager might lock > > intrusion detection configuration, check that the firewall is > > enabled, and then disable intrusion detection. Another manager > > might lock the firewall configuration, check that intrusion=20 > detection > > is enabled, and then disable the firewall. If those operations > > were interleaved, they could result in a violation of policy. > > To address this concern, I suggest that the draft contain a > > warning that parallel operations are tricky and should be > > carefully considered. Sometimes, it may be necessary to lock > > a portion of the datastore that will not be modified, just to > > ensure the datastore remains consistent and compliant with policy. > > > > Of course, a human administrator using a GUI could easily > > run into this same problem if the human does not have the > > ability to control configuration locks. The human might > > look at the firewall configuration to make sure that it's > > enabled and then switch to another section of the display > > to disable the intrusion detection function. If the management > > console only locks the datastore to execute the administrator's > > request to disable intrusion detection, overlapping operations > > from another administrator could result in a bad configuration. > > This problem can arise even without the partial lock operation. > > Probably the best that can be done here is to include language > > warning of this sort of problem. Warning human administrators > > that someone else is also editing the device should help and > > giving these administrators the ability to easily communicate > > with each other to coordinate their work would also probably help. > > > > Here are a few minor issues: > > > > * At the end of section 2.1.1.2, the comma in the last > > sentence is superfluous. > > > > * In section 2.1.1.3 in the sentence "Manager A terminates it's > > session", the apostrophe should be removed. > > > > * In section 2.4.1, I think that the sentence that begins with > > "If someone later creates a new interface" would be clearer > > if the second comma was changed to "so". > > > > * Later in section 2.4.1, the sentence that begins with > > "A NETCONF server MUST" should instead start with "A NETCONF > > server that supports partial locks MUST". I think that > > paragraph should end with "all of the overlapping locks are > > released" not "all of the locks are released". > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf >=20 > = From dromasca@avaya.com Thu Aug 13 04:14:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6423A69DF; Thu, 13 Aug 2009 04:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhfWqxGlVe7A; Thu, 13 Aug 2009 04:14:37 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 7EB3A3A68B7; Thu, 13 Aug 2009 04:14:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,373,1246852800"; d="scan'208";a="170068737" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 13 Aug 2009 07:11:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Aug 2009 07:11:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 13:10:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-netconf-partial-lock-09.txt Thread-Index: Acob/8PGxyneIihVSXS1LcqzmbNBbAAAilfAAAEi3ZA= References: <016701ca1bf7$400ac480$0601a8c0@allison> From: "Romascanu, Dan (Dan)" To: "Stephen Hanna" , "Tom.Petch" , , , Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:14:39 -0000 Steve, I believe that the situation is #1 below.=20 Dan =20 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; secdir@ietf.org; ietf@ietf.org;=20 > draft-ietf-netconf-partial-lock@tools.ietf.org > Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt >=20 > Tom, >=20 > Thanks for responding to my comments. Allow me to respond. >=20 > You wrote: > > As a participant in netconf, I see authorization as one of those=20 > > topics which the Working Group sees as necessary but cannot=20 > be tackled=20 > > just yet. As RFC4741 says, " This document does not specify an=20 > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no=20 > authorization, not yet,=20 > > nor, IMHO, for some time to come. >=20 > This is just the sort of background information that a WG=20 > participant would know but that a secdir reviewer would not.=20 > Please allow me to ask a clarifying question. You say that=20 > there is no authorization yet. > I think that could mean several things: >=20 > 1) Existing NETCONF implementations implement authorization, ensuring > that each user gets an appropriate and perhaps different level of > access to the database. However, there are no standards for the > manner in which authorization is performed or configured. >=20 > 2) Existing NETCONF implementations require authentication=20 > but generally > just give complete read-write access to the database to=20 > all authenticated > users. >=20 > 3) Existing NETCONF implementations do not require authentication. > Anyone with network access has complete, unfettered access to > the database and can modify it at will. >=20 > Could you tell me which of these meanings is most accurate? > Of course, it could be a mix of these but I'd like to get=20 > your real-world assessment of the state of the NETCONF world. > If the answer is 3), we have a serious problem! If the answer=20 > is 1) or 2), that's acceptable in my view. >=20 > Now on to the language in the draft. My comment was relating=20 > to this quote from the Security Considerations: >=20 > > "Only an authenticated and authorized user can request a partial=20 > > lock." >=20 > I'm afraid that this statement is not justified if there is=20 > no normative text requiring implementations to comply. I=20 > suggest that normative text be added to at least require=20 > authentication. > With such text, the statement above could be justified.=20 > Requiring that levels of authorization be implemented is less=20 > important in this application. And standardizing the manner=20 > in which authorization is performed or configured (which I=20 > think is your concern with respect to the lack of a data=20 > model) is really not important at all unless NETCONF=20 > customers or vendors decide that it is. Standardizing an=20 > authorization policy format is a tremendously challenging=20 > task for any protocol and often not necessary. >=20 > I hope that this helps you address my comments in a=20 > reasonable and achievable manner. The intent of secdir=20 > comments is not to impose unreasonable requirements. It is to=20 > point out issues that might not be evident to someone who is=20 > not a security expert. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: Tom.Petch [mailto:sisyphus@dial.pipex.com] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; secdir@ietf.org; ietf@ietf.org;=20 > > draft-ietf-netconf-partial-lock@tools.ietf.org > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > >=20 > > ----- Original Message ----- > > From: "Stephen Hanna" > > To: ; ; ;=20 > > > > Sent: Monday, August 10, 2009 4:28 PM > >=20 > > > I have reviewed this document as part of the security=20 > directorate's=20 > > > ongoing effort to review all IETF documents being=20 > processed by the=20 > > > IESG. These comments were written primarily for the=20 > benefit of the=20 > > > security area directors. Document editors and WG chairs > > should treat > > > these comments just like any other last call comments. > > > > > > This document defines optional partial-lock and partial-unlock=20 > > > operations to be added to the NETCONF protocol. These=20 > operations are=20 > > > used to lock only part of a configuration datastore, allowing=20 > > > multiple management sessions to modify the configuration=20 > of a device=20 > > > at a single time. > > > > > > The Security Considerations section of the document=20 > highlights the=20 > > > risk that a malicious party might employ partial locks to impede=20 > > > access to a device's configuration. Therefore, it states "Only an=20 > > > authenticated and authorized user can request a partial lock."=20 > > > Unfortunately, I cannot find any normative text (MUST)=20 > that supports=20 > > > this statement. The NETCONF spec (RFC 4741) says "NETCONF=20 > > > connections must be authenticated" but this is not clearly=20 > > > normative. Perhaps a NETCONF expert can point to some=20 > normative text=20 > > > requiring authentication and authorization for any party=20 > requesting=20 > > > a partial lock. If not, I suggest that such normative=20 > text be added=20 > > > to the partial-lock specification. > > > > > As a participant in netconf, I see authorization as one of those=20 > > topics which the Working Group sees as necessary but cannot=20 > be tackled=20 > > just yet. As RFC4741 says, " This document does not specify an=20 > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no=20 > authorization, not yet,=20 > > nor, IMHO, for some time to come. In the light of this, I=20 > am not sure=20 > > what adding a normative statement to this I-D would do; delay=20 > > publication sine die? > >=20 > > Tom Petch > >=20 > >=20 > >=20 > >=20 > > > Another security concern that I have related to the partial-lock=20 > > > operation is that the configuration might become=20 > inconsistent if one=20 > > > manager changes one part of a datastore at the same time that=20 > > > another manager changes another part. The resulting inconsistency=20 > > > could have security implications. For example, an=20 > organization might=20 > > > have a rule that either the firewall or the intrusion detection=20 > > > features must be enabled on a device. If one manager might lock=20 > > > intrusion detection configuration, check that the firewall is=20 > > > enabled, and then disable intrusion detection. Another=20 > manager might=20 > > > lock the firewall configuration, check that intrusion > > detection > > > is enabled, and then disable the firewall. If those=20 > operations were=20 > > > interleaved, they could result in a violation of policy. > > > To address this concern, I suggest that the draft contain=20 > a warning=20 > > > that parallel operations are tricky and should be carefully=20 > > > considered. Sometimes, it may be necessary to lock a=20 > portion of the=20 > > > datastore that will not be modified, just to ensure the datastore=20 > > > remains consistent and compliant with policy. > > > > > > Of course, a human administrator using a GUI could easily=20 > run into=20 > > > this same problem if the human does not have the ability=20 > to control=20 > > > configuration locks. The human might look at the firewall=20 > > > configuration to make sure that it's enabled and then switch to=20 > > > another section of the display to disable the intrusion detection=20 > > > function. If the management console only locks the datastore to=20 > > > execute the administrator's request to disable intrusion=20 > detection,=20 > > > overlapping operations from another administrator could=20 > result in a=20 > > > bad configuration. > > > This problem can arise even without the partial lock operation. > > > Probably the best that can be done here is to include language=20 > > > warning of this sort of problem. Warning human=20 > administrators that=20 > > > someone else is also editing the device should help and=20 > giving these=20 > > > administrators the ability to easily communicate with=20 > each other to=20 > > > coordinate their work would also probably help. > > > > > > Here are a few minor issues: > > > > > > * At the end of section 2.1.1.2, the comma in the last > > > sentence is superfluous. > > > > > > * In section 2.1.1.3 in the sentence "Manager A terminates it's > > > session", the apostrophe should be removed. > > > > > > * In section 2.4.1, I think that the sentence that begins with > > > "If someone later creates a new interface" would be clearer > > > if the second comma was changed to "so". > > > > > > * Later in section 2.4.1, the sentence that begins with > > > "A NETCONF server MUST" should instead start with "A NETCONF > > > server that supports partial locks MUST". I think that > > > paragraph should end with "all of the overlapping locks are > > > released" not "all of the locks are released". > > > _______________________________________________ > > > Ietf mailing list > > > Ietf@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf > >=20 > >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From sisyphus@dial.pipex.com Thu Aug 13 03:45:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7A63A6872; Thu, 13 Aug 2009 03:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffXKlc6rNDlP; Thu, 13 Aug 2009 03:45:50 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 903143A67AC; Thu, 13 Aug 2009 03:45:49 -0700 (PDT) X-Trace: 187201858/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.198/None/sisyphus@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.198 X-IP-MAIL-FROM: sisyphus@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADOGg0o+vGTG/2dsb2JhbACDMGGMbsMhCYQQBYIn X-IronPort-AV: E=Sophos;i="4.43,373,1246834800"; d="scan'208";a="187201858" X-IP-Direction: IN Received: from 1cust198.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.198]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Aug 2009 11:21:00 +0100 Message-ID: <016701ca1bf7$400ac480$0601a8c0@allison> From: "Tom.Petch" To: "Stephen Hanna" , , , References: Date: Thu, 13 Aug 2009 09:59:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Thu, 13 Aug 2009 04:15:32 -0700 Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Tom.Petch" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:45:51 -0000 ----- Original Message ----- From: "Stephen Hanna" To: ; ; ; Sent: Monday, August 10, 2009 4:28 PM > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines optional partial-lock and partial-unlock > operations to be added to the NETCONF protocol. These operations > are used to lock only part of a configuration datastore, allowing > multiple management sessions to modify the configuration of a > device at a single time. > > The Security Considerations section of the document highlights > the risk that a malicious party might employ partial locks to > impede access to a device's configuration. Therefore, it states > "Only an authenticated and authorized user can request a partial > lock." Unfortunately, I cannot find any normative text (MUST) > that supports this statement. The NETCONF spec (RFC 4741) says > "NETCONF connections must be authenticated" but this is not > clearly normative. Perhaps a NETCONF expert can point to some > normative text requiring authentication and authorization for > any party requesting a partial lock. If not, I suggest that > such normative text be added to the partial-lock specification. > As a participant in netconf, I see authorization as one of those topics which the Working Group sees as necessary but cannot be tackled just yet. As RFC4741 says, " This document does not specify an authorization scheme, as such a scheme should be tied to a meta-data model or a data model." and as yet, there is no data model; hence, no authorization, not yet, nor, IMHO, for some time to come. In the light of this, I am not sure what adding a normative statement to this I-D would do; delay publication sine die? Tom Petch > Another security concern that I have related to the partial-lock > operation is that the configuration might become inconsistent if > one manager changes one part of a datastore at the same time that > another manager changes another part. The resulting inconsistency > could have security implications. For example, an organization might > have a rule that either the firewall or the intrusion detection > features must be enabled on a device. If one manager might lock > intrusion detection configuration, check that the firewall is > enabled, and then disable intrusion detection. Another manager > might lock the firewall configuration, check that intrusion detection > is enabled, and then disable the firewall. If those operations > were interleaved, they could result in a violation of policy. > To address this concern, I suggest that the draft contain a > warning that parallel operations are tricky and should be > carefully considered. Sometimes, it may be necessary to lock > a portion of the datastore that will not be modified, just to > ensure the datastore remains consistent and compliant with policy. > > Of course, a human administrator using a GUI could easily > run into this same problem if the human does not have the > ability to control configuration locks. The human might > look at the firewall configuration to make sure that it's > enabled and then switch to another section of the display > to disable the intrusion detection function. If the management > console only locks the datastore to execute the administrator's > request to disable intrusion detection, overlapping operations > from another administrator could result in a bad configuration. > This problem can arise even without the partial lock operation. > Probably the best that can be done here is to include language > warning of this sort of problem. Warning human administrators > that someone else is also editing the device should help and > giving these administrators the ability to easily communicate > with each other to coordinate their work would also probably help. > > Here are a few minor issues: > > * At the end of section 2.1.1.2, the comma in the last > sentence is superfluous. > > * In section 2.1.1.3 in the sentence "Manager A terminates it's > session", the apostrophe should be removed. > > * In section 2.4.1, I think that the sentence that begins with > "If someone later creates a new interface" would be clearer > if the second comma was changed to "so". > > * Later in section 2.4.1, the sentence that begins with > "A NETCONF server MUST" should instead start with "A NETCONF > server that supports partial locks MUST". I think that > paragraph should end with "all of the overlapping locks are > released" not "all of the locks are released". > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From bertietf@bwijnen.net Thu Aug 13 04:36:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC39D3A6A3F; Thu, 13 Aug 2009 04:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.886 X-Spam-Level: X-Spam-Status: No, score=-8.886 tagged_above=-999 required=5 tests=[AWL=1.713, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tMpGjsEzxFy; Thu, 13 Aug 2009 04:36:23 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 123863A6896; Thu, 13 Aug 2009 04:36:22 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MbYab-0008Su-F0; Thu, 13 Aug 2009 13:35:31 +0200 Received: from guest-116.ripe.net (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 6561D2F583; Thu, 13 Aug 2009 13:35:25 +0200 (CEST) Message-ID: <4A83FA7D.9040209@bwijnen.net> Date: Thu, 13 Aug 2009 13:35:25 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Stephen Hanna References: <016701ca1bf7$400ac480$0601a8c0@allison> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd427df3ea51afe8176b514df3672d4b60d X-Mailman-Approved-At: Thu, 13 Aug 2009 04:45:02 -0700 Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "Tom.Petch" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:36:24 -0000 Stephen, I think it is your first bullet point. We have not standardize it yet. And so it is implementation dependent as to what authorization is used. Bert Stephen Hanna wrote: > Tom, > > Thanks for responding to my comments. Allow me to respond. > > You wrote: > >> As a participant in netconf, I see authorization as one of those topics >> which the Working Group sees as necessary but cannot be tackled just >> yet. As RFC4741 says, >> " This document does not specify an authorization scheme, as such a >> scheme should be tied to a meta-data model or a data model." >> and as yet, there is no data model; hence, no authorization, not yet, >> nor, IMHO, for some time to come. >> > > This is just the sort of background information that a WG participant > would know but that a secdir reviewer would not. Please allow me to > ask a clarifying question. You say that there is no authorization yet. > I think that could mean several things: > > 1) Existing NETCONF implementations implement authorization, ensuring > that each user gets an appropriate and perhaps different level of > access to the database. However, there are no standards for the > manner in which authorization is performed or configured. > > 2) Existing NETCONF implementations require authentication but generally > just give complete read-write access to the database to all authenticated > users. > > 3) Existing NETCONF implementations do not require authentication. > Anyone with network access has complete, unfettered access to > the database and can modify it at will. > > Could you tell me which of these meanings is most accurate? > Of course, it could be a mix of these but I'd like to get your > real-world assessment of the state of the NETCONF world. > If the answer is 3), we have a serious problem! If the answer > is 1) or 2), that's acceptable in my view. > > Now on to the language in the draft. My comment was relating to > this quote from the Security Considerations: > > >> "Only an authenticated and authorized user can request a partial >> lock." >> > > I'm afraid that this statement is not justified if there is no > normative text requiring implementations to comply. I suggest > that normative text be added to at least require authentication. > With such text, the statement above could be justified. Requiring > that levels of authorization be implemented is less important > in this application. And standardizing the manner in which > authorization is performed or configured (which I think is > your concern with respect to the lack of a data model) is > really not important at all unless NETCONF customers or > vendors decide that it is. Standardizing an authorization > policy format is a tremendously challenging task for any > protocol and often not necessary. > > I hope that this helps you address my comments in a reasonable > and achievable manner. The intent of secdir comments is not to > impose unreasonable requirements. It is to point out issues that > might not be evident to someone who is not a security expert. > > Thanks, > > Steve > > >> -----Original Message----- >> From: Tom.Petch [mailto:sisyphus@dial.pipex.com] >> Sent: Thursday, August 13, 2009 4:00 AM >> To: Stephen Hanna; secdir@ietf.org; ietf@ietf.org; >> draft-ietf-netconf-partial-lock@tools.ietf.org >> Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt >> >> ----- Original Message ----- >> From: "Stephen Hanna" >> To: ; ; ; >> >> Sent: Monday, August 10, 2009 4:28 PM >> >> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs >>> >> should treat >> >>> these comments just like any other last call comments. >>> >>> This document defines optional partial-lock and partial-unlock >>> operations to be added to the NETCONF protocol. These operations >>> are used to lock only part of a configuration datastore, allowing >>> multiple management sessions to modify the configuration of a >>> device at a single time. >>> >>> The Security Considerations section of the document highlights >>> the risk that a malicious party might employ partial locks to >>> impede access to a device's configuration. Therefore, it states >>> "Only an authenticated and authorized user can request a partial >>> lock." Unfortunately, I cannot find any normative text (MUST) >>> that supports this statement. The NETCONF spec (RFC 4741) says >>> "NETCONF connections must be authenticated" but this is not >>> clearly normative. Perhaps a NETCONF expert can point to some >>> normative text requiring authentication and authorization for >>> any party requesting a partial lock. If not, I suggest that >>> such normative text be added to the partial-lock specification. >>> >>> >> As a participant in netconf, I see authorization as one of >> those topics >> which the Working Group sees as necessary but cannot be tackled just >> yet. As RFC4741 says, >> " This document does not specify an authorization scheme, as such a >> scheme should be tied to a meta-data model or a data model." >> and as yet, there is no data model; hence, no authorization, not yet, >> nor, IMHO, for some time to come. In the light of this, I am not sure >> what adding a normative statement to this I-D would do; delay >> publication sine die? >> >> Tom Petch >> >> >> >> >> >>> Another security concern that I have related to the partial-lock >>> operation is that the configuration might become inconsistent if >>> one manager changes one part of a datastore at the same time that >>> another manager changes another part. The resulting inconsistency >>> could have security implications. For example, an organization might >>> have a rule that either the firewall or the intrusion detection >>> features must be enabled on a device. If one manager might lock >>> intrusion detection configuration, check that the firewall is >>> enabled, and then disable intrusion detection. Another manager >>> might lock the firewall configuration, check that intrusion >>> >> detection >> >>> is enabled, and then disable the firewall. If those operations >>> were interleaved, they could result in a violation of policy. >>> To address this concern, I suggest that the draft contain a >>> warning that parallel operations are tricky and should be >>> carefully considered. Sometimes, it may be necessary to lock >>> a portion of the datastore that will not be modified, just to >>> ensure the datastore remains consistent and compliant with policy. >>> >>> Of course, a human administrator using a GUI could easily >>> run into this same problem if the human does not have the >>> ability to control configuration locks. The human might >>> look at the firewall configuration to make sure that it's >>> enabled and then switch to another section of the display >>> to disable the intrusion detection function. If the management >>> console only locks the datastore to execute the administrator's >>> request to disable intrusion detection, overlapping operations >>> from another administrator could result in a bad configuration. >>> This problem can arise even without the partial lock operation. >>> Probably the best that can be done here is to include language >>> warning of this sort of problem. Warning human administrators >>> that someone else is also editing the device should help and >>> giving these administrators the ability to easily communicate >>> with each other to coordinate their work would also probably help. >>> >>> Here are a few minor issues: >>> >>> * At the end of section 2.1.1.2, the comma in the last >>> sentence is superfluous. >>> >>> * In section 2.1.1.3 in the sentence "Manager A terminates it's >>> session", the apostrophe should be removed. >>> >>> * In section 2.4.1, I think that the sentence that begins with >>> "If someone later creates a new interface" would be clearer >>> if the second comma was changed to "so". >>> >>> * Later in section 2.4.1, the sentence that begins with >>> "A NETCONF server MUST" should instead start with "A NETCONF >>> server that supports partial locks MUST". I think that >>> paragraph should end with "all of the overlapping locks are >>> released" not "all of the locks are released". >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > > From shanna@juniper.net Thu Aug 13 06:03:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5AC3A6AEF for ; Thu, 13 Aug 2009 06:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBnM6Q9buGon for ; Thu, 13 Aug 2009 06:03:14 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 848B63A68CD for ; Thu, 13 Aug 2009 06:03:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSoQOGpZun9HrALFeut3dxLXa6+sPV/Qr@postini.com; Thu, 13 Aug 2009 06:03:18 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 13 Aug 2009 05:56:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 13 Aug 2009 08:56:28 -0400 From: Stephen Hanna To: "Bert (IETF) Wijnen" Date: Thu, 13 Aug 2009 08:55:30 -0400 Thread-Topic: secdir review of draft-ietf-netconf-partial-lock-09.txt Thread-Index: AcocCjF5enqse6yUTiq5K+dYE/Ll6gACn90w Message-ID: References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> In-Reply-To: <4A83FA7D.9040209@bwijnen.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: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "Tom.Petch" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:03:15 -0000 Thanks to Dan and Bert for answering my question. If most NETCONF implementations authenticate users and implement some form of authorization scheme, there should be no problem with including text in draft-ietf-netconf-partial-lock-09.txt that says "NETCONF servers that implement partial locks MUST ensure that only an authenticated and authorized user can request a partial lock." Even a server that implements authentication but does not implement fine-grained authorization would meet this requirement. It would just be saying that all authenticated users are fully authorized to perform any operation on the server. Are there any concerns with this proposal? If so, please explain. Thanks, Steve > -----Original Message----- > From: Bert (IETF) Wijnen [mailto:bertietf@bwijnen.net]=20 > Sent: Thursday, August 13, 2009 7:35 AM > To: Stephen Hanna > Cc: Tom.Petch; secdir@ietf.org; ietf@ietf.org;=20 > draft-ietf-netconf-partial-lock@tools.ietf.org > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt >=20 > Stephen, >=20 > I think it is your first bullet point. We have not standardize it yet. > And so it is implementation dependent as to what=20 > authorization is used. >=20 > Bert >=20 >=20 > Stephen Hanna wrote: > > Tom, > > > > Thanks for responding to my comments. Allow me to respond. > > > > You wrote: > > =20 > >> As a participant in netconf, I see authorization as one of=20 > those topics > >> which the Working Group sees as necessary but cannot be=20 > tackled just > >> yet. As RFC4741 says, > >> " This document does not specify an authorization scheme,=20 > as such a > >> scheme should be tied to a meta-data model or a data model." > >> and as yet, there is no data model; hence, no=20 > authorization, not yet, > >> nor, IMHO, for some time to come. > >> =20 > > > > This is just the sort of background information that a WG=20 > participant > > would know but that a secdir reviewer would not. Please allow me to > > ask a clarifying question. You say that there is no=20 > authorization yet. > > I think that could mean several things: > > > > 1) Existing NETCONF implementations implement=20 > authorization, ensuring > > that each user gets an appropriate and perhaps different level of > > access to the database. However, there are no standards for the > > manner in which authorization is performed or configured. > > > > 2) Existing NETCONF implementations require authentication=20 > but generally > > just give complete read-write access to the database to=20 > all authenticated > > users. > > > > 3) Existing NETCONF implementations do not require authentication. > > Anyone with network access has complete, unfettered access to > > the database and can modify it at will. > > > > Could you tell me which of these meanings is most accurate? > > Of course, it could be a mix of these but I'd like to get your > > real-world assessment of the state of the NETCONF world. > > If the answer is 3), we have a serious problem! If the answer > > is 1) or 2), that's acceptable in my view. > > > > Now on to the language in the draft. My comment was relating to > > this quote from the Security Considerations: > > > > =20 > >> "Only an authenticated and authorized user can request a partial > >> lock." > >> =20 > > > > I'm afraid that this statement is not justified if there is no > > normative text requiring implementations to comply. I suggest > > that normative text be added to at least require authentication. > > With such text, the statement above could be justified. Requiring > > that levels of authorization be implemented is less important > > in this application. And standardizing the manner in which > > authorization is performed or configured (which I think is > > your concern with respect to the lack of a data model) is > > really not important at all unless NETCONF customers or > > vendors decide that it is. Standardizing an authorization > > policy format is a tremendously challenging task for any > > protocol and often not necessary. > > > > I hope that this helps you address my comments in a reasonable > > and achievable manner. The intent of secdir comments is not to > > impose unreasonable requirements. It is to point out issues that > > might not be evident to someone who is not a security expert. > > > > Thanks, > > > > Steve > > > > =20 > >> -----Original Message----- > >> From: Tom.Petch [mailto:sisyphus@dial.pipex.com]=20 > >> Sent: Thursday, August 13, 2009 4:00 AM > >> To: Stephen Hanna; secdir@ietf.org; ietf@ietf.org;=20 > >> draft-ietf-netconf-partial-lock@tools.ietf.org > >> Subject: Re: secdir review of=20 > draft-ietf-netconf-partial-lock-09.txt > >> > >> ----- Original Message ----- > >> From: "Stephen Hanna" > >> To: ; ; ; > >> > >> Sent: Monday, August 10, 2009 4:28 PM > >> > >> =20 > >>> I have reviewed this document as part of the security=20 > directorate's > >>> ongoing effort to review all IETF documents being processed by the > >>> IESG. These comments were written primarily for the=20 > benefit of the > >>> security area directors. Document editors and WG chairs=20 > >>> =20 > >> should treat > >> =20 > >>> these comments just like any other last call comments. > >>> > >>> This document defines optional partial-lock and partial-unlock > >>> operations to be added to the NETCONF protocol. These operations > >>> are used to lock only part of a configuration datastore, allowing > >>> multiple management sessions to modify the configuration of a > >>> device at a single time. > >>> > >>> The Security Considerations section of the document highlights > >>> the risk that a malicious party might employ partial locks to > >>> impede access to a device's configuration. Therefore, it states > >>> "Only an authenticated and authorized user can request a partial > >>> lock." Unfortunately, I cannot find any normative text (MUST) > >>> that supports this statement. The NETCONF spec (RFC 4741) says > >>> "NETCONF connections must be authenticated" but this is not > >>> clearly normative. Perhaps a NETCONF expert can point to some > >>> normative text requiring authentication and authorization for > >>> any party requesting a partial lock. If not, I suggest that > >>> such normative text be added to the partial-lock specification. > >>> > >>> =20 > >> As a participant in netconf, I see authorization as one of=20 > >> those topics > >> which the Working Group sees as necessary but cannot be=20 > tackled just > >> yet. As RFC4741 says, > >> " This document does not specify an authorization scheme,=20 > as such a > >> scheme should be tied to a meta-data model or a data model." > >> and as yet, there is no data model; hence, no=20 > authorization, not yet, > >> nor, IMHO, for some time to come. In the light of this, I=20 > am not sure > >> what adding a normative statement to this I-D would do; delay > >> publication sine die? > >> > >> Tom Petch > >> > >> > >> > >> > >> =20 > >>> Another security concern that I have related to the partial-lock > >>> operation is that the configuration might become inconsistent if > >>> one manager changes one part of a datastore at the same time that > >>> another manager changes another part. The resulting inconsistency > >>> could have security implications. For example, an=20 > organization might > >>> have a rule that either the firewall or the intrusion detection > >>> features must be enabled on a device. If one manager might lock > >>> intrusion detection configuration, check that the firewall is > >>> enabled, and then disable intrusion detection. Another manager > >>> might lock the firewall configuration, check that intrusion=20 > >>> =20 > >> detection > >> =20 > >>> is enabled, and then disable the firewall. If those operations > >>> were interleaved, they could result in a violation of policy. > >>> To address this concern, I suggest that the draft contain a > >>> warning that parallel operations are tricky and should be > >>> carefully considered. Sometimes, it may be necessary to lock > >>> a portion of the datastore that will not be modified, just to > >>> ensure the datastore remains consistent and compliant with policy. > >>> > >>> Of course, a human administrator using a GUI could easily > >>> run into this same problem if the human does not have the > >>> ability to control configuration locks. The human might > >>> look at the firewall configuration to make sure that it's > >>> enabled and then switch to another section of the display > >>> to disable the intrusion detection function. If the management > >>> console only locks the datastore to execute the administrator's > >>> request to disable intrusion detection, overlapping operations > >>> from another administrator could result in a bad configuration. > >>> This problem can arise even without the partial lock operation. > >>> Probably the best that can be done here is to include language > >>> warning of this sort of problem. Warning human administrators > >>> that someone else is also editing the device should help and > >>> giving these administrators the ability to easily communicate > >>> with each other to coordinate their work would also probably help. > >>> > >>> Here are a few minor issues: > >>> > >>> * At the end of section 2.1.1.2, the comma in the last > >>> sentence is superfluous. > >>> > >>> * In section 2.1.1.3 in the sentence "Manager A terminates it's > >>> session", the apostrophe should be removed. > >>> > >>> * In section 2.4.1, I think that the sentence that begins with > >>> "If someone later creates a new interface" would be clearer > >>> if the second comma was changed to "so". > >>> > >>> * Later in section 2.4.1, the sentence that begins with > >>> "A NETCONF server MUST" should instead start with "A NETCONF > >>> server that supports partial locks MUST". I think that > >>> paragraph should end with "all of the overlapping locks are > >>> released" not "all of the locks are released". > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf > >>> =20 > >> =20 > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > =20 > = From ietf@andybierman.com Thu Aug 13 08:28:17 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2886028C0F1 for ; Thu, 13 Aug 2009 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHPnu7+FfyrG for ; Thu, 13 Aug 2009 08:28:17 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id C956628C0EF for ; Thu, 13 Aug 2009 08:28:15 -0700 (PDT) Received: (qmail 657 invoked from network); 13 Aug 2009 15:25:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (ietf@67.125.157.61 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 13 Aug 2009 15:25:18 -0000 X-YMail-OSG: bWQ0oZ0VM1nNdLT2TL7AWbez_vUN_jnlY5eQhKGiBJPwGPs30AfvH1hFSGtK6a6R9ddF7a9SQwzZhcZIoVkhH2_73VkkqvZcJ8txWjLZXxBZWUPrPxbS5NKTMGue_4ukt8128xtVNfDB00sozxrzgg5l4p6CH7H7nMnauXWoal1tMfXNqQxk.hVwU5p8PdCWTFKQBJab.vpBTsb8sluji6n.kKJnaCpLBCbGU39Cqt16Cn.QmRukuKYh_F1EdcHHrDSlZtecUJsM4t0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8430BE.2050701@andybierman.com> Date: Thu, 13 Aug 2009 08:26:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Stephen Hanna References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Aug 2009 08:31:49 -0700 Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "secdir@ietf.org" , "Bert \(IETF\) Wijnen" , "ietf@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 15:28:17 -0000 Stephen Hanna wrote: > Thanks to Dan and Bert for answering my question. > If most NETCONF implementations authenticate users > and implement some form of authorization scheme, > there should be no problem with including text > in draft-ietf-netconf-partial-lock-09.txt that > says "NETCONF servers that implement partial > locks MUST ensure that only an authenticated > and authorized user can request a partial lock." > Even a server that implements authentication but > does not implement fine-grained authorization > would meet this requirement. It would just be > saying that all authenticated users are fully > authorized to perform any operation on the server. > > Are there any concerns with this proposal? > If so, please explain. > The partial-lock operation does not work on the candidate database, yet the draft insists that this database is supported. It also says it works on the startup database, yet there is no way to edit this database, so why does it need to be partially locked? There is a global commit operation issued by a session. That session must be authorized to make all the changes to the running config that are contained in the candidate (all-or-nothing). The partial-lock design does not really have any affect on the candidate -- using it is just as ineffective as not using any locking at all. So it is subject to the 'candidate-deadlock' first described by Wes Hardaker: Let's say there is a simple config to edit: 3 fred Let's say user A is authorized to write /foo and user B is authorized to write /bar. 1) user A does partial-lock(target='candidate', data='/foo') 2) user B skips the lock and just edits the /bar leaf directly in the candidate database (even if user B took out a partial lock on /bar, the result would be the same) HALT: User A is not authorized to issue commit User B is not authorized to issue commit The database is wedged until somebody issues a discard-changes. discard-changes only works because authorization is ignored, otherwise the agent would be deadlocked. Only the global lock operation defined in RFC 4741 can prevent this problem. > Thanks, > > Steve Andy From secdir-bounces@mit.edu Thu Aug 13 11:00:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4123A6873 for ; Thu, 13 Aug 2009 11:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.854 X-Spam-Level: X-Spam-Status: No, score=-3.854 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfvEgQej+qlQ for ; Thu, 13 Aug 2009 11:00:05 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id DF5ED3A697C for ; Thu, 13 Aug 2009 11:00:04 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7DI02QJ022869 for ; Thu, 13 Aug 2009 14:00:02 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7DI00T4022851 for ; Thu, 13 Aug 2009 14:00:00 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7DHxqFG011885 for ; Thu, 13 Aug 2009 13:59:52 -0400 (EDT) Received: from mx11.bbn.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 05A091B3B33D; Thu, 13 Aug 2009 13:59:51 -0400 (EDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu with ESMTP id yJbfqAyFYBFzEruJ; Thu, 13 Aug 2009 13:59:50 -0400 (EDT) Received-SPF: pass (mit.edu: domain of kent@bbn.com designates 128.33.0.80 as permitted sender) receiver=mit.edu; client_ip=128.33.0.80; envelope-from=kent@bbn.com; Received: from dhcp89-089-040.bbn.com ([128.89.89.40]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MbdeW-0004R7-G2; Thu, 13 Aug 2009 12:59:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 13 Aug 2009 13:50:38 -0400 To: Sam Hartman From: Stephen Kent X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: secdir@mit.edu Subject: Re: [secdir] Security participation in the LISP WG appreciated X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 18:00:05 -0000 Sam, Since the current generation of IPsec specs recommends ESP-NULL over AH, any reference to 2402 is very questionable for any new WG document, e.g., LISP documents. Also, MD5 is not an algorithm that I think most SECDIR folks would recommend at this point in time. What motivates this retro security fetish? Also, what does "static" AH mean re authentication data, key lifetime, etc.? I am not volunteering to enter the LIPS WG debate. However, I will volunteer to review and comment on LISP documents when they come up for IETF LC. The security ADs may choose to pay attention to such comments, which might result in a DISCUSS at that stage. Presumably the authors would like to avoid that :-). Steve _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From hartmans@mit.edu Thu Aug 13 11:55:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1C728C197 for ; Thu, 13 Aug 2009 11:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn2GRcFz+14x for ; Thu, 13 Aug 2009 11:55:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id D6AB528C14E for ; Thu, 13 Aug 2009 11:54:58 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 011FF641DA; Thu, 13 Aug 2009 14:54:56 -0400 (EDT) To: Stephen Kent References: From: Sam Hartman Date: Thu, 13 Aug 2009 14:54:56 -0400 In-Reply-To: (Stephen Kent's message of "Thu\, 13 Aug 2009 13\:50\:38 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , secdir@ietf.org Subject: Re: [secdir] Security participation in the LISP WG appreciated X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 18:55:02 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> Sam, Since the current generation of IPsec specs Stephen> recommends ESP-NULL over AH, any reference to 2402 is Stephen> very questionable for any new WG document, e.g., LISP Stephen> documents. Also, MD5 is not an algorithm that I think Stephen> most SECDIR folks would recommend at this point in Stephen> time. What motivates this retro security fetish? I think what's going on here is that there is a lack of familiarity with security protocols or some of the thinking about IPsec in the last 10 years that is built into 4301. I suspect that the people designing this protocol were familiar with the tcp-md5 option and picked something that had the closest wire format to that but ran over UDP without really doing much design or requirements work. They don't understand why they need something more complicated than that. "Because if you don't, you won't get anything published," is probably a true statement--I know I'd never send in a publication request for the current document, and I'll be the chair who reviews it. However that approach really frustrates people. It's far better to educate them about what the security issues are and what the technical justification is for a quality security mechanism. Obviously, I can help with that. However we're having similar issues on MTU handling, transport considerations, middlebox considerations, extensibility,etc. In short, we're taking a neat protocol idea that works in limited situations and refining it for the whole Internet. So, I have my hands full with the chair role and can't take on the security education role as well. From wjhns1@hardakers.net Thu Aug 13 13:37:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564B628C204; Thu, 13 Aug 2009 13:37:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYCwE1ALKxXD; Thu, 13 Aug 2009 13:37:50 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 7303628C191; Thu, 13 Aug 2009 13:37:50 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 8E468981D7; Thu, 13 Aug 2009 13:37:50 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> <4A8430BE.2050701@andybierman.com> Date: Thu, 13 Aug 2009 13:37:50 -0700 In-Reply-To: <4A8430BE.2050701@andybierman.com> (Andy Bierman's message of "Thu, 13 Aug 2009 08:26:54 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:37:51 -0000 >>>>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman said: AB> discard-changes only works because authorization is ignored, AB> otherwise the agent would be deadlocked. Huh???? why would discard-changes be authorization ignorant??? That's just as unsafe (unless you're only discarding your own changes). AB> Only the global lock operation defined in RFC 4741 AB> can prevent this problem. The global lock has different issues. The problem isn't with the locking. Locking, and partial locking are good. It's with the global-level commit operation. -- Wes Hardaker Cobham Analytic Solutions From ietf@andybierman.com Thu Aug 13 13:55:13 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91AA728C0E2 for ; Thu, 13 Aug 2009 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFd8JRqMAJPq for ; Thu, 13 Aug 2009 13:55:12 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id EBAC828C0E3 for ; Thu, 13 Aug 2009 13:55:12 -0700 (PDT) Received: (qmail 1344 invoked from network); 13 Aug 2009 20:53:38 -0000 Received: from unknown (HELO ?192.168.0.10?) (ietf@67.125.157.61 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 20:53:37 -0000 X-YMail-OSG: aksmePEVM1lUEdReSWXKC6hvxO_2ZkZsSEmDEMi75FbJzsCbtsHecXpnSQE.w_I8gTdAFvYyselTnrxymMzu.J4NvsoZzTTAbBgFPgiC5P6hXAR3.Yo6OgXrFVHL635zb8uNN.IaRjZd.3r7wf87eFwBtR0XvLo6Rj3YCZUEk68jxkY_bovhSKLGU3JVv3lvmIzrWCDd9OwTZOUEaDy59.r3Tt6Zvu63.6TFFTmVZUGUQa8YFfzV1j5jrFks9o8JYybIXKD9Kbz8cVhZ8LnN4WzwtrfJHgqQ_m2HcFJPEtLHYakqS.vLPTmKZmQzG6_PBYbiG88wKeCp5j9f X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A847DB3.2050209@andybierman.com> Date: Thu, 13 Aug 2009 13:55:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Wes Hardaker References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> <4A8430BE.2050701@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 20:55:13 -0000 Wes Hardaker wrote: >>>>>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman said: > > AB> discard-changes only works because authorization is ignored, > AB> otherwise the agent would be deadlocked. > > Huh???? why would discard-changes be authorization ignorant??? That's > just as unsafe (unless you're only discarding your own changes). > Oherwise the agent would deadlock. discard-changes does not affect the running configuration. It just resets the scratchpad database. Why bother applying the ACLs before the edit operation is attempted for real? > AB> Only the global lock operation defined in RFC 4741 > AB> can prevent this problem. > > The global lock has different issues. > > The problem isn't with the locking. Locking, and partial locking are > good. It's with the global-level commit operation. Requiring small embedded devices to serve as robust database engines may be more expensive than the rest of the code combined. We are coming from an operational environment based on humans using the CLI, which has no locking at all. The globally locked candidate "edit, validate, and commit" model is way better than anything we ever had in SNMP or CLI. If concurrent edits instead of serialized edits are needed, then the :writable-running + :partial-lock capabilities support that. Andy From lars.eggert@nokia.com Fri Aug 14 05:16:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591F43A68C5; Fri, 14 Aug 2009 05:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Np7sP23+rfd; Fri, 14 Aug 2009 05:16:49 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 3D2B13A69F6; Fri, 14 Aug 2009 05:16:49 -0700 (PDT) Received: from [10.180.41.33] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7EBQijV067790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Aug 2009 14:26:45 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Sandra Murphy , "mdalal@cisco.com (mdalal)" , "ananth@cisco.com (ananth)" , IESG IESG , secdir@ietf.org In-Reply-To: <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> Content-Type: multipart/signed; boundary=Apple-Mail-52--788428443; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 14:26:34 +0300 References: <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Fri, 14 Aug 2009 14:26:46 +0300 (EEST) Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 12:16:50 -0000 --Apple-Mail-52--788428443 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, what's going on with this draft? Is this still waiting for Sandy, or is the ball with the authors? Lars On 2009-7-9, at 10:06, Eggert Lars (Nokia-NRC/Espoo) wrote: > Hi, Sandy, > > On 2009-6-8, at 16:59, Sandra Murphy wrote: >> I've been on the road, so this is just a quick note to say that I >> still >> have questions, with a promise of more full answer when I get back >> to the >> office tomorrow. > > the authors are still waiting to hear your additional questions. > Please let me know when we can expect them, so I know when I can > expect a revision from the authors. > > Thanks, > Lars > >> All the following done really from memory from a >> re-review yesterday. Just so you know I haven't forgotten you. >> >> About quoting text: >> >> The example you point to of what each mitigation says is a good case. >> (what is "rg"?) >> >> You posit a case 1 and case 2. This is a summary of what 793 says, >> not a >> quote. 793 spreads the discussion over 2 pages. your case 1 is >> represented in a parenthetical remark in an "otherwise" clause - >> hard to >> find. And you have a typo in the inequality. And the case 2 in >> 793 is >> broken out over three different groupings of states. Do you mean >> the new >> ACK to be generated in all three state groups? >> >> About the stingency. >> >> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then in 793, >> the >> ack is < UNA and so "it is ignored", in your draft the ack is > >> UNA-max.snd.wnd so it is acceptable. >> >> So your draft accepts more ACKs that 793. >> >> Have I lost my ability to tell > from > more >> ACKS as "more stringent"? >> >> About the guidance to implementors. >> >> It still looks to me like this guidance is only useful to >> implementors who >> are implementing both the OS TCP stack *AND* the application. I.E., >> freebsd won't know whether this to follow the guidance or not but >> cisco/juniper/etc will. >> >> What is the "AS"? >> >> About grammar checks: >> >> And you did not miss email, I lost my marked up copy, so I've gone >> through for the grammar check again (don't think I found all that >> many >> nits) and will send to you. >> >> --Sandy >> >> > --Apple-Mail-52--788428443 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTQxMTI2MzVaMCMGCSqGSIb3DQEJBDEWBBRRpFR0zCPBlClK szmZ024hUHdTdjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAjt9dMgtbja8SIz5HmzINH6l3S0VmPuFSsYQJYTu8VYX2QgXDshzC TwYmd/gTAv+bqW8nnz4ujZHnGt6AN00O8Au7Qur53CW8fCBJEfNnJODyovVWMDAyafy2g2CPvbyv zYbdZwTTOaURL7iUNZ5irqhQsFSoeibo6N0QJiiUv/WhdojP/kS+QzPjlX8jOFGGHH6cEuXrJaQb L6RZ52Hf+U8ycMBSns4flXjR0NVLRTo98Yo+1JHe0zDrID7NNUL38xcQJdI8dQire8eOTR+iYzYA ZZMrKAz2/RLZTiMqRG3oKcc+JyMgr5i7WjjGTaQxukQu908+CsqgcVTF2UjLNQAAAAAAAA== --Apple-Mail-52--788428443-- From wjhns1@hardakers.net Fri Aug 14 07:42:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7529B3A6A3B; Fri, 14 Aug 2009 07:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkEe3WnFhK2u; Fri, 14 Aug 2009 07:41:59 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BFBCF3A6A0D; Fri, 14 Aug 2009 07:41:58 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id DFDD998208; Fri, 14 Aug 2009 07:41:58 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> <4A8430BE.2050701@andybierman.com> <4A847DB3.2050209@andybierman.com> Date: Fri, 14 Aug 2009 07:41:58 -0700 In-Reply-To: <4A847DB3.2050209@andybierman.com> (Andy Bierman's message of "Thu, 13 Aug 2009 13:55:15 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "secdir@ietf.org" , "draft-ietf-netconf-partial-lock@tools.ietf.org" , "ietf@ietf.org" , Wes Hardaker Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:42:00 -0000 >>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman said: AB> Oherwise the agent would deadlock. AB> discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. AB> It just resets the scratchpad database. AB> Why bother applying the ACLs before the edit operation AB> is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). AB> Requiring small embedded devices to serve as robust AB> database engines may be more expensive than AB> the rest of the code combined. We are coming from AB> an operational environment based on humans using the CLI, AB> which has no locking at all. The globally locked AB> candidate "edit, validate, and commit" model AB> is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using "vi" and hitting "save" without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I think "being fixed" is a great long term goal. But for right now, I'd suggest we simple say "this is version 1 at the moment and it is currently designed for use by single-operator systems". (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). -- Wes Hardaker Cobham Analytic Solutions From ietf@andybierman.com Fri Aug 14 08:12:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7373A6D31 for ; Fri, 14 Aug 2009 08:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKQNOrbE+N0e for ; Fri, 14 Aug 2009 08:12:46 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E939E3A6CDE for ; Fri, 14 Aug 2009 08:12:45 -0700 (PDT) Received: (qmail 81614 invoked from network); 14 Aug 2009 15:12:47 -0000 Received: from unknown (HELO ?192.168.0.10?) (ietf@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 15:12:47 -0000 X-YMail-OSG: ftp8zPkVM1nRxYBaJI2kokGKf5TRXoqH5cu5CMadm.Ip9OIytD1fIxOmUkRhutuK1aJJJ2ZdEyW4q_imBxLZfQYq3RRZQDUOLLLCAbF6pv9Imtn.VwJ.v8NzX8Oq3YTbEFx.nQG7hlILgmUXpwgLkmpoHvtMY8KNkhOUT2nNlcE76Z7Y5Dqatf5QDv0N819thAgi7WPUVEw822M0VY1E8o1ECjMcCvbeRtsNtCanJV3MTfNx223Icz7qcTEZNKw82OPJ49AHj7gBsdvNXmUjZm.spjYhBWei2DDDNUnCaV9C9A0ojrM2xk.4d7m1WRjo_uUye8zTs.xjibubLCpHdV3Cp8DvtusAsl02r5FkhL8R X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A857EDB.9010803@andybierman.com> Date: Fri, 14 Aug 2009 08:12:27 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Wes Hardaker References: <016701ca1bf7$400ac480$0601a8c0@allison> <4A83FA7D.9040209@bwijnen.net> <4A8430BE.2050701@andybierman.com> <4A847DB3.2050209@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:12:47 -0000 Wes Hardaker wrote: >>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman said: > > AB> Oherwise the agent would deadlock. > AB> discard-changes does not affect the running configuration. > > No, but it does affect the other users notion of changes. You should > never be allowed to discard changes that another user has made. > this assumes you have an access control model in mind. I do too -- they aren't the same. Without any standards for this, neither of us are wrong. > AB> It just resets the scratchpad database. > AB> Why bother applying the ACLs before the edit operation > AB> is attempted for real? > > user 1: add new important policy configuration > user 2: discard-changes > user 1: commit > > Granted, user 1 should be using locks of some kind. > what is the NETCONF 'add new' operation? step 1 is very unclear. > To undo changes it's rather important that someone with proper > authorization to the everything changed (IE, an admin) performs the > discard. > > Or are you suggesting that one shouldn't ever have access control > applied to the candidate store in the first place? (I hope not). > I apply it to the candidate and to running, except discard-changes, otherwise the agent would deadlock often and that would be counter-productive to network operations. When you start with an awful design premises like locking should be optional to use, then you might end up with messy code. Nothing new there. > AB> Requiring small embedded devices to serve as robust > AB> database engines may be more expensive than > AB> the rest of the code combined. We are coming from > AB> an operational environment based on humans using the CLI, > AB> which has no locking at all. The globally locked > AB> candidate "edit, validate, and commit" model > AB> is way better than anything we ever had in SNMP or CLI. > > If you look at history of operating just about anything, after it gets > to a point where multiple operators need to scale things up you'll find > that eventually stuff gets put into a multi-user revision database type > system. We are far beyond the point where operators are editing single > flat-files using "vi" and hitting "save" without any form of revision > control. After that point, then went to locking version control systems > (sccs? I'm forgetting the early version-control system names). Then > people realized that caused huge headaches because the global file > locking, although it prevented some types of problems, caused a bunch of > other problems. Eventually more modern version control systems were > developed that allowed people to simultaneously edit things and only > get bothered when conflicts happen. This was a huge win, ask anyone who > works with version control systems. > > But now, in this space, we're going back to the older methodologies of > editing a single file and hoping that two people don't conflict (with or > without a lock). > again -- when locking is optional to use, the database is never going to be very good. > > I've said this before, but I'll repeat it now: netconf, from a > protocol-operation point of view, is designed to work in a > single-operator type environment. The instant you add multiple-users > with or without different roles all these problems come up. This is > actually just fine, but it needs to either: > > 1) be fixed so that these problems go away. > 2) stop being advertised as a multi-operator type solution. > I disagree. The partial-lock feature is not needed in every environment. NETCONF supports the SQL-like model (write directly to the persistent datastore) and that is good enough. Why does the scratchpad model need to be per-session? That is nice-to-have, but not important. > I think "being fixed" is a great long term goal. But for right now, I'd > suggest we simple say "this is version 1 at the moment and it is > currently designed for use by single-operator systems". > > (And it doesn't prevent an external version-control system for being the > master and pushing the config down. It just doesn't work on the device > itself). Andy From ananth@cisco.com Fri Aug 14 08:22:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71CA3A6C26; Fri, 14 Aug 2009 08:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvwG3c+075Qz; Fri, 14 Aug 2009 08:22:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D62213A6B5F; Fri, 14 Aug 2009 08:22:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPgdhUqrR7O6/2dsb2JhbAC6AogtkRMFhBk X-IronPort-AV: E=Sophos;i="4.43,381,1246838400"; d="scan'208";a="195658229" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Aug 2009 15:22:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7EFMK4d000555; Fri, 14 Aug 2009 08:22:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7EFMKw7024011; Fri, 14 Aug 2009 15:22:20 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 08:22:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 08:22:18 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807CEEA50@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-tcpm-tcpsecure Thread-Index: Acoc0kZJyTVtKQkIQ12/r0XoKoRFkQAICNWQ References: <03C04ACE-5773-4260-AABD-E799E614C469@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , "Sandra Murphy" , "Mitesh Dalal (mdalal)" , "IESG IESG" , X-OriginalArrivalTime: 14 Aug 2009 15:22:20.0194 (UTC) FILETIME=[03EC7820:01CA1CF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3098; t=1250263340; x=1251127340; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=KBOnk2wx1iSJURsOIYV5ybodBvHUi3naSfMU1Af+hPk=; b=MgMAZ6pXzdT5Y2tVVJUL3Z8rG+MyGJomfBFoNiCsb9O0hsGF07oNCPNQET RpECCyEA/p5sMC594zYii780LbZByOJQTqBvPOKN3j7XsWUKVmD0YcIgoHVH CdAWMIIaWi; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:22:16 -0000 Hi Lars, I am still waitng for Sandy, but I am thinking I should go ahead and probably submit what we have now (which I can do in a few days, since it has been a while I looked at what I have and need to double check whether everything is incorporated) -Anantha=20 > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 > Sent: Friday, August 14, 2009 4:27 AM > To: Sandra Murphy; Mitesh Dalal (mdalal); Anantha Ramaiah=20 > (ananth); IESG IESG; secdir@ietf.org > Subject: Re: draft-ietf-tcpm-tcpsecure >=20 > Hi, >=20 > what's going on with this draft? Is this still waiting for=20 > Sandy, or is the ball with the authors? >=20 > Lars >=20 > On 2009-7-9, at 10:06, Eggert Lars (Nokia-NRC/Espoo) wrote: >=20 > > Hi, Sandy, > > > > On 2009-6-8, at 16:59, Sandra Murphy wrote: > >> I've been on the road, so this is just a quick note to say that I=20 > >> still have questions, with a promise of more full answer=20 > when I get=20 > >> back to the office tomorrow. > > > > the authors are still waiting to hear your additional questions. =20 > > Please let me know when we can expect them, so I know when I can=20 > > expect a revision from the authors. > > > > Thanks, > > Lars > > > >> All the following done really from memory from a re-review=20 > yesterday. =20 > >> Just so you know I haven't forgotten you. > >> > >> About quoting text: > >> > >> The example you point to of what each mitigation says is a=20 > good case. > >> (what is "rg"?) > >> > >> You posit a case 1 and case 2. This is a summary of what=20 > 793 says,=20 > >> not a quote. 793 spreads the discussion over 2 pages. =20 > your case 1=20 > >> is represented in a parenthetical remark in an "otherwise"=20 > clause -=20 > >> hard to find. And you have a typo in the inequality. And=20 > the case 2=20 > >> in > >> 793 is > >> broken out over three different groupings of states. Do=20 > you mean the=20 > >> new ACK to be generated in all three state groups? > >> > >> About the stingency. > >> > >> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975,=20 > then in 793,=20 > >> the ack is < UNA and so "it is ignored", in your draft the=20 > ack is >=20 > >> UNA-max.snd.wnd so it is acceptable. > >> > >> So your draft accepts more ACKs that 793. > >> > >> Have I lost my ability to tell > from >> more ACKS as "more stringent"? > >> > >> About the guidance to implementors. > >> > >> It still looks to me like this guidance is only useful to=20 > >> implementors who are implementing both the OS TCP stack *AND* the=20 > >> application. I.E., freebsd won't know whether this to follow the=20 > >> guidance or not but cisco/juniper/etc will. > >> > >> What is the "AS"? > >> > >> About grammar checks: > >> > >> And you did not miss email, I lost my marked up copy, so=20 > I've gone=20 > >> through for the grammar check again (don't think I found all that=20 > >> many > >> nits) and will send to you. > >> > >> --Sandy > >> > >> > > >=20 >=20 From Nicolas.Williams@sun.com Fri Aug 14 15:30:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D2F3A68B0; Fri, 14 Aug 2009 15:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojnXQ-msBA1T; Fri, 14 Aug 2009 15:30:33 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 448173A6872; Fri, 14 Aug 2009 15:30:33 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7EMUXrN003295; Fri, 14 Aug 2009 22:30:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7EMUXwi055482; Fri, 14 Aug 2009 16:30:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7EMCNx9001795; Fri, 14 Aug 2009 17:12:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7EMCMq4001794; Fri, 14 Aug 2009 17:12:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 14 Aug 2009 17:12:22 -0500 From: Nicolas Williams To: Sandra Murphy Message-ID: <20090814221222.GH1043@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: mdalal@cisco.com, ananth@cisco.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 22:30:34 -0000 The mitigations in this I-D are made SHOULD, SHOULD, and MAY (see section 6, page 15). But that means that a TCP implementation could claim conformance while not implementing any of these mitigations. Therefore they should be, IMO, MUST, MUST and MAY (or SHOULD). Also, ISTM that the corner case described in section 4.2 can be avoided by noting the retransmitted SYN and then sending a SYN+ACK to that, and if an acknowledgement comes back then reset the old connection (and if there's no listener to accept the new one, then reset it too). Nico -- From ananth@cisco.com Fri Aug 14 17:33:10 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6373A6DCE; Fri, 14 Aug 2009 17:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PEslJUMLA6w; Fri, 14 Aug 2009 17:33:09 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8E9A03A6B72; Fri, 14 Aug 2009 17:33:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFefhUqrR7PE/2dsb2JhbAC5SogtkG4FhBk X-IronPort-AV: E=Sophos;i="4.43,383,1246838400"; d="scan'208";a="90175637" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Aug 2009 00:33:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7F0XEe3007285; Fri, 14 Aug 2009 17:33:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7F0XEo0022956; Sat, 15 Aug 2009 00:33:14 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 17:33:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 17:33:13 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20090814221222.GH1043@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] draft-ietf-tcpm-tcpsecure Thread-Index: AcodLcrd34qLNifgR0CaN2LtEG9iWQAApZVA References: <20090814221222.GH1043@Sun.COM> From: "Anantha Ramaiah (ananth)" To: "Nicolas Williams" , "Sandra Murphy" X-OriginalArrivalTime: 15 Aug 2009 00:33:14.0047 (UTC) FILETIME=[F98E2CF0:01CA1D3F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2658; t=1250296394; x=1251160394; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[secdir]=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=ORASoBLYeOUQxt2L2LqWxxBrv9+6yIsJUSkzxfdj6tc=; b=UC3UTTgtPZSFsBXlU6M+L2pw130mcYMbn+91pdNmrNBKTDm/T+jNx/PFvK oA0fSHIotK8dF1ISsQHV9NcvtHya2SZgubdX15rXB3q0PYDJd+cBzpUN+OE1 fpluMK/5G/; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Mitesh Dalal \(mdalal\)" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 00:33:10 -0000 Hi Nico, There was a big thread that went in TCPM some time back on this. Initially the mitigations were tagged as "if you implement TCP secure then all these are a MUST", such a statement gave a leeway for implementers to chose whether or not they want to implement tcp-secure. But some folks felt that since TCP secure has an IPR on it should probably not have MUST in them at all, another argument was since TCP secure is mostly useful only for long lived connections (like BGP), then it may not be applicable to hosts and only applicable to routers. I didn't (so as many others) didn't buy this argument, but since it was not going anywhere Lars stepped up with the suggestion of applicability statement to be added to this draft (I haven't seen any other TCP related RFC which has an AS in it, FWIW) and the rest is history. I seriously doubt whether the chairs/Lars/WG would like to fallback to MUST/MUST/SHOULD. In practice I have been given to understand that some vendors have implemented these mitigations. Andre wanted to put these mitigations in BSD as well, not sure about the current status. So, I am guessing if folks are interested in adding robustness to their stacks in general and TCP in particular, they would probably be interested in implementing these mitigations. Let me know if you need some text that needs to be added in the current draft like for example add the reasoning why these mitigations are chosen like this i.e, expand section 6 a little bit. As far as the SYN corner case workaround we chose not to talk about the fix for the same in the draft since the corner case exists in RFC 793 and nothing to do with the current SYN mitigation. -Anantha > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 > Sent: Friday, August 14, 2009 3:12 PM > To: Sandra Murphy > Cc: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal);=20 > iesg@ietf.org; secdir@ietf.org > Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure >=20 > The mitigations in this I-D are made SHOULD, SHOULD, and MAY=20 > (see section 6, page 15). But that means that a TCP=20 > implementation could claim conformance while not implementing=20 > any of these mitigations. > Therefore they should be, IMO, MUST, MUST and MAY (or SHOULD). >=20 > Also, ISTM that the corner case described in section 4.2 can=20 > be avoided by noting the retransmitted SYN and then sending a=20 > SYN+ACK to that, and if an acknowledgement comes back then=20 > reset the old connection (and if there's no listener to=20 > accept the new one, then reset it too). >=20 > Nico > --=20 >=20 From Nicolas.Williams@sun.com Fri Aug 14 18:01:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217C73A69E2; Fri, 14 Aug 2009 18:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXatH5k+MAaL; Fri, 14 Aug 2009 18:00:59 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id CE2203A67C1; Fri, 14 Aug 2009 18:00:54 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7F10nSR003006; Sat, 15 Aug 2009 01:00:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7F10mIH008690; Fri, 14 Aug 2009 19:00:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7F0gZxc002047; Fri, 14 Aug 2009 19:42:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7F0gZKR002046; Fri, 14 Aug 2009 19:42:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 14 Aug 2009 19:42:35 -0500 From: Nicolas Williams To: "Anantha Ramaiah (ananth)" Message-ID: <20090815004234.GN1043@Sun.COM> References: <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.5.7i Cc: secdir@ietf.org, "Mitesh Dalal \(mdalal\)" , iesg@ietf.org Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 01:01:00 -0000 On Fri, Aug 14, 2009 at 05:33:13PM -0700, Anantha Ramaiah (ananth) wrote: > There was a big thread that went in TCPM some time back on this. > Initially the mitigations were tagged as "if you implement TCP secure > then all these are a MUST", such a statement gave a leeway for > implementers to chose whether or not they want to implement tcp-secure. > But some folks felt that since TCP secure has an IPR on it should > probably not have MUST in them at all, another argument was since TCP If the issue is IPR then the WG/IETF could choose to make this RFC not a Standards-Track RFC, but an FYI, and optionally drop the normative RFC2119 language (or make those MUSTs; doesn't matter much to me, if the RFC is to be Informational). It'd be silly to make this a Standards-Track RFC with not a single REQUIRED to implement feature in it -- all implementations of anything, anywhere, could then claim to be compliant. If there was at least one REQUIRED to implement then you could choose to make other encumbered features RECOMMENDED, or OPTIONAL. But no RTI feature at all makes no sense to me. > secure is mostly useful only for long lived connections (like BGP), then > it may not be applicable to hosts and only applicable to routers. I So what? Implementors who don't care for this feature wouldn't be bound to implement it just because this RFC says it's a MUST. Implementors who don't implement it would just not be compliant with this RFC, but nothing says they have to be. > didn't (so as many others) didn't buy this argument, but since it was > not going anywhere Lars stepped up with the suggestion of applicability > statement to be added to this draft (I haven't seen any other TCP > related RFC which has an AS in it, FWIW) and the rest is history. I > seriously doubt whether the chairs/Lars/WG would like to fallback to > MUST/MUST/SHOULD. I'd like to hear from them. > As far as the SYN corner case workaround we chose not to talk about the > fix for the same in the draft since the corner case exists in RFC 793 > and nothing to do with the current SYN mitigation. OK. Maybe this should be stated in the I-D. Nico -- From ananth@cisco.com Sat Aug 15 09:36:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FB03A6BCC; Sat, 15 Aug 2009 09:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d85L88pTGgZk; Sat, 15 Aug 2009 09:36:14 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 135793A6BA4; Sat, 15 Aug 2009 09:36:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+AhkqrR7MV/2dsb2JhbAC4RIgtkEYFhBk X-IronPort-AV: E=Sophos;i="4.43,386,1246838400"; d="scan'208";a="367903882" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Aug 2009 16:36:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7FGaI4m023022; Sat, 15 Aug 2009 09:36:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7FGaIYp011609; Sat, 15 Aug 2009 16:36:18 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 09:36:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Aug 2009 09:36:17 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5807D5548E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20090815004234.GN1043@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] draft-ietf-tcpm-tcpsecure Thread-Index: AcodQsijTDnttxM7QdmLnxlOaaJs0QAgZtfA References: <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> <20090815004234.GN1043@Sun.COM> From: "Anantha Ramaiah (ananth)" To: "Nicolas Williams" X-OriginalArrivalTime: 15 Aug 2009 16:36:18.0802 (UTC) FILETIME=[83F40D20:01CA1DC6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2075; t=1250354178; x=1251218178; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[secdir]=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=uxDvV+6oKeqnFfRxe5KNBNs3QsFdVnp/WIt3DOge7Mw=; b=IKEJUMwqqLum/NMZHXIiPrN7a/P6cGuoH9ocDDxDHyG6LUEv+LdBGKZrty t8QFeqQkrWxEGqZsqJ0mK8BM+EPqQvYuVQN49qx/2X8QL7zr4N+uaP1Mwu5D ZfEx0JYC6EPOIznVtj+HOXisAuG07byZLCz7lrN+dcrn7xXkMycLQ=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: secdir@ietf.org, "Mitesh Dalal \(mdalal\)" , iesg@ietf.org Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 16:36:15 -0000 =20 > >=20 > > secure is mostly useful only for long lived connections (like BGP),=20 > > then it may not be applicable to hosts and only applicable=20 > to routers.=20 > > I >=20 > So what? Implementors who don't care for this feature=20 > wouldn't be bound to implement it just because this RFC says=20 > it's a MUST. Implementors who don't implement it would just=20 > not be compliant with this RFC, but nothing says they have to be. Well, we did argue this point before. >=20 > > didn't (so as many others) didn't buy this argument, but=20 > since it was=20 > > not going anywhere Lars stepped up with the suggestion of=20 > > applicability statement to be added to this draft (I=20 > haven't seen any=20 > > other TCP related RFC which has an AS in it, FWIW) and the rest is=20 > > history. I seriously doubt whether the chairs/Lars/WG would like to=20 > > fallback to MUST/MUST/SHOULD. >=20 > I'd like to hear from them. Sure, but if you can also suggest some text (either in the AS section or in section 6) which can probably make the implementers more comfortable and also can make look the compliance story healhier we can consider adding such a text and take care of this issue. As an FYI, I want to stress that the draft has been around for a long time before reaching last call and I would prefer not to move backwards. That said, if the consensus turns out to be changing the mitigation stengths as per your suggestion, I am fine with that too! >=20 > > As far as the SYN corner case workaround we chose not to talk about=20 > > the fix for the same in the draft since the corner case=20 > exists in RFC=20 > > 793 and nothing to do with the current SYN mitigation. >=20 > OK. Maybe this should be stated in the I-D. The draft already covers it in section 4.2. "This corner case is a result of the [RFC0793] specification and is not introduced by these new requirements." =20 Do you see the need for more clarification?, if so pl feel free to send some text. -Anantha >=20 > Nico > --=20 >=20 From phoffman@imc.org Sat Aug 15 11:50:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD1E3A691B for ; Sat, 15 Aug 2009 11:50:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9TDd9PeJOeD for ; Sat, 15 Aug 2009 11:50:19 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3931A3A6821 for ; Sat, 15 Aug 2009 11:50:18 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7FIoI6s081135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Aug 2009 11:50:20 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 15 Aug 2009 11:50:17 -0700 To: Paul Hoffman , secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Paper on RSA 1024 and ECC X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 18:50:20 -0000 A more stable link to that paper: . FWIW, the paper has already been updated with editorial changes. From lars.eggert@nokia.com Sun Aug 16 00:54:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B985E3A693B for ; Sun, 16 Aug 2009 00:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqgV8+Vp4x+o for ; Sun, 16 Aug 2009 00:54:50 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 4E81C3A6925 for ; Sun, 16 Aug 2009 00:54:50 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n7G7scN7058056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Aug 2009 10:54:38 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <2EC33DD4-D1D8-47C8-9C8C-96A6E7CBB381@nokia.com> From: Lars Eggert To: Anantha Ramaiah (ananth) In-Reply-To: <0C53DCFB700D144284A584F54711EC5807D5548E@xmb-sjc-21c.amer.cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-21--628345202; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 16 Aug 2009 10:54:37 +0300 References: <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> <20090815004234.GN1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D5548E@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.936) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Sun, 16 Aug 2009 10:54:40 +0300 (EEST) Cc: tcpm-chairs@tools.ietf.org, Nicolas Williams , secdir@ietf.org, The IESG , "Mitesh Dalal \(mdalal\)" Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 07:54:50 -0000 --Apple-Mail-21--628345202 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, as Anantha said, the process by which the WG arrived on what's in the current document was slightly painful for all involved. If there are changes proposed, please discuss them on the WG list. Because this specific issue was so controversial, any change here needs to be vetted by the WG consensus process. Lars On 2009-8-15, at 19:36, Anantha Ramaiah (ananth) wrote: > > >> >> >>> secure is mostly useful only for long lived connections (like BGP), >>> then it may not be applicable to hosts and only applicable >> to routers. >>> I >> >> So what? Implementors who don't care for this feature >> wouldn't be bound to implement it just because this RFC says >> it's a MUST. Implementors who don't implement it would just >> not be compliant with this RFC, but nothing says they have to be. > > Well, we did argue this point before. > >> >>> didn't (so as many others) didn't buy this argument, but >> since it was >>> not going anywhere Lars stepped up with the suggestion of >>> applicability statement to be added to this draft (I >> haven't seen any >>> other TCP related RFC which has an AS in it, FWIW) and the rest is >>> history. I seriously doubt whether the chairs/Lars/WG would like to >>> fallback to MUST/MUST/SHOULD. >> >> I'd like to hear from them. > > Sure, but if you can also suggest some text (either in the AS > section or > in section 6) which can probably make the implementers more > comfortable > and also can make look the compliance story healhier we can consider > adding such a text and take care of this issue. As an FYI, I want to > stress that the draft has been around for a long time before reaching > last call and I would prefer not to move backwards. That said, if the > consensus turns out to be changing the mitigation stengths as per your > suggestion, I am fine with that too! > >> >>> As far as the SYN corner case workaround we chose not to talk about >>> the fix for the same in the draft since the corner case >> exists in RFC >>> 793 and nothing to do with the current SYN mitigation. >> >> OK. Maybe this should be stated in the I-D. > > The draft already covers it in section 4.2. "This corner case is a > result of the [RFC0793] specification and is > not introduced by these new requirements." > > Do you see the need for more clarification?, if so pl feel free to > send > some text. > > -Anantha >> >> Nico >> -- >> --Apple-Mail-21--628345202 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MTYwNzU0MzhaMCMGCSqGSIb3DQEJBDEWBBQV/XGRgDaQZk5f zT0jBjedHoP92zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAb6vZwRcfPowO0y003lgF0ZvYUB+g5dAt45KEVtZWT6miDsaz3K9m hhClkBVctkqIjM9CwRz0l5O+5cBjRf8y9H+7CTvYsG60RM3N3ZEoPwj6KlbwgFffF4pgInncDsz7 eIxxGNHDPHaqSQ7keBEkvXoZKjnKxD9BnbVdNFRFxeeU95pwZS2n3qD6H771BaLILh1i9ztswrD5 oB86Atw+1f/FpKaLVercZAkdNoTX8DHl71DsD5HsXj5rz9zppS79xrh0ooxM8fz4713uUuf24KwE TOtSQPfN4fhv1s007J0xecjCsyTQB49MjpoO/mTwDRwQ34sdRh9uxraEEnVyvwAAAAAAAA== --Apple-Mail-21--628345202-- From Nicolas.Williams@sun.com Sun Aug 16 17:00:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5C43A6939; Sun, 16 Aug 2009 17:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLbIUGWVfakm; Sun, 16 Aug 2009 16:59:59 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 4DCEA3A67F9; Sun, 16 Aug 2009 16:59:54 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7GNxxt3001808; Sun, 16 Aug 2009 23:59:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7GNxumQ007774; Sun, 16 Aug 2009 17:59:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7GNfd48002658; Sun, 16 Aug 2009 18:41:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7GNfXtL002657; Sun, 16 Aug 2009 18:41:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 16 Aug 2009 18:41:33 -0500 From: Nicolas Williams To: Lars Eggert , g@sun.com Message-ID: <20090816234133.GO1043@Sun.COM> References: <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> <20090815004234.GN1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D5548E@xmb-sjc-21c.amer.cisco.com> <2EC33DD4-D1D8-47C8-9C8C-96A6E7CBB381@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EC33DD4-D1D8-47C8-9C8C-96A6E7CBB381@nokia.com> User-Agent: Mutt/1.5.7i Cc: tcpm-chairs@tools.ietf.org, secdir@ietf.org, Anantha Ramaiah , The IESG , "Mitesh Dalal \(mdalal\)" Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 00:00:00 -0000 On Sun, Aug 16, 2009 at 10:54:37AM +0300, Lars Eggert wrote: > as Anantha said, the process by which the WG arrived on what's in the > current document was slightly painful for all involved. > > If there are changes proposed, please discuss them on the WG list. > Because this specific issue was so controversial, any change here > needs to be vetted by the WG consensus process. I don't have the energy for that. There are ways to deal with IPR. Is this one of them? I fail to understand what a Standards-Track RFC means that has no required to implement features. Surely the IESG will wonder too. And if not, would that be because the issue has been settled before and we do know what such an RFC "means"? If so, please let me know. From phoffman@imc.org Sun Aug 16 18:36:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5232728C111; Sun, 16 Aug 2009 18:36:52 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8++L7L7P6UB; Sun, 16 Aug 2009 18:36:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4969E3A6833; Sun, 16 Aug 2009 18:36:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7H1aooO061785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 18:36:52 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090815004234.GN1043@Sun.COM> References: <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com> <20090815004234.GN1043@Sun.COM> Date: Sun, 16 Aug 2009 18:36:48 -0700 To: Nicolas Williams From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "Mitesh Dalal \(mdalal\)" , "Anantha Ramaiah \(ananth\)" , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 01:36:52 -0000 At 7:42 PM -0500 8/14/09, Nicolas Williams wrote: >It'd be silly to make this a Standards-Track RFC with not a single >REQUIRED to implement feature in it -- all implementations of anything, >anywhere, could then claim to be compliant. The draft in question normatively relies on the definitions in RFC 2119 and, because it is slated for standards track, RFC 2026. Any implementation of any type of RFC, not just standards track RFCs, can claim whatever it wants. 'Twas ever thus. If you want to update RFC 2026 to deal with the issue of standards track documents with no RFC 2119 MUST statements, that's fine. However, doing so should not affect Internet Drafts while the IETF goes through yet another process on process. From sisyphus@dial.pipex.com Mon Aug 17 04:40:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117183A6ED9; Mon, 17 Aug 2009 04:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_40=-0.185, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b3rzkEFT+CK; Mon, 17 Aug 2009 04:40:55 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 8043728C114; Mon, 17 Aug 2009 04:40:54 -0700 (PDT) X-Trace: 242151276/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.249/None/sisyphus@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.249 X-IP-MAIL-FROM: sisyphus@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAKveiEo+vGT5/2dsb2JhbACDMGKNBsNUCYQQBYIp X-IronPort-AV: E=Sophos;i="4.43,396,1246834800"; d="scan'208";a="242151276" X-IP-Direction: IN Received: from 1cust249.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.249]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Aug 2009 12:40:53 +0100 Message-ID: <002e01ca1f27$0f582160$0601a8c0@allison> From: "Tom.Petch" To: "Stephen Hanna" , , "ietf" , References: <016701ca1bf7$400ac480$0601a8c0@allison> Date: Sun, 16 Aug 2009 10:21:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Mon, 17 Aug 2009 04:41:55 -0700 Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Tom.Petch" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 11:40:59 -0000 Stephen As Dan and Bert think and believe, I guess #1. My experience with other technologies is that where enterprise systems are involved, then authorisation is likely to be powerful and comprehensive (and proprietary) but where network and operators are involved, then this is not so. Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Stephen Hanna" ; "Tom.Petch" ; ; ; Sent: Thursday, August 13, 2009 1:10 PM Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt Steve, I believe that the situation is #1 below. Dan > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; secdir@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-lock@tools.ietf.org > Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt > > Tom, > > Thanks for responding to my comments. Allow me to respond. > > You wrote: > > As a participant in netconf, I see authorization as one of those > > topics which the Working Group sees as necessary but cannot > be tackled > > just yet. As RFC4741 says, " This document does not specify an > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no > authorization, not yet, > > nor, IMHO, for some time to come. > > This is just the sort of background information that a WG > participant would know but that a secdir reviewer would not. > Please allow me to ask a clarifying question. You say that > there is no authorization yet. > I think that could mean several things: > > 1) Existing NETCONF implementations implement authorization, ensuring > that each user gets an appropriate and perhaps different level of > access to the database. However, there are no standards for the > manner in which authorization is performed or configured. > > 2) Existing NETCONF implementations require authentication > but generally > just give complete read-write access to the database to > all authenticated > users. > > 3) Existing NETCONF implementations do not require authentication. > Anyone with network access has complete, unfettered access to > the database and can modify it at will. > > Could you tell me which of these meanings is most accurate? > Of course, it could be a mix of these but I'd like to get > your real-world assessment of the state of the NETCONF world. > If the answer is 3), we have a serious problem! If the answer > is 1) or 2), that's acceptable in my view. > > Now on to the language in the draft. My comment was relating > to this quote from the Security Considerations: > > > "Only an authenticated and authorized user can request a partial > > lock." > > I'm afraid that this statement is not justified if there is > no normative text requiring implementations to comply. I > suggest that normative text be added to at least require > authentication. > With such text, the statement above could be justified. > Requiring that levels of authorization be implemented is less > important in this application. And standardizing the manner > in which authorization is performed or configured (which I > think is your concern with respect to the lack of a data > model) is really not important at all unless NETCONF > customers or vendors decide that it is. Standardizing an > authorization policy format is a tremendously challenging > task for any protocol and often not necessary. > > I hope that this helps you address my comments in a > reasonable and achievable manner. The intent of secdir > comments is not to impose unreasonable requirements. It is to > point out issues that might not be evident to someone who is > not a security expert. > > Thanks, > > Steve > > > -----Original Message----- > > From: Tom.Petch [mailto:sisyphus@dial.pipex.com] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; secdir@ietf.org; ietf@ietf.org; > > draft-ietf-netconf-partial-lock@tools.ietf.org > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > > > ----- Original Message ----- > > From: "Stephen Hanna" > > To: ; ; ; > > > > Sent: Monday, August 10, 2009 4:28 PM > > > > > I have reviewed this document as part of the security > directorate's > > > ongoing effort to review all IETF documents being > processed by the > > > IESG. These comments were written primarily for the > benefit of the > > > security area directors. Document editors and WG chairs > > should treat > > > these comments just like any other last call comments. > > > > > > This document defines optional partial-lock and partial-unlock > > > operations to be added to the NETCONF protocol. These > operations are > > > used to lock only part of a configuration datastore, allowing > > > multiple management sessions to modify the configuration > of a device > > > at a single time. > > > > > > The Security Considerations section of the document > highlights the > > > risk that a malicious party might employ partial locks to impede > > > access to a device's configuration. Therefore, it states "Only an > > > authenticated and authorized user can request a partial lock." > > > Unfortunately, I cannot find any normative text (MUST) > that supports > > > this statement. The NETCONF spec (RFC 4741) says "NETCONF > > > connections must be authenticated" but this is not clearly > > > normative. Perhaps a NETCONF expert can point to some > normative text > > > requiring authentication and authorization for any party > requesting > > > a partial lock. If not, I suggest that such normative > text be added > > > to the partial-lock specification. > > > > > As a participant in netconf, I see authorization as one of those > > topics which the Working Group sees as necessary but cannot > be tackled > > just yet. As RFC4741 says, " This document does not specify an > > authorization scheme, as such a > > scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no > authorization, not yet, > > nor, IMHO, for some time to come. In the light of this, I > am not sure > > what adding a normative statement to this I-D would do; delay > > publication sine die? > > > > Tom Petch > > > > > > > > > > > Another security concern that I have related to the partial-lock > > > operation is that the configuration might become > inconsistent if one > > > manager changes one part of a datastore at the same time that > > > another manager changes another part. The resulting inconsistency > > > could have security implications. For example, an > organization might > > > have a rule that either the firewall or the intrusion detection > > > features must be enabled on a device. If one manager might lock > > > intrusion detection configuration, check that the firewall is > > > enabled, and then disable intrusion detection. Another > manager might > > > lock the firewall configuration, check that intrusion > > detection > > > is enabled, and then disable the firewall. If those > operations were > > > interleaved, they could result in a violation of policy. > > > To address this concern, I suggest that the draft contain > a warning > > > that parallel operations are tricky and should be carefully > > > considered. Sometimes, it may be necessary to lock a > portion of the > > > datastore that will not be modified, just to ensure the datastore > > > remains consistent and compliant with policy. > > > > > > Of course, a human administrator using a GUI could easily > run into > > > this same problem if the human does not have the ability > to control > > > configuration locks. The human might look at the firewall > > > configuration to make sure that it's enabled and then switch to > > > another section of the display to disable the intrusion detection > > > function. If the management console only locks the datastore to > > > execute the administrator's request to disable intrusion > detection, > > > overlapping operations from another administrator could > result in a > > > bad configuration. > > > This problem can arise even without the partial lock operation. > > > Probably the best that can be done here is to include language > > > warning of this sort of problem. Warning human > administrators that > > > someone else is also editing the device should help and > giving these > > > administrators the ability to easily communicate with > each other to > > > coordinate their work would also probably help. > > > > > > Here are a few minor issues: > > > > > > * At the end of section 2.1.1.2, the comma in the last > > > sentence is superfluous. > > > > > > * In section 2.1.1.3 in the sentence "Manager A terminates it's > > > session", the apostrophe should be removed. > > > > > > * In section 2.4.1, I think that the sentence that begins with > > > "If someone later creates a new interface" would be clearer > > > if the second comma was changed to "so". > > > > > > * Later in section 2.4.1, the sentence that begins with > > > "A NETCONF server MUST" should instead start with "A NETCONF > > > server that supports partial locks MUST". I think that > > > paragraph should end with "all of the overlapping locks are > > > released" not "all of the locks are released". From secdir-bounces@mit.edu Mon Aug 17 09:32:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0452E3A6F48 for ; Mon, 17 Aug 2009 09:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K+oM-z8dIYH for ; Mon, 17 Aug 2009 09:32:23 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 48FE528C2DF for ; Mon, 17 Aug 2009 09:31:25 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7HGVR9K005954 for ; Mon, 17 Aug 2009 12:31:27 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7HGVPMK005947 for ; Mon, 17 Aug 2009 12:31:26 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7HGVE9r007015 for ; Mon, 17 Aug 2009 12:31:15 -0400 (EDT) Received: from TX2EHSOBE006.bigfish.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 4D87A22B2473 for ; Mon, 17 Aug 2009 12:31:13 -0400 (EDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by mit.edu with ESMTP id EUQILo4zoEDQGNrZ (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 17 Aug 2009 12:31:13 -0400 (EDT) Received: from mail59-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 8.1.340.0; Mon, 17 Aug 2009 16:31:11 +0000 Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2-R.bigfish.com (Postfix) with ESMTP id 062F2159841B; Mon, 17 Aug 2009 16:31:12 +0000 (UTC) X-SpamScore: -42 X-BigFish: VPS-42(zz1432R98dN936eM10d1Izz1202hzz1033ILz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5, X-FB-DOMAIN-IP-MATCH: fail Received: by mail59-tx2 (MessageSwitch) id 1250526669954437_28980; Mon, 17 Aug 2009 16:31:09 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail59-tx2.bigfish.com (Postfix) with ESMTP id A61AA1B28056; Mon, 17 Aug 2009 16:31:09 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 2674068006; Mon, 17 Aug 2009 17:31:09 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A039C619089; Mon, 17 Aug 2009 17:31:09 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id D659868006; Mon, 17 Aug 2009 17:31:08 +0100 (IST) Message-ID: <4A8985CD.3030001@cs.tcd.ie> Date: Mon, 17 Aug 2009 17:31:09 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Richard Barnes References: <4A83616C.1030506@bbn.com> In-Reply-To: <4A83616C.1030506@bbn.com> X-Enigmail-Version: 0.96.0 X-AntiVirus-Status: MessageID = A139C619089 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.112.7) X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: sec-ads@ietf.org, SECDIR , draft-ietf-pkix-other-certs@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-pkix-other-certs-04 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:32:24 -0000 Thanks Richard, I'll roll changes for those comments into a rev of the document whenever the AD says to do so. Cheers, S. Richard Barnes wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This documents creates a certificate extension that allows the issuer of > a certificate to assert that the subject of the certificate is the same > as that of a set of other certificates (i.e., that the same entity holds > all the corresponding private keys). This extension clearly creates > some impersonation risks, but the document provides sufficient advice to > CAs to mitigate these risks. > > Overall, I think the document is basically ready for publication. Some > comments, mostly editorial, follow below. > > --Richard > > > ----- > Section 1, Paragraph 2 > s/assoicate/associate/ > > Section 1, Paragraph 3 > To be clear here and decouple this paragraph from the last, I would > replace the phrase "... supports such linkage" to something like "... > allows a certificate issuer to attest that the end entity that holds the > private key for the certificate in question also holds other private > keys corresponding to other certificates." This change also clarifies > why you refer to "end entities" below instead of just "subjects". > > Section 2, Paragraph 3 > Change "... change CA when renewing its certificate" to "... change CA > when replacing its certificate". Renewal only happens with the same CA. > > Section 3, ASN.1 fragment > Change "::==" to "::=". > > Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para) > The first sentence in this paragraph seems very vague -- what does it > mean for a use of this extension to be "safe"? Suggest replacing with a > requirement that is notably absent from this paragraph, namely that "CAs > MUST issue a certificate containing this extension only after they have > validated that the holder of the private key for the certificate also > holds the private keys for linked certificates." > > Section 3, Paragraph 6 (same as above) > Do you mean to have both requirements in the final sentence as "SHOULD > NOT"? It might be helpful here to note how the "purpose" a certificate > might be determined, e.g., via CP or EKU OIDs. > > Setion 3, Paragraph 10 > The validation procedure in RFC 5280 requires an RP to verify that a > certificate has not been revoked (Section 6.1.3, step (a)(3)), so the > initial conditional can be omitted. This requirement is really > important for this extension, since one reason that certificates get > revoked is private key compromise, in which case a party other than the > intended subject has possession of the private key (by definition). This > situation would allow the attacker to obtain linked certificates even > from a CA that complies with this document. > > Section 3, Paragraph 12 > It would be helpful to clarify why this restriction is in place, e.g., > "Since CA certificates are only used for certificate validation, and > this extension has no effect on the validation procedure, this extension > is meaningless for CA certificates." > > Section 5 > It's not clear that this section belongs in this document. It would not > reduce the clarity of the document to remove it. > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From Fred.L.Templin@boeing.com Mon Aug 17 10:35:17 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A63B3A6D39; Mon, 17 Aug 2009 10:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsXAopEIIv3R; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 712353A6B87; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7HHZAt2001095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7HHZAB3016048; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7HHZ8XE015894; Mon, 17 Aug 2009 10:35:10 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 10:35:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1F61.10FEDC58" Date: Mon, 17 Aug 2009 10:35:08 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcofTmXEPOk1UYNFRUS+bwV+J7jmOAADteKg References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 17 Aug 2009 17:35:10.0344 (UTC) FILETIME=[11BE1880:01CA1F61] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:35:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1F61.10FEDC58 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Gabi, =20 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =20 > 6.2. ISATAP Interface Address Configuration >=20 > Each ISATAP interface configures a set of locators consisting of IPv4 > address-to-interface mappings from a single site; i.e., an ISATAP > interface's locator set MUST NOT span multiple sites. =20 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global Internet itself as site #2. If the ISATAP interface is to be used as an enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =20 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =20 Fred fred.l.templin@boeing.com =20 ________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =20 Hi all, I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently published. The research presents a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =20 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit vulnerabilities in these tunnels. These attacks take advantage of inconsistencies between a tunnel's overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. We exhibit five attacks of this class. One of the presented attacks can DoS a Teredo server using a single packet. The exploited vulnerabilities are embedded in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 R2.=20 =20 I think the results of the research warrant some corrective action. If this indeed shall be the general sentiment of the list, I will be happy write an appropriate I-D. The mitigation measures we suggested in the paper are the best we could think of to completely eliminate the problem. However they are far from perfect since they would require tunnel implementations to be updated in case new types of automatic tunnels are introduced. =20 Your comments are welcome. =20 Gabi =20 ------_=_NextPart_001_01CA1F61.10FEDC58 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Gabi,

 

Thanks for publishing this work. In = the document, attacks A, B and C

correspond to a configuration that violates section 6.2 of RFC5214:

 

> 6.2.  ISATAP Interface = Address Configuration

> 

>   Each ISATAP = interface configures a set of locators consisting of IPv4

>   = address-to-interface mappings from a single site; i.e., an ISATAP

>   interface's = locator set MUST NOT span multiple sites.

 

In particular, in scenarios A, B = and C the IPv4 locator used for ISATAP

is seen both within the enterprise = as site #1 and within the global Internet

itself as site #2. If the ISATAP = interface is to be used as an enterprise-

interior interface, it should = therefore not accept IP-proto-41 packets

coming from an IPv4 source outside = of the enterprise nor source

IP-proto-41 packets that are = destined to an IPv4 node outside of the

enterprise. This condition should = be satisfied by having the site border

routers implement IPv4 ingress = filtering and ip-protocol-41 filtering as

required in Section 10 of = RFC5214.

 

It is mentioned that attack C could = also occur when the routers reside

in the same site, where their = addresses may be private. This would

correspond to a case in which an = attacker within the site attacks the

site itself, which can easily be = traced – especially when source address

spoofing from a node within the = site is prevented through proper ingress

filtering.

 

Fred

fred.l.templin@boeing.com

 

From: Gabi = Nakibly [mailto:gnakibly@yahoo.com]
Sent: Monday, August 17, = 2009 8:21 AM
To: v6ops
Cc: ipv6@ietf.org; = secdir@ietf.org
Subject: Routing loop = attacks using IPv6 tunnels

 

Hi all,

I would like to draw the attention of the list to some research results which my colleague and I at the National EW Research & Simulation Center have recently = published. The research presents a class of routing loop attacks that abuses = 6to4, ISATAP and Teredo. The paper can be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

 

Here is the abstract:

IPv6 is the future network layer protocol for the = Internet. Since it is not compatible with its predecessor, some interoperability mechanisms were designed. An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 network = without prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these tunnels. = These attacks take advantage of inconsistencies between a tunnel's overlay = IPv6 routing state and the native IPv6 routing state. The attacks form = routing loops which can be abused as a vehicle for traffic amplification to facilitate = DoS attacks. We exhibit five attacks of this class. One of the presented = attacks can DoS a Teredo server using a single packet. The exploited = vulnerabilities are embedded in the design of the tunnels; hence any implementation of = these tunnels may be vulnerable. In particular, the attacks were tested = against the ISATAP, 6to4 and Teredo implementations of Windows Vista and Windows = Server 2008 R2.

 

I think the results of the research warrant some = corrective action. If this indeed shall be the general sentiment of the list, = I will be happy write an appropriate I-D. The mitigation measures we suggested = in the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since they would = require tunnel implementations to be updated in case new types of automatic tunnels are introduced.

 

Your comments are welcome.

 

Gabi

 

------_=_NextPart_001_01CA1F61.10FEDC58-- From gnakibly@yahoo.com Mon Aug 17 08:22:13 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD16628C173 for ; Mon, 17 Aug 2009 08:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1ucoOYP1Alh for ; Mon, 17 Aug 2009 08:22:13 -0700 (PDT) Received: from n68.bullet.mail.sp1.yahoo.com (n68.bullet.mail.sp1.yahoo.com [98.136.44.44]) by core3.amsl.com (Postfix) with SMTP id B87B43A6E76 for ; Mon, 17 Aug 2009 08:22:13 -0700 (PDT) Received: from [216.252.122.216] by n68.bullet.mail.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 Received: from [69.147.84.114] by t1.bullet.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 Received: from [127.0.0.1] by omp203.mail.sp1.yahoo.com with NNFMP; 17 Aug 2009 15:21:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 24248.29488.bm@omp203.mail.sp1.yahoo.com Received: (qmail 83234 invoked by uid 60001); 17 Aug 2009 15:21:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250522472; bh=aFwhQp/2YAUeE6RiHthyLsD9Qv4v2E0QoYy/7DH9Ib8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gklmzotnVChiwl3Avgw8BzwkZAi6REZ1273X2UzmCtoma7r9qA9/Iix5BaWWUNQTd5zyEOX1KIENjj122uGMZQUaIK1s7iW5aGwBOXMltGSkrevmvGb6yDcNJI+AdGjwHO6aZwbpDkM1Pj90wJIMswHUEDtn/2YWuxthWAvnSiQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=acJr3zedFbpo32lqoBllfc9pYrM2Y33MYC69MS/r4l9zAXuA5XgtZOG2Hhu91gBOsU83E5ak6A4Ik7+ZGUxv62/NGuyCGSMnhMedgl6o7u6lR87MTfmDhXGlty1FVZjmVVNwDBPwuUn3wZ4teSh+mYM9VXSLEosgTn/KlmzRyA8=; Message-ID: <789539.81531.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: wbhj3XYVM1nend3JxUs6Y_qC4.6wg5WEdsq8eavbVZlCDQ340jP0xBjqiV94KT4mqH88BsCMCdwa6fJ3oBQlfI4ZM4fh40oun5y847yvqbPiZvfKmcmZ97tjcpSA38DfSSGLTVRsvNMeQlz0Y6ORZ5gu5OFFp9y0cpFJ_LsWuJGMOzYCscUtWl1bMLCfaDmK0.ytUXXf1HW5qD9u09HZ98tkwQ00GqwvztM6Ri9KMRiaOYHKwTiBaMBdKUzfYZM4_EoYZOyVxEIphgwpBIk2ZvB5DT2g8EFmXAikYm0lMu.HtZuh4.fV Received: from [89.138.113.91] by web45502.mail.sp1.yahoo.com via HTTP; Mon, 17 Aug 2009 08:21:12 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Mon, 17 Aug 2009 08:21:12 -0700 (PDT) From: Gabi Nakibly To: v6ops MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-619404899-1250522472=:81531" X-Mailman-Approved-At: Mon, 17 Aug 2009 23:31:52 -0700 Cc: ipv6@ietf.org, secdir@ietf.org Subject: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:22:13 -0000 --0-619404899-1250522472=:81531 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,=0AI would like to draw the attention of the list to=A0some=A0resear= ch=A0results which my colleague and I at the National EW Research=A0& Simul= ation=A0Center have recently published. The research presents a=A0class of = routing loop attacks that abuses 6to4, ISATAP and Teredo. The=A0paper can b= e found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pd= f=0A=0AHere is the abstract:=0AIPv6 is the future network layer protocol fo= r the Internet. Since it is not compatible with its predecessor, some inter= operability mechanisms were designed. An important category of these mechan= isms is automatic tunnels, which enable IPv6 communication over an IPv4 net= work without prior configuration. This category includes ISATAP, 6to4 and T= eredo. We present a novel class of attacks that exploit vulnerabilities in = these tunnels. These attacks take advantage of inconsistencies between a tu= nnel's overlay IPv6 routing state and the native IPv6 routing state. The at= tacks form routing loops which can be abused as a vehicle for traffic ampli= fication to facilitate DoS attacks. We exhibit five attacks of this class. = One of the presented attacks can DoS a Teredo server using a single packet.= The exploited vulnerabilities are embedded in the design of the tunnels; h= ence any implementation of these tunnels may be vulnerable. In particular, = the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=0AI think the results of the research warrant so= me corrective action. If this=A0indeed shall be the general sentiment of th= e list, I will be happy write an appropriate I-D. The mitigation measures w= e suggested in the paper are the best we could think of to completely elimi= nate the problem. However they are far from perfect since=A0they would requ= ire=A0tunnel implementations to be updated in case new types of automatic t= unnels are introduced.=0A=0AYour comments are welcome.=0A=0AGabi=0A=0A=0A = --0-619404899-1250522472=:81531 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=0A
I would like to draw the attention of the li= st to some research results which my colleague and I at the = National EW Research & Simulation Center have recently publis= hed. The research presents a class of routing loop attacks that abuses= 6to4, ISATAP and Teredo. The paper can be found at: http://www.usen= ix.org/events/woot09/tech/full_papers/nakibly.pdf
=0A
 =0A
Here is the abstract:
=0A
IPv6 is the future network layer protocol for the Internet.= Since it is not compatible with its predecessor, some interoperability mec= hanisms were designed. An important category of these mechanisms is automat= ic tunnels, which enable IPv6 communication over an IPv4 network without pr= ior configuration. This category includes ISATAP, 6to4 and Teredo. We prese= nt a novel class of attacks that exploit vulnerabilities in these tunnels. = These attacks take advantage of inconsistencies between a tunnel's overlay = IPv6 routing state and the native IPv6 routing state. The attacks form rout= ing loops which can be abused as a vehicle for traffic amplification to fac= ilitate DoS attacks. We exhibit five attacks of this class. One of the pres= ented attacks can DoS a Teredo server using a single packet. The exploited = vulnerabilities are embedded in the design of the tunnels; hence any implem= entation of these tunnels may be vulnerable. In particular, the attacks were tested against the ISATAP, 6to= 4 and Teredo implementations of Windows Vista and Windows Server 2008 R2. <= /FONT>
=0A
 
=0A
I think the results of the research= warrant some corrective action. If this indeed shall be the general s= entiment of the list, I will be happy write an appropriate I-D. The mitigat= ion measures we suggested in the paper are the best we could think of to co= mpletely eliminate the problem. However they are far from perfect since&nbs= p;they would require tunnel implementations to be updated in case new = types of automatic tunnels are introduced.
=0A
 
=0AYour comments are welcome.
=0A
 
=0A
Gabi

=0A=0A --0-619404899-1250522472=:81531-- From remi@remlab.net Mon Aug 17 09:54:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2911828C191; Mon, 17 Aug 2009 09:54:48 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQzYNEUYqOko; Mon, 17 Aug 2009 09:54:47 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id A729528C2B8; Mon, 17 Aug 2009 09:54:06 -0700 (PDT) Received: from basile.remlab.net (cs27060099.pp.htv.fi [89.27.60.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 07D462D4; Mon, 17 Aug 2009 18:54:09 +0200 (CEST) From: "=?iso-8859-15?q?R=E9mi?= Denis-Courmont" Organization: Remlab.net To: Gabi Nakibly Date: Mon, 17 Aug 2009 19:54:06 +0300 User-Agent: KMail/1.12.0 (Linux/2.6.30.4; KDE/4.3.0; i686; ; ) References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <200908171954.07106.remi@remlab.net> X-Mailman-Approved-At: Mon, 17 Aug 2009 23:31:52 -0700 Cc: v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:54:48 -0000 Le lundi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit : > Hi all, > I would like to draw the attention of the list to some research results > which my colleague and I at the National EW Research & Simulation Center > have recently published. The research presents a class of routing loop > attacks that abuses 6to4, ISATAP and Teredo. The paper can be found at: > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf Attack E has been known for at least 2 years, though I do not have a Micros= oft=20 implementation to verify: http://www.remlab.net/miredo/mtfl-sa-0603.shtml.en Note that it *does* affect Linux-based in the sense that a non-privileged=20 local user could screw up (an unlikely scenario on a Teredo server, anyway). I'm now trying to verify attack D. =2D-=20 R=E9mi Denis-Courmont http://www.remlab.net/ From gnakibly@yahoo.com Tue Aug 18 02:33:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712873A6DE3 for ; Tue, 18 Aug 2009 02:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElKocG8sa5jR for ; Tue, 18 Aug 2009 02:33:23 -0700 (PDT) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id 4AF3E3A6DF2 for ; Tue, 18 Aug 2009 02:33:23 -0700 (PDT) Received: from [216.252.122.217] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:59 -0000 Received: from [69.147.84.88] by t2.bullet.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:58 -0000 Received: from [127.0.0.1] by omp204.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 09:29:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 896605.44181.bm@omp204.mail.sp1.yahoo.com Received: (qmail 63969 invoked by uid 60001); 18 Aug 2009 09:29:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250587798; bh=Xog9xZ5c5UeuLK5xjiGcY3IlKftxHwVbSeOxGNAv/e4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kMCSK5bHviRPpp7J0s2MRCI2a6c8+1+Qr2txf9ORTR4zR+zDWE50Nam/HCsdY3kq5BC2AmtjZXX0GyRvW75oqlcolG29bfb/GZkhmR5y4w8U/7CieXq1+6xrEnEF9V1ihZAFJGwhw5XIlEtPQQS5WUKgLvtwjolSDGz/lhYq3co= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ye8fVTICRwVLgrpcxbItMxp4a9qB+0evHYmayEke/eZFKxCnNM98uLga1qUpxr+YLlps5tj3niEV6NGtcQOjIDMSxnPtommJlqJOfm2ic4PUSPvEX1b0WlFX/UpboPM2yQZSzgZkgN9838baYPsu1Cg7XEh/1cbWcx5aqdStZwA=; Message-ID: <726098.63579.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: PuL04akVM1nrwaa8C1Zdq8RfdVDvtbNk50H_YjqX7uR.fHDa7HcfS3XJBZ95VzonvXg_vy8iPV3Dpz4O_HSfC_nPoco58MX1TNmhzqOyEaAQm3sNNvLUWaqYiJ_GxqWNWGodWVxPFpXRCypVj.lSPxApZnrJ5xYZoRlaBXMt0HWb2MKMLLZVbHESuO3VO9cJglkCx1e_XRdte6qSxW_m3BTO2L1W9JY7L2vJNyiDBzXMvBhCDNzdf07mfFferaz4DWu99t53xHeLuPVIiuMGcFqrtUTMOZV47Ub4NZN0ZKG9zkS3GL0- Received: from [89.138.113.91] by web45508.mail.sp1.yahoo.com via HTTP; Tue, 18 Aug 2009 02:29:58 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> Date: Tue, 18 Aug 2009 02:29:58 -0700 (PDT) From: Gabi Nakibly To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200908171954.07106.remi@remlab.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1408785047-1250587798=:63579" X-Mailman-Approved-At: Tue, 18 Aug 2009 02:42:02 -0700 Cc: v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 09:33:24 -0000 --0-1408785047-1250587798=:63579 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Indeed, the vulnerability of attack 5 was noted and fixed in Miredo. Howeve= r, I am not aware of any updates=A0to the Teredo specification to mitigate = it. This means that new implementations will=A0always be vulnerable as in t= he case of Windows Server 2008 R2. This vulnerability was reported to Micro= soft a few months ago. They have reproduced it on their end. A fix should b= e released in the next RC.=0AI did not realize that the attack can be succe= ssful also on Linux. Thanks for the correction.=0A=0APlease let me know the= results of your check on attack #4. If you wish, I can send you (off-list)= =A0the details of my setup for this attack. By the way, I encourage other p= eople on the list to verify the attacks in different scenarios.=0A=0AGabi= =0A=0A=A0=0A=0A________________________________=0AFrom: R=E9mi Denis-Courmo= nt =0ATo: Gabi Nakibly =0ACc: v6ops ; secdir@ietf.org; ipv6@ietf.org=0ASent: Monday, August 1= 7, 2009 7:54:06 PM=0ASubject: Re: Routing loop attacks using IPv6 tunnels= =0A=0ALe lundi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit :=0A= > Hi all,=0A> I would like to draw the attention of the list to some resear= ch results=0A> which my colleague and I at the National EW Research & Simul= ation Center=0A> have recently published. The research presents a class of = routing loop=0A> attacks that abuses 6to4, ISATAP and Teredo. The paper can= be found at:=0A> http://www.usenix.org/events/woot09/tech/full_papers/naki= bly.pdf=0A=0AAttack E has been known for at least 2 years, though I do not = have a Microsoft =0Aimplementation to verify: http://www.remlab.net/miredo/= mtfl-sa-0603.shtml.en=0A=0ANote that it *does* affect Linux-based in the se= nse that a non-privileged =0Alocal user could screw up (an unlikely scenari= o on a Teredo server, anyway).=0A=0A=0AI'm now trying to verify attack D.= =0A=0A=0A-- =0AR=E9mi Denis-Courmont=0Ahttp://www.remlab.net/=0A=0A=0A=0A = --0-1408785047-1250587798=:63579 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Indeed, the vulnerability of attack 5 was noted and fixed in Mire= do. However, I am not aware of any updates to the Teredo specification= to mitigate it. This means that new implementations will always be vu= lnerable as in the case of Windows Server 2008 R2. This vulnerability was r= eported to Microsoft a few months ago. They have reproduced it on their end= .. A fix should be released in the next RC.
=0A
I did not realize t= hat the attack can be successful also on Linux. Thanks for the correction.<= /DIV>=0A
 
=0A
Please let me know the results of your che= ck on attack #4. If you wish, I can send you (off-list) the details of= my setup for this attack. By the way, I encourage other people on the list= to verify the attacks in different scenarios.
=0A
 
=0A
Gabi=0A

 
=0A
=0A
=0A<= SPAN style=3D"FONT-WEIGHT: bold">From: R=E9mi Denis-Courmont <= ;remi@remlab.net>
To:= Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org>; secdir@ietf.org; ipv= 6@ietf.org
Sent: Monday,= August 17, 2009 7:54:06 PM
Subject= : Re: Routing loop attacks using IPv6 tunnels

Le l= undi 17 ao=FBt 2009 18:21:12 Gabi Nakibly, vous avez =E9crit :
> Hi a= ll,
> I would like to draw the attention of the list to some research= results
> which my colleague and I at the National EW Research &= Simulation Center
> have recently published. The research presents a= class of routing loop
> attacks that abuses 6to4, ISATAP and Teredo.= The paper can be found at:
> http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf

At= tack E has been known for at least 2 years, though I do not have a Microsof= t
implementation to verify: http://www.remlab.net/miredo/mtfl-sa-0603.s= html.en

Note that it *does* affect Linux-based in the sense that a n= on-privileged
local user could screw up (an unlikely scenario on a Tere= do server, anyway).


I'm now trying to verify attack D.

--
R=E9mi Denis-Courmont
http://www.remlab.net/
=0A=0A=0A=0A --0-1408785047-1250587798=:63579-- From gnakibly@yahoo.com Tue Aug 18 03:31:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCD328C0F2 for ; Tue, 18 Aug 2009 03:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3MxM1wJnWa2 for ; Tue, 18 Aug 2009 03:31:58 -0700 (PDT) Received: from n72.bullet.mail.sp1.yahoo.com (n72.bullet.mail.sp1.yahoo.com [98.136.44.34]) by core3.amsl.com (Postfix) with SMTP id F18A83A69A4 for ; Tue, 18 Aug 2009 03:31:57 -0700 (PDT) Received: from [69.147.84.144] by n72.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 Received: from [69.147.84.34] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 Received: from [127.0.0.1] by omp210.mail.sp1.yahoo.com with NNFMP; 18 Aug 2009 10:29:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 213279.79398.bm@omp210.mail.sp1.yahoo.com Received: (qmail 44992 invoked by uid 60001); 18 Aug 2009 10:29:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250591367; bh=FhrggRYJfMQPyzw933PNcehrE2GcrLL8yvQV75aq6fg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c2ncJKmi+IvpWWl+/0XblUJqFhD6Kke//EwQzKZArrfAqZywwQJLvsNjpwaQhQdyhCsoFVdm2LgeUwh7mjh+Wam7rMtf7nhvav4QKK3KAoGQ6TRzFBACG9GrBkGzOU6sxThFQhqp/iKfXQqV0xUHAbz0LeLIsKwl9kz9Bk0XY6c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0yD4r7gEQf6M8btJ0pELKZSFEbB7/rWoTdyfD8evzVfk2ObDgD6/8DiazZEjr5Q8opQbrB7XIRtsQo/Aj3hHt+Qecf9cQ/3mBAMLyq8MFAp48bLMSVNrRvIvDdVtX/EhPcXSHKLBZ4UFsJ4pk5NXZr3prVNah+jtY1QcNa/cpsQ=; Message-ID: <2705.42043.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: VBI9GEkVM1llUTTNFOz1BkkiBeoEYErNwFMrfpoXtT.d3KOzB_djLgS3 Received: from [89.138.113.91] by web45502.mail.sp1.yahoo.com via HTTP; Tue, 18 Aug 2009 03:29:26 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> Date: Tue, 18 Aug 2009 03:29:26 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1918408619-1250591366=:42043" Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 10:31:59 -0000 --0-1918408619-1250591366=:42043 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Indeed the ISATAP interface of the ISATAP router is meant to be an enterpri= se-interior (note that=C2=A0it is still=C2=A0assumed that the associated IP= v4 address is=C2=A0non-private). As=C2=A0we explicitly note in the paper, t= he first three attacks=C2=A0will be mitigated=C2=A0if proper protocol-41 fi= ltering is deployed on the site's border. However, note that RFC5214 does n= ot mandate or require this filtering. It is only mentioned as a possible mi= tigation against incoming spurious protocol-41 packets. In addition, Sectio= n 10 of RFC5214 only mentions=C2=A0ingress not=C2=A0egress filtering.=C2=A0= Hence it=C2=A0will not stop attack #2.=C2=A0=0AIn addition, as mentioned, p= rotocol-41 filtering is not helpful when attack #3 is launched on two route= rs that reside in the same site. Note that=C2=A0it=C2=A0may be=C2=A0possibl= e for=C2=A0the attack packet=C2=A0to be sourced from outside the site unles= s proper filtering of incoming IPv6 packets is deployed. If the attacker re= sides in the site, usually ingress filtering will not be helpful since it i= s deployed in general on the site's border.=0A=0AIn general, I would like t= o point out that indeed as in most other attacks these attacks may also be = mitigated by proper firewall rules. However, I do not believe that this=C2= =A0should be our only answer against these attacks. I believe that since th= ese attacks are made possible due to the inherent characteristics of the tu= nnels they=C2=A0should be stopped intrinsically as much as possible by the = tunnel participants and not relay on outside filtering rules.=0A=0AGabi=0A= =0A=0A________________________________=0AFrom: "Templin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Monday, August 17, = 2009 8:35:08 PM=0ASubject: RE: Routing loop attacks using IPv6 tunnels=0A= =0A=0AGabi,=0A=C2=A0=0AThanks for publishing this work. In the document, at= tacks A, B and C=0Acorrespond to a configuration that violates section 6.2 = of RFC5214:=0A=C2=A0=0A> 6.2.=C2=A0 ISATAP Interface Address Configuration= =0A>=C2=A0=0A> =C2=A0=C2=A0Each ISATAP interface configures a set of locato= rs consisting of IPv4=0A>=C2=A0=C2=A0 address-to-interface mappings from a = single site; i.e., an ISATAP=0A>=C2=A0=C2=A0 interface's locator set MUST N= OT span multiple sites.=0A=C2=A0=0AIn particular, in scenarios A, B and C t= he IPv4 locator used for ISATAP=0Ais seen both within the enterprise as sit= e #1 and within the global Internet=0Aitself as site #2. If the ISATAP inte= rface is to be used as an enterprise-=0Ainterior interface, it should there= fore not accept IP-proto-41 packets=0Acoming from an IPv4 source outside of= the enterprise nor source=0AIP-proto-41 packets that are destined to an IP= v4 node outside of the=0Aenterprise. This condition should be satisfied by = having the site border=0Arouters implement IPv4 ingress filtering and ip-pr= otocol-41 filtering as=0Arequired in Section 10 of RFC5214.=0A=C2=A0=0AIt i= s mentioned that attack C could also occur when the routers reside=0Ain the= same site, where their addresses may be private. This would=0Acorrespond t= o a case in which an attacker within the site attacks the=0Asite itself, wh= ich can easily be traced =E2=80=93 especially when source address=0Aspoofin= g from a node within the site is prevented through proper ingress=0Afilteri= ng.=0A=C2=A0=0AFred=0Afred.l.templin@boeing.com=0A=C2=A0=0A=0A_____________= ___________________=0A=0AFrom:Gabi Nakibly [mailto:gnakibly@yahoo.com] =0AS= ent: Monday, August 17, 2009 8:21 AM=0ATo: v6ops=0ACc: ipv6@ietf.org; secdi= r@ietf.org=0ASubject: Routing loop attacks using IPv6 tunnels=0A=C2=A0=0AHi= all,=0AI would like to draw the attention of the list to=C2=A0some=C2=A0re= search=C2=A0results which my colleague and I at the National EW Research=C2= =A0& Simulation=C2=A0Center have recently published. The research presents = a=C2=A0class of routing loop attacks that abuses 6to4, ISATAP and Teredo. T= he=C2=A0paper can be found at: http://www.usenix.org/events/woot09/tech/ful= l_papers/nakibly.pdf=0A=C2=A0=0AHere is the abstract:=0AIPv6 is the future = network layer protocol for the Internet. Since it is not compatible with it= s predecessor, some interoperability mechanisms were designed. An important= category of these mechanisms is automatic tunnels, which enable IPv6 commu= nication over an IPv4 network without prior configuration. This category in= cludes ISATAP, 6to4 and Teredo. We present a novel class of attacks that ex= ploit vulnerabilities in these tunnels. These attacks take advantage of inc= onsistencies between a tunnel's overlay IPv6 routing state and the native I= Pv6 routing state. The attacks form routing loops which can be abused as a = vehicle for traffic amplification to facilitate DoS attacks. We exhibit fiv= e attacks of this class. One of the presented attacks can DoS a Teredo serv= er using a single packet. The exploited vulnerabilities are embedded in the= design of the tunnels; hence any implementation of these tunnels may be vu= lnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=C2=A0=0AI think the results of the research warr= ant some corrective action. If this=C2=A0indeed shall be the general sentim= ent of the list, I will be happy write an appropriate I-D. The mitigation m= easures we suggested in the paper are the best we could think of to complet= ely eliminate the problem. However they are far from perfect since=C2=A0the= y would require=C2=A0tunnel implementations to be updated in case new types= of automatic tunnels are introduced.=0A=C2=A0=0AYour comments are welcome.= =0A=C2=A0=0AGabi=0A=0A=0A --0-1918408619-1250591366=:42043 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Indeed the ISATAP interface of the ISATAP router is meant to be a= n enterprise-interior (note that it is still assumed that the ass= ociated IPv4 address is non-private). As we explicitly note in th= e paper, the first three attacks will be mitigated if proper prot= ocol-41 filtering is deployed on the site's border. However, note that RFC5= 214 does not mandate or require this filtering. It is only mentioned as a p= ossible mitigation against incoming spurious protocol-41 packets. In additi= on, Section 10 of RFC5214 only mentions ingress not egress filter= ing. Hence it will not stop attack #2. 
=0A
In addition= , as mentioned, protocol-41 filtering is not helpful when attack #3 is laun= ched on two routers that reside in the same site. Note that it ma= y be possible for the attack packet to be sourced from outsi= de the site unless proper filtering of incoming IPv6 packets is deployed. I= f the attacker resides in the site, usually ingress filtering will not be h= elpful since it is deployed in general on the site's border.
=0A
 <= /DIV>=0A
In general, I would like to point out that indeed as in most other a= ttacks these attacks may also be mitigated by proper firewall rules. Howeve= r, I do not believe that this should be our only answer against these = attacks. I believe that since these attacks are made possible due to the in= herent characteristics of the tunnels they should be stopped intrinsic= ally as much as possible by the tunnel participants and not relay on outsid= e filtering rules.
=0A
 
=0A
Gabi
=0A
 
=0A
=0A
=0A
=0AFrom: "Templin, Fred L" <Fred.L.Templin@boeing.= com>
To: Gabi Nakibly= <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>
Cc: ipv6@ietf.org; secdir@ietf.orgSent: Monday, August 17, 2= 009 8:35:08 PM
Subject: = RE: Routing loop attacks using IPv6 tunnels

=0A=0A=0A=0A
=0A

Gabi,

=0A

 

=0A

Thanks for publishing this work. In the document, a= ttacks A, B and C

=0A

correspond to a configuration that violates section 6.2 of R= FC5214:

=0A

 

=0A

> 6.2.  ISATAP Interface Address Configuration

=0A

> 

=0A

> &= nbsp; Each ISATAP interface configures a set of locators consisting of= IPv4

=0A

>   address-to-interface mappings from a single site; i.e.,= an ISATAP

=0A

>   interface's locator set MUST NOT span multiple sit= es.

=0A

 

=0A

In particular, in scenarios A, B and C the IPv4 locator used for ISATA= P

=0A

i= s seen both within the enterprise as site #1 and within the global Internet=

=0A

i= tself as site #2. If the ISATAP interface is to be used as an enterprise-

=0A

inte= rior interface, it should therefore not accept IP-proto-41 packets

=0A

<= SPAN style=3D"FONT-FAMILY: Arial; COLOR: navy; FONT-SIZE: 10pt">coming from= an IPv4 source outside of the enterprise nor source

=0AIP-proto-41 packets that = are destined to an IPv4 node outside of the

=0A

enterprise. This condition should = be satisfied by having the site border

=0A

routers implement IPv4 ingress filterin= g and ip-protocol-41 filtering as

=0A

= required in Section 10 of RFC5214.

=0A

 

=0A

It is me= ntioned that attack C could also occur when the routers reside

=0A

in the same sit= e, where their addresses may be private. This would

=0A

correspond to a case in wh= ich an attacker within the site attacks the

=0A

site itself, which can easily be t= raced =E2=80=93 especially when source address

=0A

spoofing from a node within the= site is prevented through proper ingress

=0A

filtering.

=0A

 

=0A<= P class=3DMsoNormal>Fred

= =0A

fred.l.templin@boein= g.com

=0A

 

=0A
=0A
=0A
=0A
=0A
=0A

From:<= /SPAN> Gabi Nakibly [mailto:gnakibly@yahoo.com]
Sent: Monday, August 17, 2009 8:= 21 AM
To: v6ops
Cc: ipv6@ietf.org; secdir@ietf.o= rg
Subject: Routing loop= attacks using IPv6 tunnels

=0A

= &nb= sp;

=0A
=0A
=0A

Hi all,

=0A
=0A

I would like t= o draw the attention of the list to some research results wh= ich my colleague and I at the National EW Research & Simulation&nb= sp;Center have recently published. The research presents a class of ro= uting loop attacks that abuses 6to4, ISATAP and Teredo. The paper can = be found at: http://www.usenix.org/events/woot09/tech/full_papers/nakibly.p= df

=0A
=0A

 

=0A
=0A

Here is the abstract= :

=0A
=0A

IPv6 is the f= uture network layer protocol for the Internet. Since it is not compatible w= ith its predecessor, some interoperability mechanisms were designed. An imp= ortant category of these mechanisms is automatic tunnels, which enable IPv6= communication over an IPv4 network without prior configuration. This categ= ory includes ISATAP, 6to4 and Teredo. We present a novel class of attacks t= hat exploit vulnerabilities in these tunnels. These attacks take advantage = of inconsistencies between a tunnel's overlay IPv6 routing state and the na= tive IPv6 routing state. The attacks form routing loops which can be abused= as a vehicle for traffic amplification to facilitate DoS attacks. We exhib= it five attacks of this class. One of the presented attacks can DoS a Tered= o server using a single packet. The exploited vulnerabilities are embedded = in the design of the tunnels; hence any implementation of these tunnels may be vulnerable. In particular, the = attacks were tested against the ISATAP, 6to4 and Teredo implementations of = Windows Vista and Windows Server 2008 R2.

=0A
= =0A

 

=0A
=0A

I think the results of the research warrant some corre= ctive action. If this indeed shall be the general sentiment of the lis= t, I will be happy write an appropriate I-D. The mitigation measures we sug= gested in the paper are the best we could think of to completely eliminate = the problem. However they are far from perfect since they would requir= e tunnel implementations to be updated in case new types of automatic = tunnels are introduced.

=0A
=0A

 

=0A
=0A

Your comments are welcome.

=0A
=0A

 

=0A
=0A

= Gabi

=0A

 =

=0A

=0A=0A --0-1918408619-1250591366=:42043-- From remi@remlab.net Tue Aug 18 04:53:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11F43A67A3; Tue, 18 Aug 2009 04:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnUTjGX4HegI; Tue, 18 Aug 2009 04:53:34 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 1802C3A676A; Tue, 18 Aug 2009 04:53:34 -0700 (PDT) Received: by yop.chewa.net (Postfix, from userid 33) id 4C342494; Tue, 18 Aug 2009 13:51:30 +0200 (CEST) To: Gabi Nakibly MIME-Version: 1.0 Date: Tue, 18 Aug 2009 13:51:30 +0200 From: =?UTF-8?Q?R=C3=A9mi_Denis-Courmont?= Organization: Remlab.net In-Reply-To: <726098.63579.qm@web45508.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> <726098.63579.qm@web45508.mail.sp1.yahoo.com> Message-ID: <6c60aa25c21d90342161a94ee190d34f@chewa.net> X-Sender: remi@remlab.net User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 18 Aug 2009 05:05:29 -0700 Cc: v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 11:53:35 -0000 On Tue, 18 Aug 2009 02:29:58 -0700 (PDT), Gabi Nakibly wrote: > Indeed, the vulnerability of attack 5 was noted and fixed in Miredo. > However, I am not aware of any updates to the Teredo specification to > mitigate it. This means that new implementations will always be vulnerable > as in the case of Windows Server 2008 R2. This vulnerability was reported > to Microsoft a few months ago. They have reproduced it on their end. A fix > should be released in the next RC. > I did not realize that the attack can be successful also on Linux. Thanks > for the correction. Well, it is as simple as not looping packet back to yourself, isn't it? There could be a warning in the spec, but it's really an implementation error, I think. > Please let me know the results of your check on attack #4. If you wish, I > can send you (off-list) the details of my setup for this attack. By the > way, I encourage other people on the list to verify the attacks in > different scenarios. I managed to reproduce it. Single-homed NATs have absolutely no excuse in forwarding a packet with their own IP address as the source. But yeah - there is a problem. -- Rémi Denis-Courmont From weiler+secdir@watson.org Tue Aug 18 07:39:57 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24F43A69F1 for ; Tue, 18 Aug 2009 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxGfzkP1U0TE for ; Tue, 18 Aug 2009 07:39:56 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C536B3A6831 for ; Tue, 18 Aug 2009 07:39:56 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n7IEe0Vp049079 for ; Tue, 18 Aug 2009 10:40:00 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n7IEe06E049076 for ; Tue, 18 Aug 2009 10:40:00 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 18 Aug 2009 10:40:00 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Tue, 18 Aug 2009 10:40:00 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:39:57 -0000 Marcus Leech is next in the rotation. We've recently added three reviewers: Russ Mundy, Tina TSOU, and David McGrew. Please try to complete last call reviews by the end of the last call. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-08-27 Reviewer Deadline Draft Rob Austein T 2009-08-25 draft-ietf-opsawg-syslog-alarm-02 Stephen Farrell T 2009-08-25 draft-ietf-ippm-multimetrics-11 David Harrington T 2009-08-25 draft-ietf-simple-xcap-diff-13 Sam Hartman T 2009-08-25 draft-ietf-mext-aero-reqs-04 Love Hornquist-Astrand T 2009-08-25 draft-ietf-bmwg-mpls-forwarding-meth-05 Jeffrey Hutzelman T 2009-08-25 draft-ietf-mext-binding-revocation-10 Hilarie Orman TR2009-08-25 draft-ietf-ospf-hmac-sha-06 Glen Zorn T 2009-08-25 draft-ietf-ntp-dhcpv6-ntp-opt-04 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Donald Eastlake 2009-08-19 draft-zorn-radius-pkmv1-05 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-02 Phillip Hallam-Baker 2009-08-18 draft-ietf-pmol-sip-perf-metrics-03 Steve Hanna 2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04 Dan Harkins 2009-06-09 draft-ietf-enum-iax-05 Paul Hoffman 2009-08-31 draft-ietf-eai-imap-utf8-07 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman 2009-06-29 draft-ietf-ipsecme-ikev2-redirect-13 Charlie Kaufman 2009-08-31 draft-ietf-mpls-3209-patherr-05 Scott Kelly 2009-08-31 draft-ietf-mpls-gmpls-lsp-reroute-04 Stephen Kent 2009-08-31 draft-ietf-mpls-soft-preemption-18 Tero Kivinen 2009-08-28 draft-ietf-sipcore-presence-scaling-requirements-01 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Julien Laganier 2009-01-22 draft-ietf-sip-certs-08 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy 2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-13 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-07-25 draft-ietf-pkix-ta-format-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Nico Williams 2009-08-04 draft-ietf-dime-nai-routing-02 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-03 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 From Fred.L.Templin@boeing.com Tue Aug 18 08:49:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937473A68F3; Tue, 18 Aug 2009 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDPCosr5GhYS; Tue, 18 Aug 2009 08:49:29 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id EB1813A6886; Tue, 18 Aug 2009 08:49:01 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7IFmlUr005723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 10:48:48 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7IFmltf008992; Tue, 18 Aug 2009 08:48:47 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7IFmhgn008798; Tue, 18 Aug 2009 08:48:47 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 08:48:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Aug 2009 08:48:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <2705.42043.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: Acof7sREBI8RyOgVTuWZvjFQVikJ0AAJPgow References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 18 Aug 2009 15:48:46.0762 (UTC) FILETIME=[5F3E88A0:01CA201B] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 15:49:30 -0000 Gabi, ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Tuesday, August 18, 2009 3:29 AM To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Indeed the ISATAP interface of the ISATAP router is meant > to be an enterprise-interior (note that=A0it is still=A0assumed > that the associated IPv4 address is=A0non-private). As=A0we > explicitly note in the paper, the first three attacks=A0will > be mitigated=A0if proper protocol-41 filtering is deployed on > the site's border. However, note that RFC5214 does not mandate > or require this filtering. The RFC5214 Security Considerations makes clear the consequences of not implementing IPv4 ingress filtering and ip-protocol-41 filtering (i.e., a possible spooing attack in which spurious ip-protocol-41 packets are injected into an ISATAP link from outside). RFC5214 Section 6.2 additionally requires that an ISATAP interface's locator set MUST NOT span multiple sites. This means that the ISATAP interface must not decapsulate nor source ip-proto-41 packets within multiple sites, where the enterprise interior is site #1 and the global Internet is site #2. ip-protocol-41 filtering is the way in which the ISATAP interface is restricted to a single site.=20 > It is only mentioned as a possible mitigation against > incoming spurious protocol-41 packets. In addition, > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > filtering.=A0Hence it=A0will not stop attack #2. We are now talking about ip-proto-41 filtering; not ingress filtering. ip-proto-41 filtering is in both directions. It prevents ip-proto-41 packets from entering the enterprise interior ISATAP site from the Internet and prevents ip-proto-41 packets from entering the Internet ISATAP site from the enterprise interior. Else the ISATAP interface would span multiple sites. Besides, "ingress" filtering is not about packets coming from the Internet into the end site, but rather it is about packets leaving the end site and going out into the Internet. RFC2827 (BCP38) documents ingress filtering. > In addition, > as mentioned, protocol-41 filtering is not helpful when > attack #3 is launched on two routers that reside in the > same site. Note that=A0it=A0may be=A0possible for=A0the attack > packet=A0to be sourced from outside the site unless proper > filtering of incoming IPv6 packets is deployed. If the > attacker resides in the site, usually ingress filtering > will not be helpful since it is deployed in general on > the site's border. Here, we have the ISATAP router in both cases sourcing a packet from a foreign prefix. This attack is mitigated by=20 IPv6 ingress filtering which is an IPv6 security consideration and not an ISATAP nor IPv4 security consideration. BCP recommendations for network ingress filtering are documented in RFC2827 and it is expected that IPv6 routers that configure ISATAP interfaces will implement IPv6 ingress filtering according to the BCP. =A0 > In general, I would like to point out that indeed as in > most other attacks these attacks may also be mitigated by > proper firewall rules. However, I do not believe that this > should be our only answer against these attacks. I believe > that since these attacks are made possible due to the > inherent characteristics of the tunnels they=A0should be > stopped intrinsically as much as possible by the tunnel > participants and not relay on outside filtering rules. In RFC5214, Section 10 we have: "restricting access to the link can be achieved by restricting access to the site". The mitigations do exactly that, and in such a way that ISATAP nodes can operate with only the necessary and sufficient checks. So on this point, I do not share your opinion. Fred fred.l.templin@boeing.com =A0 ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Monday, August 17, 2009 8:35:08 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, =A0 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =A0 > 6.2.=A0 ISATAP Interface Address Configuration >=A0 > =A0=A0Each ISATAP interface configures a set of locators consisting of = IPv4 >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP >=A0=A0 interface's locator set MUST NOT span multiple sites. =A0 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global = Internet itself as site #2. If the ISATAP interface is to be used as an = enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =A0 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =A0 Fred fred.l.templin@boeing.com =A0 ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =A0 Hi all, I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at the National = EW Research=A0& Simulation=A0Center have recently published. The = research presents a=A0class of routing loop attacks that abuses 6to4, = ISATAP and Teredo. The=A0paper can be found at: = http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =A0 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is = not compatible with its predecessor, some interoperability mechanisms = were designed. An important category of these mechanisms is automatic = tunnels, which enable IPv6 communication over an IPv4 network without = prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these = tunnels. These attacks take advantage of inconsistencies between a = tunnel's overlay IPv6 routing state and the native IPv6 routing state. = The attacks form routing loops which can be abused as a vehicle for = traffic amplification to facilitate DoS attacks. We exhibit five attacks = of this class. One of the presented attacks can DoS a Teredo server = using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be = vulnerable. In particular, the attacks were tested against the ISATAP, = 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 = R2.=20 =A0 I think the results of the research warrant some corrective action. If = this=A0indeed shall be the general sentiment of the list, I will be = happy write an appropriate I-D. The mitigation measures we suggested in = the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since=A0they would = require=A0tunnel implementations to be updated in case new types of = automatic tunnels are introduced. =A0 Your comments are welcome. =A0 Gabi =A0 From remi.despres@free.fr Tue Aug 18 10:00:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A244B3A6BB1; Tue, 18 Aug 2009 10:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vGohu1WbNe5; Tue, 18 Aug 2009 10:00:44 -0700 (PDT) Received: from smtp2a.orange.fr (smtp2a.orange.fr [80.12.242.140]) by core3.amsl.com (Postfix) with ESMTP id B56D93A6922; Tue, 18 Aug 2009 10:00:43 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 321A980003C0; Tue, 18 Aug 2009 19:00:48 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 2622680000B9; Tue, 18 Aug 2009 19:00:48 +0200 (CEST) Received: from [193.248.104.104] (Mix-Lille-207-14-104.w193-248.abo.wanadoo.fr [193.248.104.104]) by mwinf2a23.orange.fr (SMTP Server) with ESMTP id 78E3D80003C0; Tue, 18 Aug 2009 19:00:45 +0200 (CEST) X-ME-UUID: 20090818170045495.78E3D80003C0@mwinf2a23.orange.fr In-Reply-To: <789539.81531.qm@web45502.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 18 Aug 2009 19:00:42 +0200 To: Gabi Nakibly X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Tue, 18 Aug 2009 10:30:30 -0700 Cc: v6ops , Mark Townsley , 6man 6man , secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:00:45 -0000 Hi Gabi, First, thanks to you and your colleagues for this research, and for =20 the clear presentation of its results. In my understanding, your contribution is important for transition =20 solutions to be carefully selected, and where needed improved. This mail is to complement the analysis with what applies to 6rd. For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an =20= automatic tunnel mechanism in actual use for IPv6 across IPv4 clouds. With it, service providers can offer native IPv6 to their customers =20 while using for this their existing IPv4 infrastructures. Publication of the RFC that describes it, RFC 5569, has been delayed =20 since May for a reason related to intellectual property rights =20 applicable to independent submissions. But the draft on which 6rd is based is still available, and a new =20 draft to extend its applicability is also available: - tools.ietf.org/html/draft-despres-6rd-03 - tools.ietf.org/html/draft-townsley-ipv6-6rd-01 (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and =20 neither Teredo relays nor ISP-infrastructure NATs) In its sec. 3, draft-despres-6rd-03 says: <<< The IPv4 anycast address of 6rd relays may be chosen =20 independently by each ISP. The only constraint is that routes toward the ISP that =20= are advertised must not include this address. >>> In view of your study and in my understanding, it should be completed =20= with: "Also, the ISP must not forward toward the global IPv4 global =20 Internet packets having this address as source." With this, an ISP that operates 6rd relays but operates neither 6to4 =20 relays nor Teredo relays nor NATs is immune to the routing loop =20 attack because: - An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay cannot =20= come back to an IPv4 interface of a 6rd relay of the same ISP: there =20 is no IPv4 route back to the ISP for its 6rd anycast address. - An IPv6 packet received from the IPv6 Internet by a 6rd relay =20 cannot be sent back to the IPv4 global Internet: the source address =20 of its IPv4 encapsulating packet is the 6rd anycast address, which =20 prevents it from reaching the IPv4 global Internet. Note that, if interfaces of the ISP to the IPv4 global Internet are =20 already subject to ingress filtering (packets received by the global =20 Internet are discarded if there is no reverse path available for =20 them), the added sentence is not necessary. It is just just a double =20 precaution for cases where such ingress filtering doesn't apply. (2) Case of ISPs that operate 6rd relays AND 6to4 relays (but neither =20= Teredo relays nor ISP-infrastructure NATs) In its sec. 5 on security, draft-despres-6rd-03 says: <<< o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd address that matches the IPv4 source. The IPv6 destination must not start with the ISP 6rd prefix. ... o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a =20= 6rd address of the ISP. The IPv4 destination must not be multicast, i.e. must not start with 224/3... >>> In view of your study and in my understanding, it MUST be completed =20 with: - after the first quoted paragraph: "Furthermore, if the ISP also operates 6to4 relays that advertise on =20 the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source must =20= be neither the 6to4 anycast address 192.88.99.0 nor any of its =20 equivalent IPv4 unicast addresses." - after the second quoted paragraph: "Furthermore, if the ISP also operates 6to4 relays that advertise on =20 the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination =20= derived from the IPv6 destination must be neither the IPv4 anycast =20 address 192.88.99.0 nor any of its equivalent IPv4 unicast addresses." With this, an ISP that operates both 6rd and 6to4 relays is also =20 immune to the routing-loop attack because: - an IPv6 packet forwarded to the global Internet by 6rd relays can =20 come back to the ISP IPv4 network via one of the 6to4 relays of the =20 ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source =20 address is then one of a 6to4 relay, which, with the first added =20 sentence, prevents it from being accepted by the 6rd relay. - an IPv6 packet received from the IPv6 Internet by a 6rd relay =20 cannot be sent back to the IPv4 global Internet via one of the 6to4 =20 relays: the IPv4 address derived from its IPv6 destination would have =20= for this to be one of a 6to4 relays, which, with the second added =20 sentence, prevents it from being forwarded by the 6rd relay. Note: RFC 3068, where the 6to4 anycast address is introduced, says =20 that "each 6to4 relay router that advertise the 6to4 anycast prefix =20 MUST also provide an equivalent IPv4 unicast address". Whether this =20 is really important in practice is IMHO unclear. On the other hand, =20 if this MUST is dispensed with, the above security precaution can be =20 implemented in 6rd relays without a need to handle a variable number =20 of addresses, and to administratively configure them (with the =20 associated risks of human errors). To conclude: - Without needing to modify 6to4 relays, ISATAP relays, and Teredo =20 relays, ISPs that support 6rd and don't support 6to4 appear to be =20 already protected against routing loop attacks if ingress filtering =20 is operational at their interfaces to the IPv4 global Internet. With =20 an additional simple precaution in 6rd relays, they can also be =20 immune in the absence of such filtering. - A necessary additional security precaution against routing-loop =20 attacks is now identified for ISPs that support 6rd and that, having =20 started with 6to4, wish to keep it for backward compatibility. Thanks =20= again for your analysis which made it possible. Best regards, RD Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit : > Hi all, > I would like to draw the attention of the list to some research =20 > results which my colleague and I at the National EW Research & =20 > Simulation Center have recently published. The research presents a =20 > class of routing loop attacks that abuses 6to4, ISATAP and Teredo. =20 > The paper can be found at: http://www.usenix.org/events/woot09/tech/=20= > full_papers/nakibly.pdf > > Here is the abstract: > IPv6 is the future network layer protocol for the Internet. Since =20 > it is not compatible with its predecessor, some interoperability =20 > mechanisms were designed. An important category of these mechanisms =20= > is automatic tunnels, which enable IPv6 communication over an IPv4 =20 > network without prior configuration. This category includes ISATAP, =20= > 6to4 and Teredo. We present a novel class of attacks that exploit =20 > vulnerabilities in these tunnels. These attacks take advantage of =20 > inconsistencies between a tunnel's overlay IPv6 routing state and =20 > the native IPv6 routing state. The attacks form routing loops which =20= > can be abused as a vehicle for traffic amplification to facilitate =20 > DoS attacks. We exhibit five attacks of this class. One of the =20 > presented attacks can DoS a Teredo server using a single packet. =20 > The exploited vulnerabilities are embedded in the design of the =20 > tunnels; hence any implementation of these tunnels may be =20 > vulnerable. In particular, the attacks were tested against the =20 > ISATAP, 6to4 and Teredo implementations of Windows Vista and =20 > Windows Server 2008 R2. > > I think the results of the research warrant some corrective action. =20= > If this indeed shall be the general sentiment of the list, I will =20 > be happy write an appropriate I-D. The mitigation measures we =20 > suggested in the paper are the best we could think of to completely =20= > eliminate the problem. However they are far from perfect since they =20= > would require tunnel implementations to be updated in case new =20 > types of automatic tunnels are introduced. > > Your comments are welcome. > > Gabi > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From secdir-bounces@mit.edu Tue Aug 18 10:30:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC86828C26F for ; Tue, 18 Aug 2009 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YrqMC4i2cOg for ; Tue, 18 Aug 2009 10:30:38 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BFF583A6C1B for ; Tue, 18 Aug 2009 10:30:36 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7IHUTSP021361 for ; Tue, 18 Aug 2009 13:30:29 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7IHUTQe021355 for ; Tue, 18 Aug 2009 13:30:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7IHUCbd029661 for ; Tue, 18 Aug 2009 13:30:12 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 08AD014E66F9 for ; Tue, 18 Aug 2009 13:30:11 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id 7WcJIUNnp1VPaLBH for ; Tue, 18 Aug 2009 13:30:11 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EA028C2FB; Tue, 18 Aug 2009 10:30:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 027D23A69E1; Tue, 18 Aug 2009 10:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090818173002.027D23A69E1@core3.amsl.com> Date: Tue, 18 Aug 2009 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 18 Aug 2009 11:23:46 -0700 Subject: [secdir] [New-work] WG Review: Mobility Multicast (multimob) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:30:39 -0000 A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 25, 2009. Mobility Multicast (multimob) ------------------------------- Current Status: Proposed Working Group Last Modified: 2009-08-07 Chairs: TBD Internet Area (int) Directors: Jari Arkko Ralph Droms Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: multimob@ietf.org Subscribe online at: https://www1.ietf.org/mailman/listinfo/multimob Description of Working Group The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, MLD/IGMP protocols and listener mobility. Work requiring modifications to mobility protocols, MLD/IGMP, and multicast routing protocols is out of scope in this first stage of this working group. Specific goals are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMP/MLD in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and will assume an unmodified mobile host. The work will employ the remote subscription model. This is mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Milestones: Nov 2009 Initial version of a document explaining the use of multicast in PMIPv6 Nov 2009 Initial version of a document on how to tune IGMP/MLD for mobility Feb 2010 Submit a document explaining the use of multicast in PMIPv6, for publication as either Informational or Best Current Practice Feb 2010 Submit a document on how to tune IGMP/MLD for mobility, for publication as either Informational or Best Current Practice Mar 2010 Recharter for additional optimization work involving extensions to PMIPv6, IGMPv3, or MLDv2 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Aug 18 10:30:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF3B28C342 for ; Tue, 18 Aug 2009 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.313 X-Spam-Level: X-Spam-Status: No, score=-106.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvqNHnO+QN2X for ; Tue, 18 Aug 2009 10:30:43 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 3757028C18F for ; Tue, 18 Aug 2009 10:30:38 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7IHUUxj021367 for ; Tue, 18 Aug 2009 13:30:30 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7IHUTLS021356 for ; Tue, 18 Aug 2009 13:30:29 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7IHUDUP029665 for ; Tue, 18 Aug 2009 13:30:13 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id A5D8A1BC510F for ; Tue, 18 Aug 2009 13:30:12 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id VC19seHN8XqmhOyL for ; Tue, 18 Aug 2009 13:30:12 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D76F28C332; Tue, 18 Aug 2009 10:30:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1403E28C18F; Tue, 18 Aug 2009 10:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090818173002.1403E28C18F@core3.amsl.com> Date: Tue, 18 Aug 2009 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 18 Aug 2009 11:23:46 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Internationalized Domain Names in Applications, Revised (idnabis) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:30:45 -0000 A modified charter has been submitted for the Internationalized Domain Names in Applications, Revised (idnabis) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August 25, 2009. Internationalized Domain Names in Applications, Revised (idnabis) ------------------------------- Last Modified: 2009-08-10 Additional information is available at tools.ietf.org/wg/idnabis Chair(s): - Vinton Cerf Applications Area Director(s): - Lisa Dusseault - Alexey Melnikov Applications Area Advisor: - Lisa Dusseault Mailing Lists: General Discussion: idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNA2003"). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and reduction of dependency on character mapping ) Goals and Milestones: Apr 2008 WG formation May 2008 Decision on form and structure of the WG document set Sep 2008 WG Last Call on WG document set Nov 2008 IETF Last Call on WG document set _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From gnakibly@yahoo.com Wed Aug 19 00:39:35 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6882628C35A for ; Wed, 19 Aug 2009 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTXWsSN9h9bk for ; Wed, 19 Aug 2009 00:39:34 -0700 (PDT) Received: from n65.bullet.mail.sp1.yahoo.com (n65.bullet.mail.sp1.yahoo.com [98.136.44.190]) by core3.amsl.com (Postfix) with SMTP id 5AF4428C34B for ; Wed, 19 Aug 2009 00:39:34 -0700 (PDT) Received: from [216.252.122.217] by n65.bullet.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 Received: from [69.147.65.165] by t2.bullet.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 Received: from [127.0.0.1] by omp500.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 07:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 677901.52976.bm@omp500.mail.sp1.yahoo.com Received: (qmail 64125 invoked by uid 60001); 19 Aug 2009 07:39:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250667546; bh=7bN4ZkxUxlGfnlbM+D2OvAFp+zdZ7kIMSeHOC/rBpu4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GUVIG85O/ot5prUqbHB007EOirb0hIOc8t5Sh2Y+mC6dE5qXlqz1ZWRUZlecuLc162gUaY5Dp/w28aQv2SXOlTgjCEqEng6JDmfMgdShef55y90l2OgaHzvjwVUrtBkm8x22nq03TJ7UU/RyrQsKibt97FPE26QMtrsbfk8cNLw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qklO4fYI4eclcb95Mpm7qg8Jvs9hzdDV2swgii21yNn6Z9Fdyrrg0UsWR9qucVpyvpzfECuoVzu2yua4MdW8PWdsy+LyZg7BjaDmGTN3ciSjpFYlC+W1tVWoCBarQXGfTh/GSEgf8zimvqswj0aD/p6WEG+c9beRnO0mInRJpMg=; Message-ID: <528095.63282.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: 7q85LW4VM1lrswtKVNnoJbGcElDXfHFl9q_8EGzN14EcvrZYK35sib3cxM.CJ8vrU_LUJVa65AhrOZHuOL5OHAhd3eT5vS9gTNe5ijtyFVUaV83JSoS9VFDwABkozkndNA5a3B__cjOs1.Cz_rvPxse7sRi.6.Fm6BOU84jICLwCBsHrPlsu4rwSCbfwMnzW8hMmqmUxlke.FjMQ6kspemMbAeuds5po0SoMZXhqsk4NOh7YcvaoYNG99Ut1nAdM47Rry_195koYs2.RujzZA3T60qHDY0Wx1HpEP6R_CRcTVKTkiUs- Received: from [89.138.133.93] by web45508.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 00:39:06 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <200908171954.07106.remi@remlab.net> <726098.63579.qm@web45508.mail.sp1.yahoo.com> <6c60aa25c21d90342161a94ee190d34f@chewa.net> Date: Wed, 19 Aug 2009 00:39:06 -0700 (PDT) From: Gabi Nakibly To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <6c60aa25c21d90342161a94ee190d34f@chewa.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-202411197-1250667546=:63282" Cc: v6ops , ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 07:39:35 -0000 --0-202411197-1250667546=:63282 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Remi,=0AWell, I also think that there should also be a proper check in the = spec.=0ANotice, that there are valid cases in which looping a packet back t= o yourself is OK. For example, if two processes on the same host communicat= e with each other. However, I do think that an alert implementer of a Tered= o server could avoid this loop.=0A=0AGabi=0A=0A=0A=0A=0A___________________= _____________=0AFrom: R=E9mi Denis-Courmont =0ATo: Gabi Na= kibly =0ACc: v6ops ; secdir@ietf.or= g; ipv6@ietf.org=0ASent: Tuesday, August 18, 2009 2:51:30 PM=0ASubject: Re:= Routing loop attacks using IPv6 tunnels=0A=0A=0AOn Tue, 18 Aug 2009 02:29:= 58 -0700 (PDT), Gabi Nakibly =0Awrote:=0A> Indeed, the = vulnerability of attack 5 was noted and fixed in Miredo.=0A> However, I am = not aware of any updates=A0to the Teredo specification to=0A> mitigate it. = This means that new implementations will=A0always be=0Avulnerable=0A> as in= the case of Windows Server 2008 R2. This vulnerability was reported=0A> to= Microsoft a few months ago. They have reproduced it on their end. A=0Afix= =0A> should be released in the next RC.=0A> I did not realize that the atta= ck can be successful also on Linux. Thanks=0A> for the correction.=0A=0AWel= l, it is as simple as not looping packet back to yourself, isn't it?=0ATher= e could be a warning in the spec, but it's really an implementation=0Aerror= , I think.=0A=0A> Please let me know the results of your check on attack #4= .. If you wish, I=0A> can send you (off-list)=A0the details of my setup for = this attack. By the=0A> way, I encourage other people on the list to verify= the attacks in=0A> different scenarios.=0A=0AI managed to reproduce it. Si= ngle-homed NATs have absolutely no excuse in=0Aforwarding a packet with the= ir own IP address as the source. But yeah -=0Athere is a problem.=0A=0A-- = =0AR=E9mi Denis-Courmont=0A=0A=0A --0-202411197-1250667546=:63282 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,
=0A
Well, I also think that there should also be a= proper check in the spec.
=0A
Notice, that there are valid cases = in which looping a packet back to yourself is OK. For example, if two proce= sses on the same host communicate with each other. However, I do think that= an alert implementer of a Teredo server could avoid this loop.
=0A 
=0A
Gabi
=0A

=0A
= =0A
=0AFrom: R= =E9mi Denis-Courmont <remi@remlab.net>
To: Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org&g= t;; secdir@ietf.org; ipv6@ietf.org
= Sent: Tuesday, August 18, 2009 2:51:30 PM
Subject: Re: Routing loop attacks using IPv6 t= unnels


On Tue, 18 Aug 2009 02:29:58 -0700 (PDT), Gabi Nak= ibly <gnakibly@yahoo.com>
wrote:
> Indeed, the vulnerab= ility of attack 5 was noted and fixed in Miredo.
> However, I am not = aware of any updates to the Teredo specification to
> mitigate i= t. This means that new implementations will always be
vulnerable> as in the case of Windows Server 2008 R2. This vulnerability was reported
> to Microso= ft a few months ago. They have reproduced it on their end. A
fix
>= should be released in the next RC.
> I did not realize that the atta= ck can be successful also on Linux. Thanks
> for the correction.
<= BR>Well, it is as simple as not looping packet back to yourself, isn't it?<= BR>There could be a warning in the spec, but it's really an implementation<= BR>error, I think.

> Please let me know the results of your check= on attack #4. If you wish, I
> can send you (off-list) the deta= ils of my setup for this attack. By the
> way, I encourage other peop= le on the list to verify the attacks in
> different scenarios.
I managed to reproduce it. Single-homed NATs have absolutely no excuse in<= BR>forwarding a packet with their own IP address as the source. But yeah -<= BR>there is a problem.

--
R=E9mi Denis-Courmont


=0A=0A=0A=0A --0-202411197-1250667546=:63282-- From gnakibly@yahoo.com Wed Aug 19 01:49:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8FE3A6BA7 for ; Wed, 19 Aug 2009 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.613 X-Spam-Level: X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaqotxydmZgJ for ; Wed, 19 Aug 2009 01:49:43 -0700 (PDT) Received: from n67a.bullet.mail.sp1.yahoo.com (n67a.bullet.mail.sp1.yahoo.com [98.136.45.14]) by core3.amsl.com (Postfix) with SMTP id E5E533A6AE8 for ; Wed, 19 Aug 2009 01:49:20 -0700 (PDT) Received: from [216.252.122.217] by n67.bullet.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:25 -0000 Received: from [69.147.84.100] by t2.bullet.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:24 -0000 Received: from [127.0.0.1] by omp201.mail.sp1.yahoo.com with NNFMP; 19 Aug 2009 08:49:24 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 951859.32971.bm@omp201.mail.sp1.yahoo.com Received: (qmail 40614 invoked by uid 60001); 19 Aug 2009 08:49:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250671764; bh=4hS1kj1cOnGp39rwvdnEz6YnnR8ObYiprTdsa9Q8fp8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c1vPizDKWs5YKM97am0dD3cgFb8e/TvAfAe3YZuszrQG6tyWOStAKjjXuyMJE7PrjFOXqWZw1FsoiKuSL07T9f+JvoWNJ1VB7XoXIMXrcKxo8fcgmWbrA6Xo4nq0PQNOc6ijqE+d0BPdeJbCrUMcOxVMs8qrdTnmySMFd+RjwPg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nZCeaaH0Zy9kwEkPR3RxNZg05lCV5R6n1a32W6pZ04aeH1nX0irT7Hy/N/QqhyyYBM2h5uE+lPS/p2rCVJwc7Y8DVCcyJNK3G4sZBbqFJuTA4WcObFJibw2KRHb+A7r1Mu+3h8Yr4tQzcWMFYBDkb9Wj1WQSN3e3KDoqndyIJ34=; Message-ID: <689783.40421.qm@web45505.mail.sp1.yahoo.com> X-YMail-OSG: bcyq8tsVM1nRC5ugn3B7gvrfZYgkIXfXOSu0b.J3pUwlrtd39UrR.4nA Received: from [89.138.133.93] by web45505.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 01:49:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> Date: Wed, 19 Aug 2009 01:49:23 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-967350343-1250671763=:40421" Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 08:49:45 -0000 --0-967350343-1250671763=:40421 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fred,=0ASee my comments inline ().=0A=0A=0A=0A_________________________= _______=0A=0AFrom: "Templin, Fred L" =0ATo: Gabi= Nakibly ; v6ops =0ACc: ipv6@ietf.o= rg; secdir@ietf.org=0ASent: Tuesday, August 18, 2009 6:48:45 PM=0ASubject: = RE: Routing loop attacks using IPv6 tunnels=0A=0ANow let me see that I unde= rstand Section 6.2 correctly. In attack #2, for example, I assume the ISATA= P router has two physical interfaces. A site-internal IPv4 interface with a= n address IPisatap and a site-external IPv6 interface. I also assume that t= here=A0is another border router which connects the site to the IPv4 Interne= t.=A0The ISATAP router has an ISATAP interface with a single locator: (IPis= atap, site-internal interface).=A0When the ISATAP router gets an IPv6 via i= ts external interface it will encapsulate the packet accordingly and forwar= d it through the internal IPv4 interface. If the encapsulated packet is=A0d= estined to a node outside the site then the only thing that stops it is=A0a= proto-41 filtering at the=A0other border router of the site. Did I get thi= s right?=0A=0A=0A> It is only mentioned as a possible mitigation again= st=0A> incoming spurious protocol-41 packets. In addition,=0A> Section 10 o= f RFC5214 only mentions=A0ingress not=A0egress=0A> filtering.=A0Hence it=A0= will not stop attack #2.=0A=0AWe are now talking about ip-proto-41 filterin= g; not ingress=0Afiltering. ip-proto-41 filtering is in both directions. It= =0Aprevents ip-proto-41 packets from entering the enterprise=0Ainterior ISA= TAP site from the Internet and prevents=0Aip-proto-41 packets from entering= the Internet ISATAP=0Asite from the enterprise interior. Else the ISATAP= =0Ainterface would span multiple sites.=0A=0ABesides, "ingress" filtering i= s not about packets coming=0Afrom the Internet into the end site, but rathe= r it is=0Aabout packets leaving the end site and going out into=0Athe Inter= net. RFC2827 (BCP38) documents ingress filtering.=0A=0AOK. I see what y= ou are saying here.=0A=0A=0A> In addition,=0A> as mentioned, protocol-= 41 filtering is not helpful when=0A> attack #3 is launched on two routers t= hat reside in the=0A> same site. Note that=A0it=A0may be=A0possible for=A0t= he attack=0A> packet=A0to be sourced from outside the site unless proper=0A= > filtering of incoming IPv6 packets is deployed. If the=0A> attacker resid= es in the site, usually ingress filtering=0A> will not be helpful since it = is deployed in general on=0A> the site's border.=0A=0AHere, we have the ISA= TAP router in both cases sourcing a=0Apacket from a foreign prefix. =0A= =0AWell, I do not see how this is correct. In attacks #1 and #3 the ISATAP = router sources (actually forwards) an IPv6=A0packet with=A0a source address= having=A0the corresponding=A0prefix of the ISATAP tunnel. In attacks #2 an= d #3 the ISATAP router sources and IPv4 packet with its own IPv4 address as= the source address.=0A=A0=0AThis attack is mitigated by =0AIPv6 ingre= ss filtering which is an IPv6 security consideration=0Aand not an ISATAP no= r IPv4 security consideration. BCP=0Arecommendations for network ingress fi= ltering are documented=0Ain RFC2827 and it is expected that IPv6 routers th= at configure=0AISATAP interfaces will implement IPv6 ingress filtering=0Aac= cording to the BCP.=0A=0ASo If my last comment is correct than I do not= see how ingress filtering would help here. The only case where=A0ingress f= iltering can help is in case of attack #3 when the routers reside at the sa= me site. In that case if the attack packet (packet 0) is sent from outside = the site then ingress filtering on the border of the site will drop the pac= ket.=0A=0A=0A> In general, I would like to point out that indeed as in= =0A> most other attacks these attacks may also be mitigated by=0A> proper f= irewall rules. However, I do not believe that this=0A> should be our only a= nswer against these attacks. I believe=0A> that since these attacks are mad= e possible due to the=0A> inherent characteristics of the tunnels they=A0sh= ould be=0A> stopped intrinsically as much as possible by the tunnel=0A> par= ticipants and not relay on outside filtering rules.=0A=0AIn RFC5214, Sectio= n 10 we have: "restricting access to the=0Alink can be achieved by restrict= ing access to the site". The=0Amitigations do exactly that, and in such a w= ay that ISATAP=0Anodes can operate with only the necessary and sufficient= =0Achecks. So on this point, I do not share your opinion.=0A=0AWhat abo= ut two ISATAP tunnels that reside on the same site like in attack #3. Do yo= u=A0also think that proto-41 filtering should barrier between the two tunne= ls within the site?=A0=0A=0A=0AFred=0Afred.l.templin@boeing.com=0A=A0= =0A________________________________________=0AFrom: "Templin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Monday, August= 17, 2009 8:35:08 PM=0ASubject: RE: Routing loop attacks using IPv6 tunnels= =0A=0A=0AGabi,=0A=A0=0AThanks for publishing this work. In the document, at= tacks A, B and C=0Acorrespond to a configuration that violates section 6.2 = of RFC5214:=0A=A0=0A> 6.2.=A0 ISATAP Interface Address Configuration=0A>=A0= =0A> =A0=A0Each ISATAP interface configures a set of locators consisting of= IPv4=0A>=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP=0A>=A0=A0 interface's locator set MUST NOT span multiple sites.=0A= =A0=0AIn particular, in scenarios A, B and C the IPv4 locator used for ISAT= AP=0Ais seen both within the enterprise as site #1 and within the global In= ternet=0Aitself as site #2. If the ISATAP interface is to be used as an ent= erprise-=0Ainterior interface, it should therefore not accept IP-proto-41 p= ackets=0Acoming from an IPv4 source outside of the enterprise nor source=0A= IP-proto-41 packets that are destined to an IPv4 node outside of the=0Aente= rprise. This condition should be satisfied by having the site border=0Arout= ers implement IPv4 ingress filtering and ip-protocol-41 filtering as=0Arequ= ired in Section 10 of RFC5214.=0A=A0=0AIt is mentioned that attack C could = also occur when the routers reside=0Ain the same site, where their addresse= s may be private. This would=0Acorrespond to a case in which an attacker wi= thin the site attacks the=0Asite itself, which can easily be traced - espec= ially when source address=0Aspoofing from a node within the site is prevent= ed through proper ingress=0Afiltering.=0A=A0=0AFred=0Afred.l.templin@boeing= ..com=0A=A0=0A________________________________________=0AFrom: Gabi Nakibly = [mailto:gnakibly@yahoo.com] =0ASent: Monday, August 17, 2009 8:21 AM=0ATo: = v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASubject: Routing loop attacks = using IPv6 tunnels=0A=A0=0AHi all,=0AI would like to draw the attention of = the list to=A0some=A0research=A0results which my colleague and I at the Nat= ional EW Research=A0& Simulation=A0Center have recently published. The rese= arch presents a=A0class of routing loop attacks that abuses 6to4, ISATAP an= d Teredo. The=A0paper can be found at: http://www.usenix.org/events/woot09/= tech/full_papers/nakibly.pdf=0A=A0=0AHere is the abstract:=0AIPv6 is the fu= ture network layer protocol for the Internet. Since it is not compatible wi= th its predecessor, some interoperability mechanisms were designed. An impo= rtant category of these mechanisms is automatic tunnels, which enable IPv6 = communication over an IPv4 network without prior configuration. This catego= ry includes ISATAP, 6to4 and Teredo. We present a novel class of attacks th= at exploit vulnerabilities in these tunnels. These attacks take advantage o= f inconsistencies between a tunnel's overlay IPv6 routing state and the nat= ive IPv6 routing state. The attacks form routing loops which can be abused = as a vehicle for traffic amplification to facilitate DoS attacks. We exhibi= t five attacks of this class. One of the presented attacks can DoS a Teredo= server using a single packet. The exploited vulnerabilities are embedded i= n the design of the tunnels; hence any implementation of these tunnels may = be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vista and W= indows Server 2008 R2. =0A=A0=0AI think the results of the research warrant= some corrective action. If this=A0indeed shall be the general sentiment of= the list, I will be happy write an appropriate I-D. The mitigation measure= s we suggested in the paper are the best we could think of to completely el= iminate the problem. However they are far from perfect since=A0they would r= equire=A0tunnel implementations to be updated in case new types of automati= c tunnels are introduced.=0A=A0=0AYour comments are welcome.=0A=A0=0AGabi= =0A=A0=0A=0A=0AGabi,=0A=0A________________________________________=0AFrom: = Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Tuesday, August 18, 2009 = 3:29 AM=0ATo: Templin, Fred L; v6ops=0A> Cc: ipv6@ietf.org; secdir@ietf.org= =0A> Subject: Re: Routing loop attacks using IPv6 tunnels=0A> =0A> Indeed t= he ISATAP interface of the ISATAP router is meant=0A> to be an enterprise-i= nterior (note that=A0it is still=A0assumed=0A> that the associated IPv4 add= ress is=A0non-private). As=A0we=0A> explicitly note in the paper, the first= three attacks=A0will=0A> be mitigated=A0if proper protocol-41 filtering is= deployed on=0A> the site's border. However, note that RFC5214 does not man= date=0A> or require this filtering.=0A=0AThe RFC5214 Security Consideration= s makes clear the=0Aconsequences of not implementing IPv4 ingress filtering= =0Aand ip-protocol-41 filtering (i.e., a possible spooing=0Aattack in which= spurious ip-protocol-41 packets are=0Ainjected into an ISATAP link from ou= tside). RFC5214=0ASection 6.2 additionally requires that an ISATAP interfac= e's=0Alocator set MUST NOT span multiple sites. This means that the=0AISATA= P interface must not decapsulate nor source ip-proto-41=0Apackets within mu= ltiple sites, where the enterprise interior=0Ais site #1 and the global Int= ernet is site #2. ip-protocol-41=0Afiltering is the way in which the ISATAP= interface is=0Arestricted to a single site. =0A=0A=0A=0A --0-967350343-1250671763=:40421 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fred,
=0A
See my comments inline (<gn>).
= =0A
=0A
=0A
=0A
From: "Templin, Fred L" <Fred.L.Tem= plin@boeing.com>
To: = Gabi Nakibly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org>Cc: ipv6@ietf.org; secdir= @ietf.org
Sent: Tuesday,= August 18, 2009 6:48:45 PM
Subject= : RE: Routing loop attacks using IPv6 tunnels

Gabi= ,

________________________________________
From: Gabi Nakibly [ma= ilto:gnakibly@yahoo.com]
Sent: Tuesday, August 18, 2009 3:29 AMTo: Templin, Fred L; v6ops
> Cc: ipv6@ietf.org; secdir@= ietf.org
> Subject: Re: Routing loop attacks using IPv6 tunnels>
> Indeed the ISATAP interface of the ISATAP router is meant> to be an enterprise-interior (note that it is still assume= d
> that the associated IPv4 address is non-private). As we=
> explicitly note in the paper, the first three attacks will> be mitigated if proper protocol-41 filtering is deployed on
&= gt; the site's border. However, note that RFC5214 does not mandate
> = or require this filtering.

The RFC5214 Security Considerations makes= clear the
consequences of not implementing IPv4 ingress filtering
an= d ip-protocol-41 filtering (i.e., a possible spooing
attack in which spu= rious ip-protocol-41 packets are
injected into an ISATAP link from outsi= de). RFC5214
Section 6.2 additionally requires that an ISATAP interface's
locator set MUST NOT span multiple sites. This means that t= he
ISATAP interface must not decapsulate nor source ip-proto-41
packe= ts within multiple sites, where the enterprise interior
is site #1 and t= he global Internet is site #2. ip-protocol-41
filtering is the way in wh= ich the ISATAP interface is
restricted to a single site.
<gn><= /DIV>=0A
Now let me see that I understand Section 6.2 correctly. In attack #2= , for example, I assume the ISATAP router has two physical interfaces. A si= te-internal IPv4 interface with an address IPisatap and a site-external IPv= 6 interface. I also assume that there is another border router which c= onnects the site to the IPv4 Internet. The ISATAP router has an ISATAP= interface with a single locator: (IPisatap, site-internal interface). = ;When the ISATAP router gets an IPv6 via its external interface it will enc= apsulate the packet accordingly and forward it through the internal IPv4 in= terface. If the encapsulated packet is destined to a node outside the = site then the only thing that stops it is a proto-41 filtering at the&= nbsp;other border router of the site. Did I get this right?
=0A
</gn&= gt;
=0A

> It is only mentioned as a possible mitigation against> incoming spurious protocol-41 packets. In addition,
> Section = 10 of RFC5214 only mentions ingress not egress
> filtering.=  Hence it will not stop attack #2.

We are now talking abou= t ip-proto-41 filtering; not ingress
filtering. ip-proto-41 filtering is= in both directions. It
prevents ip-proto-41 packets from entering the e= nterprise
interior ISATAP site from the Internet and prevents
ip-prot= o-41 packets from entering the Internet ISATAP
site from the enterprise = interior. Else the ISATAP
interface would span multiple sites.

Be= sides, "ingress" filtering is not about packets coming
from the Internet= into the end site, but rather it is
about packets leaving the end site = and going out into
the Internet. RFC2827 (BCP38) documents ingress filtering.
<gn>
=0A
OK. I see what you are saying here.
= =0A

> In addition,
> as mentioned, protocol-4= 1 filtering is not helpful when
> attack #3 is launched on two router= s that reside in the
> same site. Note that it may be = possible for the attack
> packet to be sourced from outside= the site unless proper
> filtering of incoming IPv6 packets is deplo= yed. If the
> attacker resides in the site, usually ingress filtering=
> will not be helpful since it is deployed in general on
> the= site's border.

Here, we have the ISATAP router in both cases sourci= ng a
packet from a foreign prefix.
=0A
=0A
<gn>
=0A
Well, I d= o not see how this is correct. In attacks #1 and #3 the ISATAP router sourc= es (actually forwards) an IPv6 packet with a source address havin= g the corresponding prefix of the ISATAP tunnel. In attacks #2 an= d #3 the ISATAP router sources and IPv4 packet with its own IPv4 address as= the source address.
=0A
</gn> 
=0A
This attack is m= itigated by
IPv6 ingress filtering which is an IPv6 security considerat= ion
and not an ISATAP nor IPv4 security consideration. BCP
recommenda= tions for network ingress filtering are documented
in RFC2827 and it is = expected that IPv6 routers that configure
ISATAP interfaces will impleme= nt IPv6 ingress filtering
according to the BCP.
<gn>
=0ASo = If my last comment is correct than I do not see how ingress filtering would= help here. The only case where ingress filtering can help is in case = of attack #3 when the routers reside at the same site. In that case if the = attack packet (packet 0) is sent from outside the site then ingress filteri= ng on the border of the site will drop the packet.
=0A
</gn>
= =0A
link ca= n be achieved by restricting access to the site". The
mitigations do exa= ctly that, and in such a way that ISATAP
nodes can operate with only the= necessary and sufficient
checks. So on this point, I do not share your = opinion.
<gn>
=0A
What about two ISATAP tunnels that reside on = the same site like in attack #3. Do you also think that proto-41 filte= ring should barrier between the two tunnels within the site? 
=0A=
&= lt;/gn>
=0A

Fred
fred.l.templin@boeing.com<= BR> 
________________________________________
From: "Templin, Fr= ed L" <Fred.L.Templin@boeing.com>
To: Gabi Naki= bly <gnakibly@yahoo.com>; v6ops <v6ops@ops.ietf.org><= BR>Cc: ip= v6@ietf.org; secdir@ietf.org
Sent: Monday, August 17, 2009 8:35:08 PM=
Subject: RE: Routing loop attacks using IPv6 tunnels


Gabi, 
Thanks for publishing this work. In the document, attacks A, B and C
correspond to a configuration= that violates section 6.2 of RFC5214:
 
> 6.2.  ISATAP = Interface Address Configuration
> 
>   Each ISAT= AP interface configures a set of locators consisting of IPv4
> &= nbsp; address-to-interface mappings from a single site; i.e., an ISATAP
= >   interface's locator set MUST NOT span multiple sites.
&= nbsp;
In particular, in scenarios A, B and C the IPv4 locator used for I= SATAP
is seen both within the enterprise as site #1 and within the globa= l Internet
itself as site #2. If the ISATAP interface is to be used as a= n enterprise-
interior interface, it should therefore not accept IP-prot= o-41 packets
coming from an IPv4 source outside of the enterprise nor so= urce
IP-proto-41 packets that are destined to an IPv4 node outside of th= e
enterprise. This condition should be satisfied by having the site border
routers implement IPv4 ingress filtering and ip-protocol-41= filtering as
required in Section 10 of RFC5214.
 
It is ment= ioned that attack C could also occur when the routers reside
in the same= site, where their addresses may be private. This would
correspond to a = case in which an attacker within the site attacks the
site itself, which= can easily be traced - especially when source address
spoofing from a n= ode within the site is prevented through proper ingress
filtering.
&n= bsp;
Fred
fred.l.templin@boeing.com
 
_= _______________________________________
From: Gabi Nakibly [mailto:gnak= ibly@yahoo.com]
Sent: Monday, August 17, 2009 8:21 AM
To: v6ops<= BR>Cc: ipv6@ietf.org; secdir@ietf.org
Subj= ect: Routing loop attacks using IPv6 tunnels
 
Hi all,
I woul= d like to draw the attention of the list to some research re= sults which my colleague and I at the National EW Research & Simul= ation Center have recently published. The research presents a cla= ss of routing loop attacks that abuses 6to4, ISATAP and Teredo. The pa= per can be found at: http://www.usenix.org/events/woot09/tech/full_papers/n= akibly.pdf
 
Here is the abstract:
IPv6 is the future network= layer protocol for the Internet. Since it is not compatible with its prede= cessor, some interoperability mechanisms were designed. An important catego= ry of these mechanisms is automatic tunnels, which enable IPv6 communicatio= n over an IPv4 network without prior configuration. This category includes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exploit = vulnerabilities in these tunnels. These attacks take advantage of inconsist= encies between a tunnel's overlay IPv6 routing state and the native IPv6 ro= uting state. The attacks form routing loops which can be abused as a vehicl= e for traffic amplification to facilitate DoS attacks. We exhibit five atta= cks of this class. One of the presented attacks can DoS a Teredo server usi= ng a single packet. The exploited vulnerabilities are embedded in the desig= n of the tunnels; hence any implementation of these tunnels may be vulnerab= le. In particular, the attacks were tested against the ISATAP, 6to4 and Ter= edo implementations of Windows Vista and Windows Server 2008 R2.
 =
I think the results of the research warrant some corrective action. If = this indeed shall be the general sentiment of the list, I will be happ= y write an appropriate I-D. The mitigation measures we suggested in the paper are the best we could think of to completely eliminate the probl= em. However they are far from perfect since they would require tu= nnel implementations to be updated in case new types of automatic tunnels a= re introduced.
 
Your comments are welcome.
 
Gabi 


=0A=0A --0-967350343-1250671763=:40421-- From gnakibly@yahoo.com Wed Aug 19 03:12:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D019528C136 for ; Wed, 19 Aug 2009 03:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8dGJNwOxMV8 for ; Wed, 19 Aug 2009 03:12:19 -0700 (PDT) Received: from web45510.mail.sp1.yahoo.com (web45510.mail.sp1.yahoo.com [68.180.197.134]) by core3.amsl.com (Postfix) with SMTP id D03333A6E93 for ; Wed, 19 Aug 2009 03:12:19 -0700 (PDT) Received: (qmail 59099 invoked by uid 60001); 19 Aug 2009 10:12:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250676743; bh=fgEG8GI5HqCo2Qtq/R+Q3NCz0PDXy11Ot/e3qYXsC3o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VnROBEhwpGYgY4wVpyMZ1LHDISyAmKs41l0U8s8WSx6Hbe7jqE6EK5CFN3+mm8xxGUve2bSYV69NvLZe6J6BcDaT4uze7sxMcAegzvIKfm12vATxn4+zj2CA1jJ/qQlVnh3aPmg0Y0bmxGTtLaUUX+L3/rIQirRxpBMveC8kfCM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r6B/Vucd5RQ5TjlHDK99hi+4Jt2n3Gpf2yXWzsiDLjSrl/gyMXLuEPDHWGng9yuawYuJYw+ODrWOIELNRC7qUvIYwXD97TQ0sELv6kivUdPAdqoxkE3VRlEWHGo+rzB9HmvBQJ5hor2tE3oaS4bPYSdhYY5tMu/aDJP0XlHBfrs=; Message-ID: <808598.58470.qm@web45510.mail.sp1.yahoo.com> X-YMail-OSG: T4Oul6IVM1na15zQ.T_OJYvfcXs4o131nz5Y7lO8W8bY4r64xlsXT55oBzVKMrZoRKYTEV1S6GXoBjRB2BngdNG2ZD5Df80WFl.9M949pHykqcOAuXv.2oYW6oy88P8t0O8Q_uH263LhSCGvCbOSkfU6426f_yFvLTBK1cjdn6lsMko5bC5dNlwL5egFoUiDRQaFJPyPXODGD9gTxf4_dylpNdcGgvJStmhlqHEWeNZP1gr7Dw9ZNX_1eTLVpiFb.qmQaWM1wFq5LJovnRbmGeodoZjr7rz4ku_wzlaCJeWZ04UTbuU- Received: from [89.138.133.93] by web45510.mail.sp1.yahoo.com via HTTP; Wed, 19 Aug 2009 03:12:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> Date: Wed, 19 Aug 2009 03:12:23 -0700 (PDT) From: Gabi Nakibly To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-73789995-1250676743=:58470" Cc: v6ops , Mark Townsley , 6man 6man , secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 10:12:21 -0000 --0-73789995-1250676743=:58470 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Remi,=0ASee my comments inline ().=0A=0AGabi=0A=0A=0A__________________= ______________=0A=0AFrom: R=E9mi Despr=E9s =0ATo: Gab= i Nakibly =0ACc: v6ops ; 6man 6man = ; secdir@ietf.org; Mark Townsley =0ASent= : Tuesday, August 18, 2009 8:00:42 PM=0ASubject: Re: Routing loop attacks u= sing IPv6 tunnels - the 6rd case=0A=0AI must admit that this is the first t= ime I read the spec of 6rd so forgive me if I miss something.=0A=0A=0A= (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and neither Te= redo relays nor ISP-infrastructure NATs)=0A=0AIn its sec. 3, draft-despres-= 6rd-03 says:=0A<<<=0A=A0 The IPv4 anycast address of 6rd relays may be chos= en independently by=0A=A0 each ISP.=A0 The only constraint is that routes t= oward the ISP that are=0A=A0 advertised must not include this address.=0A>>= >=0AIn view of your study and in my understanding, it should be completed w= ith:=0A"Also, the ISP must not forward toward the global IPv4 global Intern= et packets having this address as source."=0A=0AWith this, an ISP that oper= ates 6rd relays but operates neither 6to4 relays nor Teredo relays nor NATs= is immune to the routing loop attack because:=0A- An IPv6 packet forwarded= to the IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface = of a 6rd relay of the same ISP: there is no IPv4 route back to the ISP for = its 6rd anycast address.=0A- An IPv6 packet received from the IPv6 Internet= by a 6rd relay cannot be sent back to the IPv4 global Internet: the source= address of its IPv4 encapsulating packet is the 6rd anycast address, which= prevents it from reaching the IPv4 global Internet.=0A=0ANote that, if int= erfaces of the ISP to the IPv4 global Internet are already subject to ingre= ss filtering (packets received by the global Internet are discarded if ther= e is no reverse path available for them), the added sentence is not necessa= ry. It is just just a double precaution for cases where such ingress filter= ing doesn't apply.=0A=0A=0AI=A0agree with you that above check will wor= k. However, I might choose another way here:=A0the relay=A0must make the fo= llowing two checks:=0A1)=A0When an IPv6 packet is received from the IPv6 In= ternet the 6rd relay must ensure before encapsulation that the intended IPv= 4 destination address=A0belongs to one=A0of=A0the ISP's=A0clients (I assume= it can=A0make this check easily). This way no IPv6 packet received from th= e IPv6 Internet will be relayed to a 6to4 relay (and then back to the 6rd r= elay through the IPv6 Internet). =0A2) When an encapsulated packet is recei= ved from the IPv4 network side the 6rd relay must check that the IPv6 desti= nation does not include its own IPv4 address. For example the IPv6 destinat= ion address must not be: 2002:::/48. This will p= revent the packet from ever reaching back=A0the 6rd relay through its IPv4 = interface=0A=0AThis way=A0all the=A0checks=A0are done only at the 6rd relay= and not in=A0other IPv4 border routers of the ISP which should not be awar= e of the 6rd deployment.=0A=0A=0A=0A(2) Case of ISPs that operate 6rd = relays AND 6to4 relays (but neither Teredo relays nor ISP-infrastructure NA= Ts)=0A=0AIn its sec. 5 on security, draft-despres-6rd-03 says:=0A<<<=0A=A0 = o=A0 RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd=0A=A0= =A0 =A0 address that matches the IPv4 source.=A0 The IPv6 destination must= =0A=A0 =A0 =A0 not start with the ISP 6rd prefix.=0A...=0A=A0 o=A0 RELAY PA= CKETS FROM THE INTERNET: The IPv6 source must not be a 6rd=0A=A0 =A0 =A0 ad= dress of the ISP.=A0 The IPv4 destination must not be multicast,=0A=A0 =A0 = =A0 i.e. must not start with 224/3...=0A>>>=0A=0AIn view of your study and = in my understanding, it MUST be completed with:=0A- after the first quoted = paragraph:=0A"Furthermore, if the ISP also operates 6to4 relays that advert= ise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source mus= t be neither the 6to4 anycast address 192.88.99.0 nor any of its equivalent= IPv4 unicast addresses."=0A- after the second quoted paragraph:=0A"Further= more, if the ISP also operates 6to4 relays that advertise on the IPv6 netwo= rk the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived from the IP= v6 destination must be neither the IPv4 anycast address 192.88.99.0 nor any= of its equivalent IPv4 unicast addresses."=0A=0A=0AActually, I believe= that the precautions I suggested above will work here also instead of thos= e checks. Won't they?=0AIn general, I think that checks performed on the de= stination address (IPv4 or IPv6) should be more robust than checks on a sou= rce address.=0A=0A=0AWith this, an ISP that operates both 6rd and 6to4= relays is also immune to the routing-loop attack because:=0A- an IPv6 pack= et forwarded to the global Internet by 6rd relays can come back to the ISP = IPv4 network via one of the 6to4 relays of the ISP BUT cannot be accepted a= gain by a 6rd relay: its IPv4 source address is then one of a 6to4 relay, w= hich, with the first added sentence, prevents it from being accepted by the= 6rd relay.=0A- an IPv6 packet received from the IPv6 Internet by a 6rd rel= ay cannot be sent back to the IPv4 global Internet via one of the 6to4 rela= ys: the IPv4 address derived from its IPv6 destination would have for this = to be one of a 6to4 relays, which, with the second added sentence, prevents= it from being forwarded by the 6rd relay.=0A=0ANote: RFC 3068, where the 6= to4 anycast address is introduced, says that "each 6to4 relay router that a= dvertise the 6to4 anycast prefix MUST also provide an equivalent IPv4 unica= st address". Whether this is really important in practice is IMHO unclear. = On the other hand, if this MUST is dispensed with, the above security preca= ution can be implemented in 6rd relays without a need to handle a variable = number of addresses, and to administratively configure them (with the assoc= iated risks of human errors).=0A=0A=0AIf you do the check on the destin= ation address you can avoid this administrative configuration altogether.= =0A=0A=0ATo conclude:=0A- Without needing to modify 6to4 relays, ISATA= P relays, and Teredo relays, ISPs that support 6rd and don't support 6to4 a= ppear to be already protected against routing loop attacks if ingress filte= ring is operational at their interfaces to the IPv4 global Internet. With a= n additional simple precaution in 6rd relays, they can also be immune in th= e absence of such filtering.=0A=0AI fully agree.=0A=0A- A necessar= y additional security precaution against routing-loop attacks is now identi= fied for ISPs that support 6rd and that, having started with 6to4, wish to = keep it for backward compatibility. Thanks again for your analysis which ma= de it possible.=0A=0A=0ABest regards,=0ARD=0A=0A=0A=0ALe 17 ao=FBt 09 =E0 1= 7:21, Gabi Nakibly a =E9crit :=0A=0A> Hi all,=0A> I would like to draw the = attention of the list to some research results which my colleague and I at = the National EW Research & Simulation Center have recently published. The r= esearch presents a class of routing loop attacks that abuses 6to4, ISATAP a= nd Teredo. The paper can be found at: http://www.usenix.org/events/woot09/t= ech/full_papers/nakibly.pdf=0A> =0A> Here is the abstract:=0A> IPv6 is the = future network layer protocol for the Internet. Since it is not compatible = with its predecessor, some interoperability mechanisms were designed. An im= portant category of these mechanisms is automatic tunnels, which enable IPv= 6 communication over an IPv4 network without prior configuration. This cate= gory includes ISATAP, 6to4 and Teredo. We present a novel class of attacks = that exploit vulnerabilities in these tunnels. These attacks take advantage= of inconsistencies between a tunnel's overlay IPv6 routing state and the n= ative IPv6 routing state. The attacks form routing loops which can be abuse= d as a vehicle for traffic amplification to facilitate DoS attacks. We exhi= bit five attacks of this class. One of the presented attacks can DoS a Tere= do server using a single packet. The exploited vulnerabilities are embedded= in the design of the tunnels; hence any implementation of these tunnels ma= y be vulnerable. In particular, the attacks were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vist= a and Windows Server 2008 R2.=0A> =0A> I think the results of the research = warrant some corrective action. If this indeed shall be the general sentime= nt of the list, I will be happy write an appropriate I-D. The mitigation me= asures we suggested in the paper are the best we could think of to complete= ly eliminate the problem. However they are far from perfect since they woul= d require tunnel implementations to be updated in case new types of automat= ic tunnels are introduced.=0A> =0A> Your comments are welcome.=0A> =0A> Gab= i=0A> =0A> ----------------------------------------------------------------= ----=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Adminis= trative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> ----------= ----------------------------------------------------------=0A=0A=0A=0A=0AHi= Gabi,=0A=0AFirst, thanks to you and your colleagues for this research, and= for the clear presentation of its results.=0AIn my understanding, your con= tribution is important for transition solutions to be carefully selected, a= nd where needed improved.=0A=0AThis mail is to complement the analysis with= what applies to 6rd.=0A=0AFor those who don't know it, 6rd, like 6to4, ISA= TAP and Teredo, is an automatic tunnel mechanism in actual use for IPv6 acr= oss IPv4 clouds.=0AWith it, service providers can offer native IPv6 to thei= r customers while using for this their existing IPv4 infrastructures.=0APub= lication of the RFC that describes it, RFC 5569, has been delayed since May= for a reason related to intellectual property rights applicable to indepen= dent submissions.=0ABut the draft on which 6rd is based is still available,= and a new draft to extend its applicability is also available:=0A- tools.i= etf.org/html/draft-despres-6rd-03=0A- tools.ietf.org/html/draft-townsley-ip= v6-6rd-01=0A=0A=0A=0A --0-73789995-1250676743=:58470 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,
=0A
See my comments inline (<gn>).
= =0A
Gabi
=0A

=0A
=0A
=0A<= /DIV>=0A
From: R=E9mi Despr= =E9s <remi.despres@free.fr>
T= o: Gabi Nakibly <gnakibly@yahoo.com>
Cc: v6ops <v6ops@ops.ietf.org>; 6man 6m= an <ipv6@ietf.org>; secdir@ietf.org; Mark Townsley <townsley@cisco= .com>
Sent: Tuesday, = August 18, 2009 8:00:42 PM
Subject:= Re: Routing loop attacks using IPv6 tunnels - the 6rd case
<= /FONT>
Hi Gabi,

First, thanks to you and your colleagues for this= research, and for the clear presentation of its results.
In my understa= nding, your contribution is important for transition solutions to be carefu= lly selected, and where needed improved.

This mail is to complement = the analysis with what applies to 6rd.

For those who don't know it, 6rd, like 6to4, I= SATAP and Teredo, is an automatic tunnel mechanism in actual use for IPv6 a= cross IPv4 clouds.
With it, service providers can offer native IPv6 to t= heir customers while using for this their existing IPv4 infrastructures.Publication of the RFC that describes it, RFC 5569, has been delayed since= May for a reason related to intellectual property rights applicable to ind= ependent submissions.
But the draft on which 6rd is based is still avail= able, and a new draft to extend its applicability is also available:
- <= A href=3D"http://tools.ietf.org/html/draft-despres-6rd-03" target=3D_blank>= tools.ietf.org/html/draft-despres-6rd-03
- tools.ietf.org/htm= l/draft-townsley-ipv6-6rd-01
<gn>
=0A
I must admit that thi= s is the first time I read the spec of 6rd so forgive me if I miss somethin= g.
=0A
</gn>

(1) Case of ISPs that operate 6rd relays and n= o 6to4 relays (and neither Teredo relays nor ISP-infrastructure NATs)
In its sec. 3, draft-despres-6rd-03 says:
<<<
  The I= Pv4 anycast address of 6rd relays may be chosen independently by
  = each ISP.  The only constraint is that routes toward the ISP that are<= BR>  advertised must not include this address.
>>>
In v= iew of your study and in my understanding, it should be completed with:
= "Also, the ISP must not forward toward the global IPv4 global Internet pack= ets having this address as source."

With this, an ISP that operates = 6rd relays but operates neither 6to4 relays nor Teredo relays nor NATs is i= mmune to the routing loop attack because:
- An IPv6 packet forwarded to = the IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface of a= 6rd relay of the same ISP: there is no IPv4 route back to the ISP for its 6rd = anycast address.
- An IPv6 packet received from the IPv6 Internet by a 6= rd relay cannot be sent back to the IPv4 global Internet: the source addres= s of its IPv4 encapsulating packet is the 6rd anycast address, which preven= ts it from reaching the IPv4 global Internet.

Note that, if interfac= es of the ISP to the IPv4 global Internet are already subject to ingress fi= ltering (packets received by the global Internet are discarded if there is = no reverse path available for them), the added sentence is not necessary. I= t is just just a double precaution for cases where such ingress filtering d= oesn't apply.
=0A
<gn>
=0A
I agree with you that above= check will work. However, I might choose another way here: the relay&= nbsp;must make the following two checks:
=0A
1) When an IPv6 packet= is received from the IPv6 Internet the 6rd relay must ensure before encaps= ulation that the intended IPv4 destination address belongs to one = ;of the ISP's clients (I assume it can make this check easil= y). This way no IPv6 packet received from the IPv6 Internet will be relayed= to a 6to4 relay (and then back to the 6rd relay through the IPv6 Internet)= .
=0A
2) When an encapsulated packet is received from the IPv4 network = side the 6rd relay must check that the IPv6 destination does not include it= s own IPv4 address. For example the IPv6 destination address must not be: 2= 002:<IPv4 address of 6rd relay>::/48. This will prevent the packet fr= om ever reaching back the 6rd relay through its IPv4 interface
= =0A
This way all the checks are done only at the= 6rd relay and not in other IPv4 border routers of the ISP which shoul= d not be aware of the 6rd deployment.
=0A
</gn>


(2) Cas= e of ISPs that operate 6rd relays AND 6to4 relays (but neither Teredo relay= s nor ISP-infrastructure NATs)

In its sec. 5 on security, draft-desp= res-6rd-03 says:
<<<
  o  RELAY PACKETS TOWARD THE= INTERNET: The IPv6 source must be a 6rd
      address th= at matches the IPv4 source.  The IPv6 destination must
   = ;   not start with the ISP 6rd prefix.
...
  o  RELAY = PACKETS FROM THE INTERNET: The IPv6 source must not be a 6rd
  &nbs= p;   address of the ISP.  The IPv4 destination must not be multic= ast,
      i.e. must not start with 224/3...
>>&= gt;

In view of your study and in my understanding, it MUST be comple= ted with:
- after the first quoted paragraph:
"Furthermore, if the IS= P also operates 6to4 relays that advertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 sou= rce must be neither the 6to4 anycast address 192.88.99.0 nor any of its equ= ivalent IPv4 unicast addresses."
- after the second quoted paragraph:"Furthermore, if the ISP also operates 6to4 relays that advertise on the I= Pv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived fr= om the IPv6 destination must be neither the IPv4 anycast address 192.88.99.= 0 nor any of its equivalent IPv4 unicast addresses."
=0A
<gn><= /DIV>=0A
Actually, I believe that the precautions I suggested above will work= here also instead of those checks. Won't they?
=0A
In general, I think = that checks performed on the destination address (IPv4 or IPv6) should be m= ore robust than checks on a source address.
=0A
</gn>
=0A
W= ith this, an ISP that operates both 6rd and 6to4 relays is also immune to t= he routing-loop attack because:
- an IPv6 packet forwarded to the global= Internet by 6rd relays can come back to the ISP IPv4 network via one of th= e 6to4 relays of the ISP BUT cannot be accepted again by a 6rd relay: its I= Pv4 source address is then one of a 6to4 relay, which, with the first added= sentence, prevents it from being accepted by the 6rd relay.
- an IPv6 p= acket received from the IPv6 Internet by a 6rd relay cannot be sent back to= the IPv4 global Internet via one of the 6to4 relays: the IPv4 address deri= ved from its IPv6 destination would have for this to be one of a 6to4 relay= s, which, with the second added sentence, prevents it from being forwarded = by the 6rd relay.

Note: RFC 3068, where the 6to4 anycast address is = introduced, says that "each 6to4 relay router that advertise the 6to4 anycast prefix MUST also provide an equivalent IPv4 unicast address".= Whether this is really important in practice is IMHO unclear. On the other= hand, if this MUST is dispensed with, the above security precaution can be= implemented in 6rd relays without a need to handle a variable number of ad= dresses, and to administratively configure them (with the associated risks = of human errors).

<gn>
=0A
If you do the check on the desti= nation address you can avoid this administrative configuration altogether.<= /DIV>=0A
</gn>

To conclude:
- Without needing to modify 6to4 = relays, ISATAP relays, and Teredo relays, ISPs that support 6rd and don't s= upport 6to4 appear to be already protected against routing loop attacks if = ingress filtering is operational at their interfaces to the IPv4 global Int= ernet. With an additional simple precaution in 6rd relays, they can also be= immune in the absence of such filtering.
=0A
<gn>
=0A
I fully = agree.
=0A
</gn>
- A necessary additional security precaution a= gainst routing-loop attacks is now identified for ISPs that support 6rd and= that, having started with 6to4, wish to keep it for backward compatibility= . Thanks again for your analysis which made it possible.


Best re= gards,
RD



Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9cr= it :

> Hi all,
> I would like to draw the attention of the = list to some research results which my colleague and I at the National EW R= esearch & Simulation Center have recently published. The research prese= nts a class of routing loop attacks that abuses 6to4, ISATAP and Teredo. Th= e paper can be found at: http://www.usenix.org/events/woot09/tech/full_pape= rs/nakibly.pdf
>
> Here is the abstract:
> IPv6 is the f= uture network layer protocol for the Internet. Since it is not compatible w= ith its predecessor, some interoperability mechanisms were designed. An important = category of these mechanisms is automatic tunnels, which enable IPv6 commun= ication over an IPv4 network without prior configuration. This category inc= ludes ISATAP, 6to4 and Teredo. We present a novel class of attacks that exp= loit vulnerabilities in these tunnels. These attacks take advantage of inco= nsistencies between a tunnel's overlay IPv6 routing state and the native IP= v6 routing state. The attacks form routing loops which can be abused as a v= ehicle for traffic amplification to facilitate DoS attacks. We exhibit five= attacks of this class. One of the presented attacks can DoS a Teredo serve= r using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be vul= nerable. In particular, the attacks were tested against the ISATAP, 6to4 an= d Teredo implementations of Windows Vista and Windows Server 2008 R2.
>
> I think the results of the research warrant some corr= ective action. If this indeed shall be the general sentiment of the list, I= will be happy write an appropriate I-D. The mitigation measures we suggest= ed in the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since they would require tunnel = implementations to be updated in case new types of automatic tunnels are in= troduced.
>
> Your comments are welcome.
>
> Gabi=
>
> ---------------------------------------------------------= -----------
> IETF IPv6 working group mailing list
> ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= BR>> --------------------------------------------------------------------



=0A=0A --0-73789995-1250676743=:58470-- From Fred.L.Templin@boeing.com Wed Aug 19 08:16:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5B63A6F79; Wed, 19 Aug 2009 08:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFOWYVmZfmwp; Wed, 19 Aug 2009 08:16:18 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A28F23A6AFD; Wed, 19 Aug 2009 08:16:18 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7JFGKcd015199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Aug 2009 08:16:21 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7JFGKlO012175; Wed, 19 Aug 2009 10:16:20 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7JFGHbw012098; Wed, 19 Aug 2009 10:16:20 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 08:16:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Aug 2009 08:16:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1064DB28F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <689783.40421.qm@web45505.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcogqfWX02z6QDvcQleWnEJQ4OsboAAJVPYg References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106497BE7@XCH-NW-7V2.nw.nos.boeing.com> <2705.42043.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106498101@XCH-NW-7V2.nw.nos.boeing.com> <689783.40421.qm@web45505.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 19 Aug 2009 15:16:20.0245 (UTC) FILETIME=[01715C50:01CA20E0] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 15:16:20 -0000 Hi Gabi, I'm sorry to have to keep turning this into plaintext, but annotation is difficult otherwise. See below for my responses (=3D=3D>): ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Wednesday, August 19, 2009 1:49 AM To: Templin, Fred L; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Re: Routing loop attacks using IPv6 tunnels Fred, See my comments inline (). ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Tuesday, August 18, 2009 6:48:45 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Tuesday, August 18, 2009 3:29 AM To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Indeed the ISATAP interface of the ISATAP router is meant > to be an enterprise-interior (note that=A0it is still=A0assumed > that the associated IPv4 address is=A0non-private). As=A0we > explicitly note in the paper, the first three attacks=A0will > be mitigated=A0if proper protocol-41 filtering is deployed on > the site's border. However, note that RFC5214 does not mandate > or require this filtering. The RFC5214 Security Considerations makes clear the consequences of not implementing IPv4 ingress filtering and ip-protocol-41 filtering (i.e., a possible spooing attack in which spurious ip-protocol-41 packets are injected into an ISATAP link from outside). RFC5214 Section 6.2 additionally requires that an ISATAP interface's locator set MUST NOT span multiple sites. This means that the ISATAP interface must not decapsulate nor source ip-proto-41 packets within multiple sites, where the enterprise interior is site #1 and the global Internet is site #2. ip-protocol-41 filtering is the way in which the ISATAP interface is restricted to a single site.=20 Now let me see that I understand Section 6.2 correctly. In attack #2, for example, I assume the ISATAP router has two physical interfaces. A site-internal IPv4 interface with an address IPisatap and a site-external IPv6 interface. I also assume that there=A0is another border router which connects the site to the IPv4 Internet.=A0The ISATAP router has an ISATAP interface with a single locator: (IPisatap, site-internal interface).=A0When the ISATAP router gets an IPv6 via its external interface it will encapsulate the packet accordingly and forward it through the internal IPv4 interface. If the encapsulated packet is=A0destined to a node outside the site then the only thing that stops it is=A0a proto-41 filtering at the=A0other border router of the site. Did I get this right? =3D=3D> In this case, yes - the ip-proto-41 filtering is at a =3D=3D> border router. I know of at least one major enterprise =3D=3D> network that does this. > It is only mentioned as a possible mitigation against > incoming spurious protocol-41 packets. In addition, > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > filtering.=A0Hence it=A0will not stop attack #2. We are now talking about ip-proto-41 filtering; not ingress filtering. ip-proto-41 filtering is in both directions. It prevents ip-proto-41 packets from entering the enterprise interior ISATAP site from the Internet and prevents ip-proto-41 packets from entering the Internet ISATAP site from the enterprise interior. Else the ISATAP interface would span multiple sites. Besides, "ingress" filtering is not about packets coming from the Internet into the end site, but rather it is about packets leaving the end site and going out into the Internet. RFC2827 (BCP38) documents ingress filtering. OK. I see what you are saying here. =3D=3D> OK. > In addition, > as mentioned, protocol-41 filtering is not helpful when > attack #3 is launched on two routers that reside in the > same site. Note that=A0it=A0may be=A0possible for=A0the attack > packet=A0to be sourced from outside the site unless proper > filtering of incoming IPv6 packets is deployed. If the > attacker resides in the site, usually ingress filtering > will not be helpful since it is deployed in general on > the site's border. Here, we have the ISATAP router in both cases sourcing a packet from a foreign prefix.=20 Well, I do not see how this is correct. In attacks #1 and #3 the ISATAP = router sources (actually forwards) an IPv6=A0packet with=A0a source = address having=A0the corresponding=A0prefix of the ISATAP tunnel. In = attacks #2 and #3 the ISATAP router sources and IPv4 packet with its own = IPv4 address as the source address. =3D=3D> There were a number of errors in what I said in my last =3D=3D> message, so let me see if I can get it right here: =3D=3D> =3D=3D> In attacks #1 and #2 there are two cases to consider. Case =3D=3D> 1 in which a border router separates the 6to4 relay from the =3D=3D> ISATAP router, and case 2 in which no border router separates =3D=3D> the 6to4 relay from the ISATAP router. =3D=3D> =3D=3D> In attack #1, we have an IPv6 packet with a local source =3D=3D> address entering the site from the outside. IPv6 ingress =3D=3D> filtering at the site border router should prevent the =3D=3D> packet from entering the site in the first place. If the =3D=3D> 6to4 relay router is outside the site then ip-proto-41 =3D=3D> filtering at the border router will block the attack in =3D=3D> the first place anyway. If the relay router is *inside* =3D=3D> the site, then the IPv6 ingress filtering is the lone =3D=3D> mitigation. The end result is that the 6to4 relay should =3D=3D> really be positioned outside of the site's border routers; =3D=3D> otherwise, it could be spoofed into thinking that the =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router.=20 =3D=3D> =3D=3D> In attack #2, we have an IPv6 packet with a foreign source =3D=3D> address being forwarded by the ISATAP router to a 6to4 =3D=3D> relay, but I mis-spoke when I said that this would be a =3D=3D> case of the ISATAP router forwarding a packet with a foreign =3D=3D> source address out of the ISATAP link. For all the ISATAP =3D=3D> router knows, the 6to4 relay is just an ordinary host on =3D=3D> the ISATAP link, so the ISATAP router actually believes it =3D=3D> is forwarding the packet *into* the ISATAP link (not out of =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41 =3D=3D> filtering at the border router between the ISATAP router and =3D=3D> the 6to4 relay. If there is no border router between the ISATAP =3D=3D> router and the 6to4 relay, then we have an identical instance =3D=3D> to attack #3 which I will discuss below. But, the best =3D=3D> operational practice would again be to have the 6to4 relay =3D=3D> oriented outside of a border router that filters ip-proto-41. =3D=3D> =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks it =3D=3D> is talking to a 6to4 router and not an ISATAP router. In =3D=3D> attack #2, the ISATAP router thinks it is talking to a =3D=3D> simple host on the link and not a 6to4 relay. In both cases, =3D=3D> the attacks are mitigated when there is an ip-proto-41 =3D=3D> filtering border router between the ISATAP router and the =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- =3D=3D> interface router that implements 6to4 on a site-external =3D=3D> IPv4 interface and implements ISATAP on a site-internal =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packets =3D=3D> from outside the site with an IPv4 destination corresponding =3D=3D> to the ISATAP interface. I will discuss attack #3 below: =A0 This attack is mitigated by=20 IPv6 ingress filtering which is an IPv6 security consideration and not an ISATAP nor IPv4 security consideration. BCP recommendations for network ingress filtering are documented in RFC2827 and it is expected that IPv6 routers that configure ISATAP interfaces will implement IPv6 ingress filtering according to the BCP. So If my last comment is correct than I do not see how ingress filtering = would help here. The only case where=A0ingress filtering can help is in = case of attack #3 when the routers reside at the same site. In that case = if the attack packet (packet 0) is sent from outside the site then = ingress filtering on the border of the site will drop the packet. =3D=3D> Correct about the IPv6 ingress filtering at the border, =3D=3D> but as with attack #2 my error in the previous message =3D=3D> was in thinking the ISATAP router A was forwarding the =3D=3D> packet *out* of the ISATAP link when in fact from the =3D=3D> ISATAP router's perspective it is forwarding the packet =3D=3D> to a simple host *inside* of the link. =3D=3D> =3D=3D> The problem here is that the ISATAP router is blindly =3D=3D> forwarding a packet to a node that it assumes is a simple =3D=3D> host on the ISATAP link without first verifying that the =3D=3D> node has demonstrated a willingness to participate as a =3D=3D> host on the link. As you have pointed out, this can lead =3D=3D> to strange scenarios when the anonymous node is a tunnel =3D=3D> router of some sort that does not participate in the =3D=3D> ISATAP link. =3D=3D> =3D=3D> It would not generally be possible for the ISATAP router =3D=3D> to check whether the IPv6 destination address is an ISATAP =3D=3D> address that embeds one of its own IPv4 addresses, because =3D=3D> when IPv4 private addresses are used the same IPv4 address =3D=3D> can (and often does) occur in multiple sites. So for example, =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 =3D=3D> and is asked to forward an IPv6 packet with ISATAP =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the =3D=3D> IPv6 prefix is foreign, the router can't very well drop the =3D=3D> packet as this would block legitimate communications. It =3D=3D> is also not generally possible to check whether a foreign =3D=3D> link is an ISATAP link by looking for the magic token =3D=3D> "0:5EFE" as that token only has significance for ISATAP =3D=3D> links and not other link types. =3D=3D> =3D=3D> Instead, the mitigation I think makes the most sense is =3D=3D> for the ISATAP router to first verify that the node which =3D=3D> it assumes to be a simple ISATAP host has demonstrated a =3D=3D> willingness to participate in the link. That can be done =3D=3D> by having the ISATAP router first check the neighbor cache =3D=3D> when it has a packet to send to verify that there is a =3D=3D> cached entry corresponding to the destination. For nodes =3D=3D> that are willing ISATAP hosts on the link, there would =3D=3D> have been a neighbor cache entry created when the node =3D=3D> sends a Router Solicitation to the ISATAP router for the =3D=3D> purpose of discovering default router lifetimes and on- =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP =3D=3D> router to forward the packet only if there is a pre-existing =3D=3D> neighbor cache entry and drop the packet otherwise. This =3D=3D> implies that the router should keep neighbor cache entires =3D=3D> for the duration of the minimum lifetime of the prefixes =3D=3D> it advertises in its Router Advertisements. =20 > In general, I would like to point out that indeed as in > most other attacks these attacks may also be mitigated by > proper firewall rules. However, I do not believe that this > should be our only answer against these attacks. I believe > that since these attacks are made possible due to the > inherent characteristics of the tunnels they=A0should be > stopped intrinsically as much as possible by the tunnel > participants and not relay on outside filtering rules. In RFC5214, Section 10 we have: "restricting access to the link can be achieved by restricting access to the site". The mitigations do exactly that, and in such a way that ISATAP nodes can operate with only the necessary and sufficient checks. So on this point, I do not share your opinion. What about two ISATAP tunnels that reside on the same site like in = attack #3. Do you=A0also think that proto-41 filtering should barrier = between the two tunnels within the site?=A0 =3D=3D> I think this may be overcome by the discussion above. =3D=3D> Short story is that operational practices must be =3D=3D> employed whereby an ISATAP router is not mistaken for =3D=3D> a 6to4 router. This is through proper arrangement of =3D=3D> 6to4 router/relay interfaces outside of the site border =3D=3D> rather than inside, and ISATAP router interfaces inside =3D=3D> of the site border rather than outside. Also proper =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at =3D=3D> site borders. =3D=3D> =3D=3D> Also, when there are multiple ISATAP links within the =3D=3D> same local IPv4 routing region, an ISATAP router should =3D=3D> first verify a node's willingness to act as a host on =3D=3D> the ISATAP link before blindly sending a packet to it. =3D=3D> =3D=3D> Fred =3D=3D> fred.l.templin@boeing.com Fred fred.l.templin@boeing.com =A0 ________________________________________ From: "Templin, Fred L" To: Gabi Nakibly ; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Sent: Monday, August 17, 2009 8:35:08 PM Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, =A0 Thanks for publishing this work. In the document, attacks A, B and C correspond to a configuration that violates section 6.2 of RFC5214: =A0 > 6.2.=A0 ISATAP Interface Address Configuration >=A0 > =A0=A0Each ISATAP interface configures a set of locators consisting of = IPv4 >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP >=A0=A0 interface's locator set MUST NOT span multiple sites. =A0 In particular, in scenarios A, B and C the IPv4 locator used for ISATAP is seen both within the enterprise as site #1 and within the global = Internet itself as site #2. If the ISATAP interface is to be used as an = enterprise- interior interface, it should therefore not accept IP-proto-41 packets coming from an IPv4 source outside of the enterprise nor source IP-proto-41 packets that are destined to an IPv4 node outside of the enterprise. This condition should be satisfied by having the site border routers implement IPv4 ingress filtering and ip-protocol-41 filtering as required in Section 10 of RFC5214. =A0 It is mentioned that attack C could also occur when the routers reside in the same site, where their addresses may be private. This would correspond to a case in which an attacker within the site attacks the site itself, which can easily be traced - especially when source address spoofing from a node within the site is prevented through proper ingress filtering. =A0 Fred fred.l.templin@boeing.com =A0 ________________________________________ From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=20 Sent: Monday, August 17, 2009 8:21 AM To: v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: Routing loop attacks using IPv6 tunnels =A0 Hi all, I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at the National = EW Research=A0& Simulation=A0Center have recently published. The = research presents a=A0class of routing loop attacks that abuses 6to4, = ISATAP and Teredo. The=A0paper can be found at: = http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf =A0 Here is the abstract: IPv6 is the future network layer protocol for the Internet. Since it is = not compatible with its predecessor, some interoperability mechanisms = were designed. An important category of these mechanisms is automatic = tunnels, which enable IPv6 communication over an IPv4 network without = prior configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks that exploit vulnerabilities in these = tunnels. These attacks take advantage of inconsistencies between a = tunnel's overlay IPv6 routing state and the native IPv6 routing state. = The attacks form routing loops which can be abused as a vehicle for = traffic amplification to facilitate DoS attacks. We exhibit five attacks = of this class. One of the presented attacks can DoS a Teredo server = using a single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any implementation of these tunnels may be = vulnerable. In particular, the attacks were tested against the ISATAP, = 6to4 and Teredo implementations of Windows Vista and Windows Server 2008 = R2.=20 =A0 I think the results of the research warrant some corrective action. If = this=A0indeed shall be the general sentiment of the list, I will be = happy write an appropriate I-D. The mitigation measures we suggested in = the paper are the best we could think of to completely eliminate the = problem. However they are far from perfect since=A0they would = require=A0tunnel implementations to be updated in case new types of = automatic tunnels are introduced. =A0 Your comments are welcome. =A0 Gabi =A0 From d3e3e3@gmail.com Wed Aug 19 20:46:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515AF3A6992; Wed, 19 Aug 2009 20:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iRssPYH3wMr; Wed, 19 Aug 2009 20:46:39 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id DDDD23A6CC3; Wed, 19 Aug 2009 20:46:38 -0700 (PDT) Received: by ewy2 with SMTP id 2so1626822ewy.43 for ; Wed, 19 Aug 2009 20:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Maw1wDGAGoIuBvohk9UjYkXK2tAVE+BiRg+qWRCd/DI=; b=O6d9jumTiAa7v3KfIArvzZ1MWxAWDc5/XTG4x85Py4QzjeM+UzbrapzaPLH385esyn I4fDh5vMKy9QIPrIsBy9ZqoWlOeG2gHY4FdYmneDBpbaImENtHGC0Cyal0mYYeOI4IYy TSfSJbCIZQNCxc/y0mCrJnXMEgrUOlPYI7Jbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=OL49p0M4KYlW+Zc3v8veDKF+vl7my9Z5G7g9HWjy5jeQI1GscdLRmfcypopum3EvAX lTc8JkjeeVz9uTDVpX9xSls9x5ZxrClumRI5A3uDy8+GZomXymSAMOoQ2FMVwnf9HiUh PdN3u/MfqARhVKTbsNTvSqMt1V+x0Wq3KWhKI= MIME-Version: 1.0 Received: by 10.216.85.200 with SMTP id u50mr1731517wee.73.1250739987617; Wed, 19 Aug 2009 20:46:27 -0700 (PDT) Date: Wed, 19 Aug 2009 23:46:27 -0400 Message-ID: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> From: Donald Eastlake To: IETF Discussion , secdir@ietf.org, Glen Zorn , Dan Romascanu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 03:46:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines seven RADIUS Attributes to support the implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version 1). I would guess that RADIUS can be used between the 802.16 Base Station and an authorization server but I don't know how you could tell. Maybe I missed it but it looks like the RADIUS protocol isn't mentioned anywhere in 802.16-2004. From the text in some of these RADIUS attribute descriptions, it appears that they are not used between the Subscriber Station and the Base Stations but may be the basis of 802.16 Attributes that are used on that hop. Given this, I think a paragraph is needed (maybe even accompanied by a little ASCII art) at the beginning show what's going on would be useful. Many document have security considerations section that only refer to other documents and may be missing specifics to the document contents. I think this document has the opposite problem good security specifics in the security consideration section but could usefully add references to the 802.16-2004 and RADiUS security sections. The security considerations section rightly warns to protect against modification of the PKM-Auth-Key attribute. But is it really clear there is no problem with modification of the Security Association ID attribute or the attribute listing cryptosuites? The wording in Sections 3.1 and 3.2 see to almost be designed to allow the possibility of the multiple *-Cert Attributes carrying a certificate to appear in more than one Access-Request message. But I would assume that's not meaningful and/or was not intended to allow that. The table of attributes in Section 4 that gives the number of times each attribute can occur in different message types seems to have problems. Since there is no key giving it another meaning, I assume "0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are described and possibly occurring multiple times due to fragmentation of certificates. If the table is supposed to be in terms of logical attributes so that multiple PKM-SS-Cert attributes only count as one if they have parts of one certificate, then the table should say so. On the other hand, the PKM-SA-Descriptor attribute is shown as "0+", which presumably means zero or more, but the text description in 3.6 clearly says it can occur one or more times, which presumably would be written "1+". This whole table need to be carefully checked, the inconsistencies resolved, and it should be clear if literal binary attributes or some sort of logical aggregate attributes (in the case of the "Cert" attributes at least), is being counted. The text between the Section 6. header line and the Section 6.1 header line as well as the Section 6.1 header line itself seem superfluous and can be deleted. I think this document still needs a little more work. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From remi.despres@free.fr Thu Aug 20 02:34:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB3F3A6FEA; Thu, 20 Aug 2009 02:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P8l54m1s5ZO; Thu, 20 Aug 2009 02:34:54 -0700 (PDT) Received: from smtp28.orange.fr (smtp28.orange.fr [80.12.242.100]) by core3.amsl.com (Postfix) with ESMTP id D833428C21B; Thu, 20 Aug 2009 02:34:49 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 990C57000082; Thu, 20 Aug 2009 11:34:54 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 8CAB5700008D; Thu, 20 Aug 2009 11:34:54 +0200 (CEST) Received: from [193.248.114.206] (Mix-Lille-207-3-206.w193-248.abo.wanadoo.fr [193.248.114.206]) by mwinf2806.orange.fr (SMTP Server) with ESMTP id 201507000082; Thu, 20 Aug 2009 11:34:50 +0200 (CEST) X-ME-UUID: 20090820093451131.201507000082@mwinf2806.orange.fr In-Reply-To: <808598.58470.qm@web45510.mail.sp1.yahoo.com> References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> <808598.58470.qm@web45510.mail.sp1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 20 Aug 2009 11:34:49 +0200 To: Gabi Nakibly X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Thu, 20 Aug 2009 08:36:21 -0700 Cc: v6ops , Mark Townsley , 6man 6man , secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 09:34:56 -0000 gabi, Thanks for your quick answer. Further remarks in line. Le 19 ao=FBt 09 =E0 12:12, Gabi Nakibly a =E9crit : > Remi, > See my comments inline (). > Gabi > > From: R=E9mi Despr=E9s > To: Gabi Nakibly > Cc: v6ops ; 6man 6man ; =20 > secdir@ietf.org; Mark Townsley > Sent: Tuesday, August 18, 2009 8:00:42 PM > Subject: Re: Routing loop attacks using IPv6 tunnels - the 6rd case > > Hi Gabi, > > First, thanks to you and your colleagues for this research, and for =20= > the clear presentation of its results. > In my understanding, your contribution is important for transition =20 > solutions to be carefully selected, and where needed improved. > > This mail is to complement the analysis with what applies to 6rd. > > For those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is =20 > an automatic tunnel mechanism in actual use for IPv6 across IPv4 =20 > clouds. > With it, service providers can offer native IPv6 to their customers =20= > while using for this their existing IPv4 infrastructures. > Publication of the RFC that describes it, RFC 5569, has been =20 > delayed since May for a reason related to intellectual property =20 > rights applicable to independent submissions. > But the draft on which 6rd is based is still available, and a new =20 > draft to extend its applicability is also available: > - tools.ietf.org/html/draft-despres-6rd-03 > - tools.ietf.org/html/draft-townsley-ipv6-6rd-01 > > I must admit that this is the first time I read the spec of 6rd so =20 > forgive me if I miss something. > > > (1) Case of ISPs that operate 6rd relays and no 6to4 relays (and =20 > neither Teredo relays nor ISP-infrastructure NATs) > > In its sec. 3, draft-despres-6rd-03 says: > <<< > The IPv4 anycast address of 6rd relays may be chosen =20 > independently by > each ISP. The only constraint is that routes toward the ISP that =20= > are > advertised must not include this address. > >>> > In view of your study and in my understanding, it should be =20 > completed with: > "Also, the ISP must not forward toward the global IPv4 global =20 > Internet packets having this address as source." > > With this, an ISP that operates 6rd relays but operates neither =20 > 6to4 relays nor Teredo relays nor NATs is immune to the routing =20 > loop attack because: > - An IPv6 packet forwarded to the IPv6 Internet by a 6rd relay =20 > cannot come back to an IPv4 interface of a 6rd relay of the same =20 > ISP: there is no IPv4 route back to the ISP for its 6rd anycast =20 > address. > - An IPv6 packet received from the IPv6 Internet by a 6rd relay =20 > cannot be sent back to the IPv4 global Internet: the source address =20= > of its IPv4 encapsulating packet is the 6rd anycast address, which =20 > prevents it from reaching the IPv4 global Internet. > > Note that, if interfaces of the ISP to the IPv4 global Internet are =20= > already subject to ingress filtering (packets received by the =20 > global Internet are discarded if there is no reverse path available =20= > for them), the added sentence is not necessary. It is just just a =20 > double precaution for cases where such ingress filtering doesn't =20 > apply. > > I agree with you that above check will work. However, I might =20 > choose another way here: the relay must make the following two checks: > 1) When an IPv6 packet is received from the IPv6 Internet the 6rd =20 > relay must ensure before encapsulation that the intended IPv4 =20 > destination address belongs to one of the ISP's clients (I assume =20 > it can make this check easily). This way no IPv6 packet received =20 > from the IPv6 Internet will be relayed to a 6to4 relay (and then =20 > back to the 6rd relay through the IPv6 Internet). The problem is that this check is not easy "in general" because ISPs =20 typically have their IPv4 prefixes allocated one by one as they =20 increase the number of their clients. > 2) When an encapsulated packet is received from the IPv4 network =20 > side the 6rd relay must check that the IPv6 destination does not =20 > include its own IPv4 address. For example the IPv6 destination =20 > address must not be: 2002:::/48. This =20 > will prevent the packet from ever reaching back the 6rd relay =20 > through its IPv4 interface The problem is that to be general, and as you noted, this test =20 depends on a knowledge of all formats used to embed IPv4 addresses in =20= IPv6 addresses. When a new format is introduced, a security weakness =20 therefore holds until all relays are upgraded to support it. Besides, and more important, some formats may use _ISP dependent =20 prefixes_ (and 6rd is already in this case!). These formats cannot be =20= recognized by a constant code. This being noted, I agree that, to extend applicability of 6rd relays =20= to cases where ingress filtering doesn't apply, and to deal more =20 simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd =20 relays SHOULD do as you propose: *In 6rd relays, packets received on the IPv4 side should be discarded =20= if their IPv6 destinations are 6to4 addresses containing the ISP 6rd =20 anycast address.* > > This way all the checks are done only at the 6rd relay and not in =20 > other IPv4 border routers of the ISP which should not be aware of =20 > the 6rd deployment. Note that IPv4 border routers of the ISP need not to be aware of the =20 6rd in particular. They only have to make sure that ingress filtering "in general" =20 applies to packets sent toward the global Internet. (If their downstream neighbors do ingress filtering as they should, =20 these border routers have nothing specific to do. In cases where this =20= isn't sure though, they should better prevent source address spoofing =20= by filtering themselves source addresses for which they have no =20 reverse path.) > > > > (2) Case of ISPs that operate 6rd relays AND 6to4 relays (but =20 > neither Teredo relays nor ISP-infrastructure NATs) > > In its sec. 5 on security, draft-despres-6rd-03 says: > <<< > o RELAY PACKETS TOWARD THE INTERNET: The IPv6 source must be a 6rd > address that matches the IPv4 source. The IPv6 destination must > not start with the ISP 6rd prefix. > ... > o RELAY PACKETS FROM THE INTERNET: The IPv6 source must not be a =20= > 6rd > address of the ISP. The IPv4 destination must not be multicast, > i.e. must not start with 224/3... > >>> > > In view of your study and in my understanding, it MUST be completed =20= > with: > - after the first quoted paragraph: > "Furthermore, if the ISP also operates 6to4 relays that advertise =20 > on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source =20= > must be neither the 6to4 anycast address 192.88.99.0 nor any of its =20= > equivalent IPv4 unicast addresses." > - after the second quoted paragraph: > "Furthermore, if the ISP also operates 6to4 relays that advertise =20 > on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 =20 > destination derived from the IPv6 destination must be neither the =20 > IPv4 anycast address 192.88.99.0 nor any of its equivalent IPv4 =20 > unicast addresses." > > Actually, I believe that the precautions I suggested above will =20 > work here also instead of those checks. Won't they? As explained above, it would be 100% safe only if all embedded IPv4 =20 addresses were guaranteed to be recognized, which is not the case. > In general, I think that checks performed on the destination =20 > address (IPv4 or IPv6) should be more robust than checks on a =20 > source address. In my understanding, not always. Each scenario has to be studied for what it is. > > > With this, an ISP that operates both 6rd and 6to4 relays is also =20 > immune to the routing-loop attack because: > - an IPv6 packet forwarded to the global Internet by 6rd relays can =20= > come back to the ISP IPv4 network via one of the 6to4 relays of the =20= > ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source =20 > address is then one of a 6to4 relay, which, with the first added =20 > sentence, prevents it from being accepted by the 6rd relay. > - an IPv6 packet received from the IPv6 Internet by a 6rd relay =20 > cannot be sent back to the IPv4 global Internet via one of the 6to4 =20= > relays: the IPv4 address derived from its IPv6 destination would =20 > have for this to be one of a 6to4 relays, which, with the second =20 > added sentence, prevents it from being forwarded by the 6rd relay. > > Note: RFC 3068, where the 6to4 anycast address is introduced, says =20 > that "each 6to4 relay router that advertise the 6to4 anycast prefix =20= > MUST also provide an equivalent IPv4 unicast address". Whether this =20= > is really important in practice is IMHO unclear. On the other hand, =20= > if this MUST is dispensed with, the above security precaution can =20 > be implemented in 6rd relays without a need to handle a variable =20 > number of addresses, and to administratively configure them (with =20 > the associated risks of human errors). > > > If you do the check on the destination address you can avoid this =20 > administrative configuration altogether. Agreed for packets forwarded to the IPv6 side (see above). Now, for packets from the IPv6 Internet, rather than checking that =20 the embedded IPv4 destination has one of the ISP allocated prefixes, =20 there is a better check I hadn't seen before sending the previous e-=20 mail: *In 6rd relays, packets received on the IPv6 side should be discarded =20= if their source addresses are 6to4 addresses containing the ISP 6rd =20 anycast address.* The above administrative configuration is thus unnecessary, and the =20 6rd relay cannot participate in a routing loop attack even if its ISP =20= also operates 6to4 relays. NOTE: As a matter of fact, a source address check can also be used to =20= improve the Mitigation Measures you proposed for 6to4, ISATAP and =20 Teredo relays: *In your three forwarding conditions, it would be sufficient to add =20 "or source" after each occurrence of "destination".* Thus, each of these relays becomes protected against rooting loop =20 attacks via any other 6to4, ISATAP, and Teredo relay, even if this =20 relay doesn't make the new check on destination addresses. > > > To conclude: > - Without needing to modify 6to4 relays, ISATAP relays, and Teredo =20 > relays, ISPs that support 6rd and don't support 6to4 appear to be =20 > already protected against routing loop attacks if ingress filtering =20= > is operational at their interfaces to the IPv4 global Internet. =20 > With an additional simple precaution in 6rd relays, they can also =20 > be immune in the absence of such filtering. > > I fully agree. Thanks. Thoughts on the proposal to improve your mitigation measures? Regards, RD > > - A necessary additional security precaution against routing-loop =20 > attacks is now identified for ISPs that support 6rd and that, =20 > having started with 6to4, wish to keep it for backward =20 > compatibility. Thanks again for your analysis which made it possible. > > > Best regards, > RD > > > > Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit : > > > Hi all, > > I would like to draw the attention of the list to some research =20 > results which my colleague and I at the National EW Research & =20 > Simulation Center have recently published. The research presents a =20 > class of routing loop attacks that abuses 6to4, ISATAP and Teredo. =20 > The paper can be found at: http://www.usenix.org/events/woot09/tech/=20= > full_papers/nakibly.pdf > > > > Here is the abstract: > > IPv6 is the future network layer protocol for the Internet. Since =20= > it is not compatible with its predecessor, some interoperability =20 > mechanisms were designed. An important category of these mechanisms =20= > is automatic tunnels, which enable IPv6 communication over an IPv4 =20 > network without prior configuration. This category includes ISATAP, =20= > 6to4 and Teredo. We present a novel class of attacks that exploit =20 > vulnerabilities in these tunnels. These attacks take advantage of =20 > inconsistencies between a tunnel's overlay IPv6 routing state and =20 > the native IPv6 routing state. The attacks form routing loops which =20= > can be abused as a vehicle for traffic amplification to facilitate =20 > DoS attacks. We exhibit five attacks of this class. One of the =20 > presented attacks can DoS a Teredo server using a single packet. =20 > The exploited vulnerabilities are embedded in the design of the =20 > tunnels; hence any implementation of these tunnels may be =20 > vulnerable. In particular, the attacks were tested against the =20 > ISATAP, 6to4 and Teredo implementations of Windows Vista and =20 > Windows Server 2008 R2. > > > > I think the results of the research warrant some corrective =20 > action. If this indeed shall be the general sentiment of the list, =20 > I will be happy write an appropriate I-D. The mitigation measures =20 > we suggested in the paper are the best we could think of to =20 > completely eliminate the problem. However they are far from perfect =20= > since they would require tunnel implementations to be updated in =20 > case new types of automatic tunnels are introduced. > > > > Your comments are welcome. > > > > Gabi > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > From hartmans@mit.edu Fri Aug 21 03:46:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25DE3A6BBE; Fri, 21 Aug 2009 03:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFPkaXpZt5Ts; Fri, 21 Aug 2009 03:46:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id DCF483A67E6; Fri, 21 Aug 2009 03:46:46 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5157A64492; Fri, 21 Aug 2009 06:46:49 -0400 (EDT) To: secdir@ietf.org,iesg@ietf.org From: Sam Hartman Date: Fri, 21 Aug 2009 06:46:49 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-mext-aero-reqs@tools.ietf.org, mext-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 10:46:47 -0000 This is a security directorate review; editors should treat these comments as any other last call comments. Sorry that the review is late. I read the draft, prepared my comments and failed to send them out. This draft describes requirements from the air and space communities for nemo route optimization for aircraft and spacecraft. Within that scope, I have no additional security concerns. However it is important to make sure that everyone involved understands meeting these requirements alone without more general security requirements would not produce an acceptable solution. If the intent of this draft is to state all the requirements that mext needs to consider in developing a solution that meets IETF standards and that meets the needs of the air/space community, then it falls significantly short. I don't think that is the intent though; I think this is simply intended to be one stakeholder's input. Presumably, even if we are only targeting deployment in air/space enviroments, we will look at more general security and management requirements necessary to make the technology deployable on the internet. If we're all on the same page on that point, then this draft is fine. I think the stated requirements seem reasonable. However, I'm not actually sure that a solution exists as an extension to current basic nemo. In particular, requirements about minimizing or avoiding custom software may rule out nemo. However, perhaps I'm missing something. From dharkins@lounge.org Fri Aug 21 14:46:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393A03A6B9D; Fri, 21 Aug 2009 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJan8zm14Hip; Fri, 21 Aug 2009 14:46:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6E9A03A6831; Fri, 21 Aug 2009 14:46:42 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2C93010224074; Fri, 21 Aug 2009 14:46:48 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 21 Aug 2009 14:46:48 -0700 (PDT) Message-ID: <5305e23ba28df21e566bb8be04961f80.squirrel@www.trepanning.net> Date: Fri, 21 Aug 2009 14:46:48 -0700 (PDT) From: "Dan Harkins" To: secdir@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: edguy@emcsw.com, iesg@ietf.org, enum-chars@ietf.org Subject: [secdir] review of draft-ietf-enum-iax-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 21:46:43 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-enum-iax-05 registers the Inter-Asterisk eXchange (IAX) protocol according to the guidelines specified in ENUM (RFC 3751). The registration requirements of RFC 3751 specify that a registration proposal must have a security analysis and this draft says: "this Enumservice provides another fact, visible to anyone anonymously, that may be harvested and possibly exploited." While this is correct I think it would be better use to the language of RFC 3751 section 3.1.3(2) and say something like: "the protocol provides for disclosure of information that may facilitate an attack or a violation of user privacy in some way." Also, this draft has a typo in section 4: RFC 3822 should be RFC 3833. Other than that, I have no problems with the draft's security considerations. regards, Dan. From hartmans@mit.edu Fri Aug 21 18:40:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D823E3A68BE; Fri, 21 Aug 2009 18:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrPlauMZx5C2; Fri, 21 Aug 2009 18:40:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 110093A6B73; Fri, 21 Aug 2009 18:40:35 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 391FB64631; Fri, 21 Aug 2009 21:40:40 -0400 (EDT) To: "Davis\, Terry L" References: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> From: Sam Hartman Date: Fri, 21 Aug 2009 21:40:40 -0400 In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> (Terry L. Davis's message of "Fri\, 21 Aug 2009 15\:48\:55 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "mext-chairs@tools.ietf.org" , "secdir@ietf.org" , 'Sam Hartman' , "iesg@ietf.org" , "draft-ietf-mext-aero-reqs@tools.ietf.org" , "weddy@grc.nasa.gov" , "'Ivancic, William D. \(GRC-RHN0\)'" Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 01:40:36 -0000 >>>>> "Davis," == Davis, Terry L writes: Davis,> Sam One of the items that continues to seriously concern Davis,> me across the whole IP protocol RFC set is the basic lack Davis,> of simple vendor-to-vendor IP security interoperability! Davis,> All of NEMO and MEXT assumes that simple, easy to Davis,> implement, IPSec, PKI, and IKE interoperability exist; Davis,> they do NOT. With you so far. Davis,> In aviation we do not have the luxury that Enterprise or Davis,> Entity organizations have in being able to deploy "single Davis,> vendor" solutions! In the aviation space, if someone made Davis,> one, aviation will have it somewhere in our infrastructure Davis,> and we need to interoperate with it as our aircraft Davis,> operate in a truly heterogeneous global space. An Davis,> aircraft in flight will usually 1 to 4 open communications Davis,> links and these will be continuously changing as we hand Davis,> off between communication providers and "Navigation Davis,> Service Providers" who utilize entirely different vendors Davis,> and PKIs. I think the rest of the world is much more similar to this than you believe. Davis,> Nor can we have a "single PKI" global solution; Davis,> nation/state laws preclude this in many cases as they Davis,> reasonably require credentials that they control for Davis,> authentication in their territory and bridge assurances, Davis,> although fine for business level relationships, may Davis,> reasonably not meet nation/state requirements for Davis,> operations within their nation. Davis,> I continue to state that the lack of easy to use/configure Davis,> vendor interoperability parameters for our basic IP Davis,> security protocol associations is a major failure in of Davis,> Internet architectures. It cannot require a senior Davis,> network engineer, a senior PKI analyst, and dozens of Davis,> Wireshark traces to establish a secure link! Entry level Davis,> engineers/analysts and techs need to be able to perform Davis,> this function as we do with basic network (DHCP) Davis,> connectivity. We need a "dynamic security association Davis,> protocol" like DHCP for industries like aviation (and most Davis,> the CI sectors too!). Davis,> To me, this lack of a simple, easy to use, Davis,> interoperability security association configuration is one Davis,> of our most pressing issues in our efforts to establish Davis,> "cyber space security" regardless of what CI sector we are Davis,> looking at. I think I'm in general agreement with you. However I don't see how any of this applies to my comments--unless possibly you are saying that the draft needs to be expanded with additional security requirements. From weiler+secdir@watson.org Sat Aug 22 08:39:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957503A68B8 for ; Sat, 22 Aug 2009 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn3QynEh9+NY for ; Sat, 22 Aug 2009 08:39:23 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 6BFE63A67EA for ; Sat, 22 Aug 2009 08:39:04 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n7MFd9Ip050531 for ; Sat, 22 Aug 2009 11:39:09 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n7MFd8CN050528 for ; Sat, 22 Aug 2009 11:39:09 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 22 Aug 2009 11:39:08 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Sat, 22 Aug 2009 11:39:09 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 15:39:24 -0000 Eric Rescorla is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, particularly the one on September 10th, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Several of the docs on that September 10th telechat are being assigned for the first time today. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-08-27 Reviewer Deadline Draft Rob Austein T 2009-08-25 draft-ietf-opsawg-syslog-alarm-02 Stephen Farrell T 2009-08-25 draft-ietf-ippm-multimetrics-11 David Harrington T 2009-08-25 draft-ietf-simple-xcap-diff-13 Love Hornquist-Astrand T 2009-08-25 draft-ietf-bmwg-mpls-forwarding-meth-05 Jeffrey Hutzelman T 2009-08-25 draft-ietf-mext-binding-revocation-10 Hilarie Orman TR2009-08-25 draft-ietf-ospf-hmac-sha-06 Glen Zorn T 2009-08-25 draft-ietf-ntp-dhcpv6-ntp-opt-04 For telechat 2009-09-10 Reviewer Deadline Draft Barry Leiba TR2009-09-08 draft-ietf-sipping-service-identification-03 Catherine Meadows T 2009-09-08 draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10 Russ Mundy T 2009-09-08 draft-ietf-hip-nat-traversal-08 Magnus Nystrom T 2009-09-08 draft-ietf-pcn-baseline-encoding-05 Hilarie Orman T 2009-09-08 draft-ietf-pwe3-segmented-pw-13 Joe Salowey TR2009-09-08 draft-ietf-sipping-service-identification-03 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-02 Phillip Hallam-Baker 2009-08-18 draft-ietf-pmol-sip-perf-metrics-03 Steve Hanna 2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04 Paul Hoffman 2009-08-31 draft-ietf-eai-imap-utf8-07 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman 2009-06-29 draft-ietf-ipsecme-ikev2-redirect-13 Charlie Kaufman 2009-08-31 draft-ietf-mpls-3209-patherr-05 Scott Kelly 2009-08-31 draft-ietf-mpls-gmpls-lsp-reroute-04 Stephen Kent 2009-08-31 draft-ietf-mpls-soft-preemption-18 Tero Kivinen 2009-08-28 draft-ietf-sipcore-presence-scaling-requirements-01 Julien Laganier 2009-01-22 draft-ietf-sip-certs-08 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Barry Leiba 2009-09-17 draft-iana-ipv4-examples-01 Chris Lonvick 2009-09-17 draft-daboo-srv-email-02 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy 2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-13 Sandy Murphy 2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05 Radia Perlman 2009-09-04 draft-ietf-rtgwg-lf-conv-frmwk-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-07-25 draft-ietf-pkix-ta-format-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Nico Williams 2009-08-04 draft-ietf-dime-nai-routing-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-03 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 From stephen.farrell@cs.tcd.ie Sun Aug 23 10:33:32 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EBD3A6B8F for ; Sun, 23 Aug 2009 10:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXYsXoqowZbb; Sun, 23 Aug 2009 10:33:31 -0700 (PDT) Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by core3.amsl.com (Postfix) with ESMTP id B39EC3A635F; Sun, 23 Aug 2009 10:33:31 -0700 (PDT) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 1695B476B; Sun, 23 Aug 2009 18:33:36 +0100 (IST) Received: from [10.87.48.11] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n7NHXXbl012587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Aug 2009 18:33:34 +0100 Message-ID: <4A917D6E.7060205@cs.tcd.ie> Date: Sun, 23 Aug 2009 18:33:34 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-ippm-multimetrics@tools.ietf.org, ippm-chairs@tools.ietf.org, sec-ads@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 48519566 - e572010a579a (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Subject: [secdir] secdir review of draft-ietf-ippm-multimetrics X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 17:33:32 -0000 Hi, This is a security directorate review; editors should treat these comments as any other last call comments. The draft defines new "spatial" and multi-party metrics. 1. The security considerations section refers to the same section in RFCs 2679, 2680 (are those identical?), 3393 and 3432. Those are all pretty brief (~3 paragraphs) and don't really say much. Presumably this was considered ok when those were produced so if the ADs are happy that that remains the case, then its ok that this draft refers to those as if they were more detailed than they are. 2. If I am a point of interest presumably I could send bad results in order to attempt to get someone to reconfigure the network so as to offer me better service or give someone else worse service. I would think that that may warrant a specific mention as a security consideration. The current text doesn't seem to cover that and I guess I'd argue that this is more likely for a one-to-group measurement. Regards, Stephen. Editorial/Nits: - Are the "x" and "X" characters different in Figure 2? I think they are, but the legend only mentions the "x" as not being of interest. Maybe use Y/N instead but do say if the "X" (or "Y") are of interest. - The acronym ipdv is used without expansion in section 3. - 5.1.5 s/DTi+1/dTi+1/ - 5.2 s/from the section 2/from section 2/ - 8.0 s/This kind of statistics/This kind of statistic/ or /These kinds of statistics/ - 8.1 s/The packet loss/Packet loss/ (There are a number of such language changes that should be made.) - 10.4 In the informationm model should hosts_serie be hosts_series? (same for other xxx_serie elements) From terry.l.davis@boeing.com Fri Aug 21 15:51:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96773A69EA; Fri, 21 Aug 2009 15:51:25 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e+WyeXAt3F8; Fri, 21 Aug 2009 15:51:25 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E34513A6826; Fri, 21 Aug 2009 15:51:24 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7LMmvdW000483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Aug 2009 15:48:57 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7LMmuad003178; Fri, 21 Aug 2009 15:48:56 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7LMmuMi003171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 21 Aug 2009 15:48:56 -0700 (PDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 21 Aug 2009 15:48:55 -0700 From: "Davis, Terry L" To: "'Sam Hartman'" , "secdir@ietf.org" , "iesg@ietf.org" , "'Ivancic, William D. (GRC-RHN0)'" , "weddy@grc.nasa.gov" Date: Fri, 21 Aug 2009 15:48:55 -0700 Thread-Topic: secdir review of draft-ietf-mext-aero-reqs8 Thread-Index: AcoiTLmXRs1VNJUrSkqOzFTnBn2IdQAXvPzA Message-ID: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-3.800.1026-15056.000 x-tm-as-result: No--61.881900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 24 Aug 2009 00:40:35 -0700 Cc: "draft-ietf-mext-aero-reqs@tools.ietf.org" , "mext-chairs@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 22:51:26 -0000 Sam One of the items that continues to seriously concern me across the whole IP= protocol RFC set is the basic lack of simple vendor-to-vendor IP security = interoperability! All of NEMO and MEXT assumes that simple, easy to implem= ent, IPSec, PKI, and IKE interoperability exist; they do NOT. In aviation we do not have the luxury that Enterprise or Entity organizatio= ns have in being able to deploy "single vendor" solutions! In the aviation= space, if someone made one, aviation will have it somewhere in our infrast= ructure and we need to interoperate with it as our aircraft operate in a tr= uly heterogeneous global space. An aircraft in flight will usually 1 to 4 = open communications links and these will be continuously changing as we han= d off between communication providers and "Navigation Service Providers" wh= o utilize entirely different vendors and PKIs. =20 Nor can we have a "single PKI" global solution; nation/state laws preclude = this in many cases as they reasonably require credentials that they control= for authentication in their territory and bridge assurances, although fine= for business level relationships, may reasonably not meet nation/state req= uirements for operations within their nation. I continue to state that the lack of easy to use/configure vendor interoper= ability parameters for our basic IP security protocol associations is a maj= or failure in of Internet architectures. It cannot require a senior networ= k engineer, a senior PKI analyst, and dozens of Wireshark traces to establi= sh a secure link! Entry level engineers/analysts and techs need to be able= to perform this function as we do with basic network (DHCP) connectivity. = We need a "dynamic security association protocol" like DHCP for industries= like aviation (and most the CI sectors too!). =20 To me, this lack of a simple, easy to use, interoperability security associ= ation configuration is one of our most pressing issues in our efforts to es= tablish "cyber space security" regardless of what CI sector we are looking = at. Take care Terry PS: I might also remind the IETF that DHCP came from commerical industry de= velopment not communications or academia. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Friday, August 21, 2009 3:47 AM > To: secdir@ietf.org; iesg@ietf.org > Cc: mext-chairs@tools.ietf.org; draft-ietf-mext-aero-reqs@tools.ietf.org > Subject: secdir review of draft-ietf-mext-aero-reqs8 >=20 >=20 >=20 > This is a security directorate review; editors should treat these > comments as any other last call comments. >=20 > Sorry that the review is late. I read the draft, prepared my comments > and failed to send them out. >=20 > This draft describes requirements from the air and space communities > for nemo route optimization for aircraft and spacecraft. >=20 > Within that scope, I have no additional security concerns. >=20 > However it is important to make sure that everyone involved > understands meeting these requirements alone without more general > security requirements would not produce an acceptable solution. If > the intent of this draft is to state all the requirements that mext > needs to consider in developing a solution that meets IETF standards > and that meets the needs of the air/space community, then it falls > significantly short. I don't think that is the intent though; I think > this is simply intended to be one stakeholder's input. Presumably, > even if we are only targeting deployment in air/space enviroments, we > will look at more general security and management requirements > necessary to make the technology deployable on the internet. If we're > all on the same page on that point, then this draft is fine. >=20 > I think the stated requirements seem reasonable. However, I'm not > actually sure that a solution exists as an extension to current basic > nemo. In particular, requirements about minimizing or avoiding custom > software may rule out nemo. However, perhaps I'm missing something. From secdir-bounces@mit.edu Sat Aug 22 08:53:49 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0453A6C72 for ; Sat, 22 Aug 2009 08:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=-2.352, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5SiRDeamFx0 for ; Sat, 22 Aug 2009 08:53:48 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 5883A3A6C67 for ; Sat, 22 Aug 2009 08:53:48 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7MFrrVr014938 for ; Sat, 22 Aug 2009 11:53:53 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7MFrqHP014935 for ; Sat, 22 Aug 2009 11:53:53 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7MFrX7j003854 for ; Sat, 22 Aug 2009 11:53:33 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 177F823F3A7D for ; Sat, 22 Aug 2009 11:53:32 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id XjToEmTl4YNzIcI0 for ; Sat, 22 Aug 2009 11:53:32 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15FE43A6B8C; Sat, 22 Aug 2009 08:53:26 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447A33A6BB1 for ; Tue, 18 Aug 2009 10:16:31 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mflaYWFpNb4Y for ; Tue, 18 Aug 2009 10:16:30 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 6F69A3A6B28 for ; Tue, 18 Aug 2009 10:16:30 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MdSIO-00051c-6U for public-new-work-dist@listhub.w3.org; Tue, 18 Aug 2009 17:16:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MdSIN-00050w-Ai for public-new-work@listhub.w3.org; Tue, 18 Aug 2009 17:16:27 +0000 Received: from ssh.w3.org ([128.30.52.60] helo=homer.w3.org) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MdSIE-000670-KR; Tue, 18 Aug 2009 17:16:26 +0000 Received: from [IPv6:::1] (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id D88EA4EEFF; Tue, 18 Aug 2009 13:16:17 -0400 (EDT) Message-Id: From: Ian Jacobs To: Ian Jacobs In-Reply-To: Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 18 Aug 2009 12:16:17 -0500 References: X-Mailer: Apple Mail (2.935.3) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: maggie.w3.org 1MdSIE-000670-KR 02cf3b0526168d7734edc2efc15c87a2 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/48 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 18 Aug 2009 17:16:28 +0000 X-Mailman-Approved-At: Sat, 22 Aug 2009 08:53:24 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 24 Aug 2009 00:40:35 -0700 Cc: public-new-work@w3.org Subject: [secdir] [New-work] Deadline extended [Was: Proposed W3C Charter: RDB2RDF Working Group (until 2009-08-15)] X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 15:53:49 -0000 On 25 Jun 2009, at 1:37 PM, Ian Jacobs wrote: > Hello, > > Today W3C Advisory Committee Representatives received a Proposal > to revise the Semantic Web Activity [0] (see the W3C Process > Document description of Activity Proposals [1]). This proposal > includes a draft charter for the RDB2RDF Working Group: > http://www.w3.org/2009/03/rdb2rdf-charter > > As part of ensuring that the community is aware of proposed work > at W3C, this draft charter is public during the Advisory > Committee review period. > > W3C invites public comments through 2009-08-15 on the > proposed charter. Please send comments to > public-new-work@w3.org, which has a public archive: > http://lists.w3.org/Archives/Public/public-new-work/ Because this is the vacation period, we have extended the review deadline to 26 August. _ Ian Jacobs, Head of W3C Communications > > Other than comments sent in formal responses by W3C Advisory > Committee Representatives, W3C cannot guarantee a response to > comments. If you work for a W3C Member [2], please coordinate > your comments with your Advisory Committee Representative. For > example, you may wish to make public comments via this list and > have your Advisory Committee Representative refer to it from his > or her formal review comments. > > If you should have any questions or need further information, please > contact Ivan Herman, Semantic Web Activity Lead . > > Thank you, > > Ian Jacobs, Head of W3C Communications > > [0] http://www.w3.org/2001/sw/ > [1] > http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation > [2] http://www.w3.org/Consortium/Member/List > > > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 > -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From jari.arkko@piuha.net Mon Aug 24 03:48:32 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA5928C1F1; Mon, 24 Aug 2009 03:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukFP0lB8Yiva; Mon, 24 Aug 2009 03:48:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F34828C1EF; Mon, 24 Aug 2009 03:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89D3C198698; Mon, 24 Aug 2009 13:48:37 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJhJaMzWl6xW; Mon, 24 Aug 2009 13:48:37 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8BDE8198653; Mon, 24 Aug 2009 13:48:36 +0300 (EEST) Message-ID: <4A927003.7050004@piuha.net> Date: Mon, 24 Aug 2009 13:48:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mext-aero-reqs@tools.ietf.org, mext-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 10:48:32 -0000 Thanks for your review, Sam. A few responses below: > However it is important to make sure that everyone involved > understands meeting these requirements alone without more general > security requirements would not produce an acceptable solution. If > the intent of this draft is to state all the requirements that mext > needs to consider in developing a solution that meets IETF standards > and that meets the needs of the air/space community, then it falls > significantly short. I don't think that is the intent though; I think > this is simply intended to be one stakeholder's input. Presumably, > even if we are only targeting deployment in air/space enviroments, we > will look at more general security and management requirements > necessary to make the technology deployable on the internet. If we're > all on the same page on that point, then this draft is fine. > You raise a valid point and I think we have it under control. But its actually a bit more complicated than what you state above. I have treated the document as an input from a particular stakeholder's perspective. I have assumed that there are more general protocol design and even security aspects that an actual solution should take into account. However, I do not necessarily believe that there is a single NEMO route optimization solution that should cater for everyone's needs. The group's charter was written with the assumption that there are different use cases and that their solutions might be different. For instance, federated tunnel servers advertising the same BGP space is likely a good match for the aeronautics requirements, as it can solve the continental dogleg routing problem. Its not clear that this solution solve every other application's NEMO RO problems, however. So, if and when we actually design a solution, I'd like that solution to be generally usable and be able to run on the Internet as well as in a closed ATC network. But the solution will probably still be limited to a particular type of movements, and be able to address only some of the needs for NEMO RO. Note that the group is probably not unanimous in these beliefs; at least in the past we've seen arguments favoring the construction of a solution that can handle everything. I just don't personally believe this is achievable. > I think the stated requirements seem reasonable. However, I'm not > actually sure that a solution exists as an extension to current basic > nemo. In particular, requirements about minimizing or avoiding custom > software may rule out nemo. However, perhaps I'm missing something. > The document obviously prefers solutions where as small number of components as possible is touched. However, I do not remember a statement that says no software is allowed (but maybe I missed it). In fact, you would assume that for any sort of route optimization, you have to touch at least your router. The document says: "The MRs and MNNs onboard a spacecraft are highly-customized computing platforms, and adding custom code or complex configurations in order to obtain NEMO RO capabilities is feasible, ... Since for ATS, the MRs and MNNs are under regulatory control and are actively tested and maintained, it is not completely unreasonable to assume that special patches or software be running on these devices to enable NEMO RO. In fact, since these devices are accessed by skilled technicians and professionals, it may tolerable be if some special configuration is required for NEMO RO. Of course simplicity in setup and configuration is highly preferable, however, and the desirable feature labeled "Des1" below in this document prefers solutions with lower configuration state and overhead. To minimize costs of ownership and operations, it is also highly desirable for only widely-available off-the-shelf operating systems or network stacks to be required, but not a full requirement. ... it is desirable that a NEMO RO solution be as simple to configure as possible ..." Jari From gnakibly@yahoo.com Mon Aug 24 04:44:26 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E483A6971 for ; Mon, 24 Aug 2009 04:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56V5bPd94Wli for ; Mon, 24 Aug 2009 04:44:24 -0700 (PDT) Received: from web45510.mail.sp1.yahoo.com (web45510.mail.sp1.yahoo.com [68.180.197.134]) by core3.amsl.com (Postfix) with SMTP id 3DC653A69E5 for ; Mon, 24 Aug 2009 04:43:53 -0700 (PDT) Received: (qmail 90224 invoked by uid 60001); 24 Aug 2009 11:43:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251114237; bh=vuHLAbMSy6zcbOoUueqA8TbzU4ESksA1bW4qjYizY94=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xKeV/jtHNS/f/hLhHsb3IOKerKznaTIp9L+deKIrkFgP95zJu953jKCUwo8iuM2hWUMTwQct2ISGHjmYm4xUbehap8Qc4HkDftzQ2rhsiOaCzlNUCWSepVlgN5krgpfWfILOhfeuoNXy6ELcoTqfYxAP07Ozs6t/0BQZ/BVCO3c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=29SXcpI/dE7VEX1uZ3TiRtGpW4rjGvlk/IoI6dj7zfHiykH6sMk9Bk0iOl+TvtiCwjnEFO/ofh2cPPsZ0uaHuq7I1SVaikPIhUQmFHytixfohiOjyEu6HUY+WsOyE3bppr/r9BDV6Q70QRTO1FDs+IyJhIPCGWIb6eQ9GfqnyEY=; Message-ID: <475898.88672.qm@web45510.mail.sp1.yahoo.com> X-YMail-OSG: 0EOTXdEVM1nkTG9q3rRXGw8pcJXBRe20k0bI4xL18xpIzKwMJxJXXWeyXCGM_b05YDw7dkJKDmBsQSl4JoG_eoOzE_xnSu.wDNU7qQwsXHEttAcLUBefiS4pYs5PFvH2777deG1P2M6vAwmok5P.0pc1pojD8nVdY65iC.V7knheRYReF4k0BEnz4C9Qbp02yvsSYagsjTozD22bWV63y2xbyWqRYkYFTQ8XfUabbwP6YOhHccrTqu2hoe5bm0RSNGMvKDJHadjvsPjjgGs- Received: from [89.139.41.78] by web45510.mail.sp1.yahoo.com via HTTP; Mon, 24 Aug 2009 04:43:57 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Mon, 24 Aug 2009 04:43:57 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:44:26 -0000 Fred,=0AI=A0initially very much=A0liked your suggestion regarding the check= =A0of the neighbor cache before forwarding a packet into the tunnel.=A0It t= ruly addresses the root cause of the problem ans is simple enough to implem= ent. However, I realized that an attacker can send a spoofed=A0RS to the IS= ATAP router as if it came from the 6to4 relay. The router would then send= =A0a RA=A0to it=A0and consequently change its neighbor cache. So it seems= =A0that this defense does not add much.=A0Wouldn't you agree?=A0=0A=A0=0AI = completely agree with your observation on the non-feasibility of verifying= =A0that the destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the ISATAP address may include a private IPv4 address. On t= he other hand, a check on public IPv4 addresses is acceptable.=A0If the che= ck would be done only on ISATAP addresses that include public IPv4 addresse= s then this will eliminate the attacks in which the two victims reside=A0at= different sites. Note that if attack #3=A0is launched on two ISATAP router= s=A0having private addresses at two different sites then the attack will no= t work anyway since one router can not send a direct=A0IPv4 packet to the o= ther. In addition, to=A0mitigate attacks in which the other victim is a 6to= 4 relay (such as attack #1) then a check would have to be done on a 6to4 ad= dress, i.e. the destination address must not be "2002:::*". In this case the IPv4 address must be public, according= to the 6to4 spec.=0A=A0=0AAs you also noted there is another problem with thi= s check since the string "200::5EFE" is not unique to ISATAP links. On the = other hand, it seems that the probability to encounter a non-malicious pack= et with a destination address having an IID that equals "200:5EFE:" is pretty slim.=0A=A0=0AThis check is definitely not a= =A0perfect solution, and I sure hope that someone will come up with a bette= r one for mitigating the routing loops. However, I would be happy if there = is some kind of other mitigation=A0measures besides packet filtering=A0(pro= to-41 and ingress) by=A0other nodes (which=A0does not necessarily exist). = =0A=A0=0AGabi=0A=A0=0A----- Original Message ----=0AFrom: "Templin, Fred L"= =0ATo: Gabi Nakibly ; v6ops= =0ACc: ipv6@ietf.org; secdir@ietf.org=0ASent: Wednesda= y, August 19, 2009 6:16:18 PM=0ASubject: RE: Routing loop attacks using IPv= 6 tunnels=0A=0AHi Gabi,=0A=0AI'm sorry to have to keep turning this into pl= aintext,=0Abut annotation is difficult otherwise. See below for=0Amy respon= ses (=3D=3D>):=0A=0A________________________________________=0AFrom: Gabi N= akibly [mailto:gnakibly@yahoo.com] =0ASent: Wednesday, August 19, 2009 1:49= AM=0ATo: Templin, Fred L; v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASub= ject: Re: Routing loop attacks using IPv6 tunnels=0A=0AFred,=0ASee my comme= nts inline ().=0A=0A________________________________________=0AFrom: "T= emplin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org= =0ASent: Tuesday, August 18, 2009 6:48:45 PM=0ASubject: RE: Routing loop at= tacks using IPv6 tunnels=0A=0AGabi,=0A=0A__________________________________= ______=0AFrom: Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Tuesday, A= ugust 18, 2009 3:29 AM=0ATo: Templin, Fred L; v6ops=0A> Cc: ipv6@ietf.org; = secdir@ietf.org=0A> Subject: Re: Routing loop attacks using IPv6 tunnels=0A= > =0A> Indeed the ISATAP interface of the ISATAP router is meant=0A> to be = an enterprise-interior (note that=A0it is still=A0assumed=0A> that the asso= ciated IPv4 address is=A0non-private). As=A0we=0A> explicitly note in the p= aper, the first three attacks=A0will=0A> be mitigated=A0if proper protocol-= 41 filtering is deployed on=0A> the site's border. However, note that RFC52= 14 does not mandate=0A> or require this filtering.=0A=0AThe RFC5214 Securit= y Considerations makes clear the=0Aconsequences of not implementing IPv4 in= gress filtering=0Aand ip-protocol-41 filtering (i.e., a possible spooing=0A= attack in which spurious ip-protocol-41 packets are=0Ainjected into an ISAT= AP link from outside). RFC5214=0ASection 6.2 additionally requires that an = ISATAP interface's=0Alocator set MUST NOT span multiple sites. This means t= hat the=0AISATAP interface must not decapsulate nor source ip-proto-41=0Apa= ckets within multiple sites, where the enterprise interior=0Ais site #1 and= the global Internet is site #2. ip-protocol-41=0Afiltering is the way in w= hich the ISATAP interface is=0Arestricted to a single site. =0A=0ANow l= et me see that I understand Section 6.2 correctly. In=0Aattack #2, for exam= ple, I assume the ISATAP router has two=0Aphysical interfaces. A site-inter= nal IPv4 interface with an=0Aaddress IPisatap and a site-external IPv6 inte= rface. I also=0Aassume that there=A0is another border router which connects= the=0Asite to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0Ainter= face with a single locator: (IPisatap, site-internal=0Ainterface).=A0When t= he ISATAP router gets an IPv6 via its=0Aexternal interface it will encapsul= ate the packet accordingly=0Aand forward it through the internal IPv4 inter= face. If the=0Aencapsulated packet is=A0destined to a node outside the site= =0Athen the only thing that stops it is=A0a proto-41 filtering=0Aat the=A0o= ther border router of the site. Did I get this right?=0A=0A=0A=3D=3D> = In this case, yes - the ip-proto-41 filtering is at a=0A=3D=3D> border rout= er. I know of at least one major enterprise=0A=3D=3D> network that does thi= s.=0A=0A> It is only mentioned as a possible mitigation against=0A> incomin= g spurious protocol-41 packets. In addition,=0A> Section 10 of RFC5214 only= mentions=A0ingress not=A0egress=0A> filtering.=A0Hence it=A0will not stop = attack #2.=0A=0AWe are now talking about ip-proto-41 filtering; not ingress= =0Afiltering. ip-proto-41 filtering is in both directions. It=0Aprevents ip= -proto-41 packets from entering the enterprise=0Ainterior ISATAP site from = the Internet and prevents=0Aip-proto-41 packets from entering the Internet = ISATAP=0Asite from the enterprise interior. Else the ISATAP=0Ainterface wou= ld span multiple sites.=0A=0ABesides, "ingress" filtering is not about pack= ets coming=0Afrom the Internet into the end site, but rather it is=0Aabout = packets leaving the end site and going out into=0Athe Internet. RFC2827 (BC= P38) documents ingress filtering.=0A=0AOK. I see what you are saying he= re.=0A=0A=0A=3D=3D> OK.=0A=0A> In addition,=0A> as mentioned, protocol= -41 filtering is not helpful when=0A> attack #3 is launched on two routers = that reside in the=0A> same site. Note that=A0it=A0may be=A0possible for=A0= the attack=0A> packet=A0to be sourced from outside the site unless proper= =0A> filtering of incoming IPv6 packets is deployed. If the=0A> attacker re= sides in the site, usually ingress filtering=0A> will not be helpful since = it is deployed in general on=0A> the site's border.=0A=0AHere, we have the = ISATAP router in both cases sourcing a=0Apacket from a foreign prefix. =0A<= gn>=0AWell, I do not see how this is correct. In attacks #1 and #3 the ISAT= AP router sources (actually forwards) an IPv6=A0packet with=A0a source addr= ess having=A0the corresponding=A0prefix of the ISATAP tunnel. In attacks #2= and #3 the ISATAP router sources and IPv4 packet with its own IPv4 address= as the source address.=0A=0A=0A=3D=3D> There were a number of errors = in what I said in my last=0A=3D=3D> message, so let me see if I can get it = right here:=0A=3D=3D>=0A=3D=3D> In attacks #1 and #2 there are two cases to= consider. Case=0A=3D=3D> 1 in which a border router separates the 6to4 rel= ay from the=0A=3D=3D> ISATAP router, and case 2 in which no border router s= eparates=0A=3D=3D> the 6to4 relay from the ISATAP router.=0A=3D=3D>=0A=3D= =3D> In attack #1, we have an IPv6 packet with a local source=0A=3D=3D> add= ress entering the site from the outside. IPv6 ingress=0A=3D=3D> filtering a= t the site border router should prevent the=0A=3D=3D> packet from entering = the site in the first place. If the=0A=3D=3D> 6to4 relay router is outside = the site then ip-proto-41=0A=3D=3D> filtering at the border router will blo= ck the attack in=0A=3D=3D> the first place anyway. If the relay router is *= inside*=0A=3D=3D> the site, then the IPv6 ingress filtering is the lone=0A= =3D=3D> mitigation. The end result is that the 6to4 relay should=0A=3D=3D> = really be positioned outside of the site's border routers;=0A=3D=3D> otherw= ise, it could be spoofed into thinking that the=0A=3D=3D> ISATAP router is = a 6to4 router and not an ISATAP router. =0A=3D=3D>=0A=3D=3D> In attack #2, = we have an IPv6 packet with a foreign source=0A=3D=3D> address being forwar= ded by the ISATAP router to a 6to4=0A=3D=3D> relay, but I mis-spoke when I = said that this would be a=0A=3D=3D> case of the ISATAP router forwarding a = packet with a foreign=0A=3D=3D> source address out of the ISATAP link. For = all the ISATAP=0A=3D=3D> router knows, the 6to4 relay is just an ordinary h= ost on=0A=3D=3D> the ISATAP link, so the ISATAP router actually believes it= =0A=3D=3D> is forwarding the packet *into* the ISATAP link (not out of=0A= =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41=0A= =3D=3D> filtering at the border router between the ISATAP router and=0A=3D= =3D> the 6to4 relay. If there is no border router between the ISATAP=0A=3D= =3D> router and the 6to4 relay, then we have an identical instance=0A=3D=3D= > to attack #3 which I will discuss below. But, the best=0A=3D=3D> operatio= nal practice would again be to have the 6to4 relay=0A=3D=3D> oriented outsi= de of a border router that filters ip-proto-41.=0A=3D=3D>=0A=3D=3D> Short s= ummary is that in attack #1, the 6to4 relay thinks it=0A=3D=3D> is talking = to a 6to4 router and not an ISATAP router. In=0A=3D=3D> attack #2, the ISAT= AP router thinks it is talking to a=0A=3D=3D> simple host on the link and n= ot a 6to4 relay. In both cases,=0A=3D=3D> the attacks are mitigated when th= ere is an ip-proto-41=0A=3D=3D> filtering border router between the ISATAP = router and the=0A=3D=3D> 6to4 relay. Oftentimes, the "border router" will b= e a two-=0A=3D=3D> interface router that implements 6to4 on a site-external= =0A=3D=3D> IPv4 interface and implements ISATAP on a site-internal=0A=3D=3D= > IPv4 interface and performs ip-proto-41 filtering on packets=0A=3D=3D> fr= om outside the site with an IPv4 destination corresponding=0A=3D=3D> to the= ISATAP interface. I will discuss attack #3 below:=0A=A0 =A0=0AThis attack = is mitigated by =0AIPv6 ingress filtering which is an IPv6 security conside= ration=0Aand not an ISATAP nor IPv4 security consideration. BCP=0Arecommend= ations for network ingress filtering are documented=0Ain RFC2827 and it is = expected that IPv6 routers that configure=0AISATAP interfaces will implemen= t IPv6 ingress filtering=0Aaccording to the BCP.=0A=0ASo If my last com= ment is correct than I do not see how ingress filtering would help here. Th= e only case where=A0ingress filtering can help is in case of attack #3 when= the routers reside at the same site. In that case if the attack packet (pa= cket 0) is sent from outside the site then ingress filtering on the border = of the site will drop the packet.=0A=0A=0A=3D=3D> Correct about the IP= v6 ingress filtering at the border,=0A=3D=3D> but as with attack #2 my erro= r in the previous message=0A=3D=3D> was in thinking the ISATAP router A was= forwarding the=0A=3D=3D> packet *out* of the ISATAP link when in fact from= the=0A=3D=3D> ISATAP router's perspective it is forwarding the packet=0A= =3D=3D> to a simple host *inside* of the link.=0A=3D=3D>=0A=3D=3D> The prob= lem here is that the ISATAP router is blindly=0A=3D=3D> forwarding a packet= to a node that it assumes is a simple=0A=3D=3D> host on the ISATAP link wi= thout first verifying that the=0A=3D=3D> node has demonstrated a willingnes= s to participate as a=0A=3D=3D> host on the link. As you have pointed out, = this can lead=0A=3D=3D> to strange scenarios when the anonymous node is a t= unnel=0A=3D=3D> router of some sort that does not participate in the=0A=3D= =3D> ISATAP link.=0A=3D=3D>=0A=3D=3D> It would not generally be possible fo= r the ISATAP router=0A=3D=3D> to check whether the IPv6 destination address= is an ISATAP=0A=3D=3D> address that embeds one of its own IPv4 addresses, = because=0A=3D=3D> when IPv4 private addresses are used the same IPv4 addres= s=0A=3D=3D> can (and often does) occur in multiple sites. So for example,= =0A=3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1=0A=3D= =3D> and is asked to forward an IPv6 packet with ISATAP=0A=3D=3D> destinati= on address 2001:DB8::0:5EFE:10.0.0.1 where the=0A=3D=3D> IPv6 prefix is for= eign, the router can't very well drop the=0A=3D=3D> packet as this would bl= ock legitimate communications. It=0A=3D=3D> is also not generally possible = to check whether a foreign=0A=3D=3D> link is an ISATAP link by looking for = the magic token=0A=3D=3D> "0:5EFE" as that token only has significance for = ISATAP=0A=3D=3D> links and not other link types.=0A=3D=3D>=0A=3D=3D> Instea= d, the mitigation I think makes the most sense is=0A=3D=3D> for the ISATAP = router to first verify that the node which=0A=3D=3D> it assumes to be a sim= ple ISATAP host has demonstrated a=0A=3D=3D> willingness to participate in = the link. That can be done=0A=3D=3D> by having the ISATAP router first chec= k the neighbor cache=0A=3D=3D> when it has a packet to send to verify that = there is a=0A=3D=3D> cached entry corresponding to the destination. For nod= es=0A=3D=3D> that are willing ISATAP hosts on the link, there would=0A=3D= =3D> have been a neighbor cache entry created when the node=0A=3D=3D> sends= a Router Solicitation to the ISATAP router for the=0A=3D=3D> purpose of di= scovering default router lifetimes and on-=0A=3D=3D> link prefixes. So, the= simple mitigations is for the ISATAP=0A=3D=3D> router to forward the packe= t only if there is a pre-existing=0A=3D=3D> neighbor cache entry and drop t= he packet otherwise. This=0A=3D=3D> implies that the router should keep nei= ghbor cache entires=0A=3D=3D> for the duration of the minimum lifetime of t= he prefixes=0A=3D=3D> it advertises in its Router Advertisements.=A0 =0A=0A= > In general, I would like to point out that indeed as in=0A> most other at= tacks these attacks may also be mitigated by=0A> proper firewall rules. How= ever, I do not believe that this=0A> should be our only answer against thes= e attacks. I believe=0A> that since these attacks are made possible due to = the=0A> inherent characteristics of the tunnels they=A0should be=0A> stoppe= d intrinsically as much as possible by the tunnel=0A> participants and not = relay on outside filtering rules.=0A=0AIn RFC5214, Section 10 we have: "res= tricting access to the=0Alink can be achieved by restricting access to the = site". The=0Amitigations do exactly that, and in such a way that ISATAP=0An= odes can operate with only the necessary and sufficient=0Achecks. So on thi= s point, I do not share your opinion.=0A=0AWhat about two ISATAP tunnel= s that reside on the same site like in attack #3. Do you=A0also think that = proto-41 filtering should barrier between the two tunnels within the site?= =A0=0A=0A=0A=3D=3D> I think this may be overcome by the discussion abo= ve.=0A=3D=3D> Short story is that operational practices must be=0A=3D=3D> e= mployed whereby an ISATAP router is not mistaken for=0A=3D=3D> a 6to4 route= r. This is through proper arrangement of=0A=3D=3D> 6to4 router/relay interf= aces outside of the site border=0A=3D=3D> rather than inside, and ISATAP ro= uter interfaces inside=0A=3D=3D> of the site border rather than outside. Al= so proper=0A=3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at=0A= =3D=3D> site borders.=0A=3D=3D>=0A=3D=3D> Also, when there are multiple ISA= TAP links within the=0A=3D=3D> same local IPv4 routing region, an ISATAP ro= uter should=0A=3D=3D> first verify a node's willingness to act as a host on= =0A=3D=3D> the ISATAP link before blindly sending a packet to it.=0A=3D=3D>= =0A=3D=3D> Fred=0A=3D=3D> fred.l.templin@boeing.com=0A=0AFred=0Afred.l.temp= lin@boeing.com=0A=A0=0A________________________________________=0AFrom: "Te= mplin, Fred L" =0ATo: Gabi Nakibly ; v6ops =0ACc: ipv6@ietf.org; secdir@ietf.org=0A= Sent: Monday, August 17, 2009 8:35:08 PM=0ASubject: RE: Routing loop attack= s using IPv6 tunnels=0A=0A=0AGabi,=0A=A0=0AThanks for publishing this work.= In the document, attacks A, B and C=0Acorrespond to a configuration that v= iolates section 6.2 of RFC5214:=0A=A0=0A> 6.2.=A0 ISATAP Interface Address = Configuration=0A>=A0=0A> =A0=A0Each ISATAP interface configures a set of lo= cators consisting of IPv4=0A>=A0=A0 address-to-interface mappings from a si= ngle site; i.e., an ISATAP=0A>=A0=A0 interface's locator set MUST NOT span = multiple sites.=0A=A0=0AIn particular, in scenarios A, B and C the IPv4 loc= ator used for ISATAP=0Ais seen both within the enterprise as site #1 and wi= thin the global Internet=0Aitself as site #2. If the ISATAP interface is to= be used as an enterprise-=0Ainterior interface, it should therefore not ac= cept IP-proto-41 packets=0Acoming from an IPv4 source outside of the enterp= rise nor source=0AIP-proto-41 packets that are destined to an IPv4 node out= side of the=0Aenterprise. This condition should be satisfied by having the = site border=0Arouters implement IPv4 ingress filtering and ip-protocol-41 f= iltering as=0Arequired in Section 10 of RFC5214.=0A=A0=0AIt is mentioned th= at attack C could also occur when the routers reside=0Ain the same site, wh= ere their addresses may be private. This would=0Acorrespond to a case in wh= ich an attacker within the site attacks the=0Asite itself, which can easily= be traced - especially when source address=0Aspoofing from a node within t= he site is prevented through proper ingress=0Afiltering.=0A=A0=0AFred=0Afre= d.l.templin@boeing.com=0A=A0=0A________________________________________=0AF= rom: Gabi Nakibly [mailto:gnakibly@yahoo.com] =0ASent: Monday, August 17, 2= 009 8:21 AM=0ATo: v6ops=0ACc: ipv6@ietf.org; secdir@ietf.org=0ASubject: Rou= ting loop attacks using IPv6 tunnels=0A=A0=0AHi all,=0AI would like to draw= the attention of the list to=A0some=A0research=A0results which my colleagu= e and I at the National EW Research=A0& Simulation=A0Center have recently p= ublished. The research presents a=A0class of routing loop attacks that abus= es 6to4, ISATAP and Teredo. The=A0paper can be found at: http://www.usenix.= org/events/woot09/tech/full_papers/nakibly.pdf=0A=A0=0AHere is the abstract= :=0AIPv6 is the future network layer protocol for the Internet. Since it is= not compatible with its predecessor, some interoperability mechanisms were= designed. An important category of these mechanisms is automatic tunnels, = which enable IPv6 communication over an IPv4 network without prior configur= ation. This category includes ISATAP, 6to4 and Teredo. We present a novel c= lass of attacks that exploit vulnerabilities in these tunnels. These attack= s take advantage of inconsistencies between a tunnel's overlay IPv6 routing= state and the native IPv6 routing state. The attacks form routing loops wh= ich can be abused as a vehicle for traffic amplification to facilitate DoS = attacks. We exhibit five attacks of this class. One of the presented attack= s can DoS a Teredo server using a single packet. The exploited vulnerabilit= ies are embedded in the design of the tunnels; hence any implementation of = these tunnels may be vulnerable. In particular, the attacks were tested=0Aa= gainst the ISATAP, 6to4 and Teredo implementations of Windows Vista and Win= dows Server 2008 R2. =0A=A0=0AI think the results of the research warrant s= ome corrective action. If this=A0indeed shall be the general sentiment of t= he list, I will be happy write an appropriate I-D. The mitigation measures = we suggested in the paper are the best we could think of to completely elim= inate the problem. However they are far from perfect since=A0they would req= uire=A0tunnel implementations to be updated in case new types of automatic = tunnels are introduced.=0A=A0=0AYour comments are welcome.=0A=A0=0AGabi=0A= =0A=0A From kivinen@iki.fi Mon Aug 24 05:10:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B713A6995; Mon, 24 Aug 2009 05:10:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv+05zlJC2Bl; Mon, 24 Aug 2009 05:10:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6583A67AD; Mon, 24 Aug 2009 05:10:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n7OCA3Qq028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Aug 2009 15:10:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n7OCA3x2029979; Mon, 24 Aug 2009 15:10:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19090.33563.491859.518026@fireball.kivinen.iki.fi> Date: Mon, 24 Aug 2009 15:10:03 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: draft-ietf-sipcore-presence-scaling-requirements@tools.ietf.org, sipping-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-sipcore-presence-scaling-requirements-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 12:10:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This documents lists set of requirements for the optimizations for SIP/SIMPLE when used in large inter-domain environments. As such it does not really have security considerations as it does not specify any protocol, but it does have some security requirements. Most of those security requirements are in type of "MUST NOT change security requirements of existing RFCs". I think the current document is good enough for security considerations / requirements area. One thing that do require more work is the abstract section. Now it is very short (single sentence) and it mostly says same thing as title of the document. It should give more information what is meant with "inter-domain" and give references to the "SIP/SIMPLE" already there, not just use those acronyms there withing expanding them or providing references. Taking few more sentenses from the "Introduction" section would fix that problem. Nits: Section "4. Considerations for Possible Optimizations": "Some initial work to address= these issues can be found in:" ^^^^ Extra '='-character. -- kivinen@iki.fi From hartmans@mit.edu Mon Aug 24 05:33:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDB228C1B8; Mon, 24 Aug 2009 05:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8emHChWl9q3P; Mon, 24 Aug 2009 05:33:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id BBD1A28C12B; Mon, 24 Aug 2009 05:33:28 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9E84864673; Mon, 24 Aug 2009 08:33:28 -0400 (EDT) To: Jari Arkko References: <4A927003.7050004@piuha.net> From: Sam Hartman Date: Mon, 24 Aug 2009 08:33:28 -0400 In-Reply-To: <4A927003.7050004@piuha.net> (Jari Arkko's message of "Mon\, 24 Aug 2009 13\:48\:35 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mext-chairs@tools.ietf.org, draft-ietf-mext-aero-reqs@tools.ietf.org, Sam Hartman , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 12:33:29 -0000 >>>>> "Jari" == Jari Arkko writes: Jari> Thanks for your review, Sam. A few responses below: >> However it is important to make sure that everyone involved >> understands meeting these requirements alone without more >> general security requirements would not produce an acceptable >> solution. If the intent of this draft is to state all the >> requirements that mext needs to consider in developing a >> solution that meets IETF standards and that meets the needs of >> the air/space community, then it falls significantly short. I >> don't think that is the intent though; I think this is simply >> intended to be one stakeholder's input. Presumably, even if we >> are only targeting deployment in air/space enviroments, we will >> look at more general security and management requirements >> necessary to make the technology deployable on the internet. >> If we're all on the same page on that point, then this draft is >> fine. >> You raise a valid point and I think we have it under control. But its Jari> actually a bit more complicated than what you state above. Jari> I have treated the document as an input from a particular Jari> stakeholder's perspective. I have assumed that there are Jari> more general protocol design and even security aspects that Jari> an actual solution should take into account. Jari> However, I do not necessarily believe that there is a single Jari> NEMO route optimization solution that should cater for Jari> everyone's needs. The group's charter was written with the Jari> assumption that there are different use cases and that their Jari> solutions might be different. For instance, federated tunnel Jari> servers advertising the same BGP space is likely a good Jari> match for the aeronautics requirements, as it can solve the Jari> continental dogleg routing problem. Its not clear that this Jari> solution solve every other application's NEMO RO problems, Jari> however. I think some of this discussion took place while I was still on the IESG. Regardless, I was definitely aware that there would be multiple solutions for different use cases; I was basically trying to capture what you say above. So, what you're thinking is definitely in alignment with what I was thinking when I wrote my review. From gnakibly@yahoo.com Mon Aug 24 09:11:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D42228C259 for ; Mon, 24 Aug 2009 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jh8I8ANyn9c for ; Mon, 24 Aug 2009 09:11:55 -0700 (PDT) Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id CDEE528C1F6 for ; Mon, 24 Aug 2009 09:11:54 -0700 (PDT) Received: from [68.142.194.243] by n16.bullet.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 Received: from [68.142.201.246] by t1.bullet.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 24 Aug 2009 16:11:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 434488.81695.bm@omp407.mail.mud.yahoo.com Received: (qmail 57852 invoked by uid 60001); 24 Aug 2009 16:11:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251130318; bh=Z5S+vdzSLcYqgBnb1PXmFH30/JUIE1+UrWKg0MnGidA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XGMFXdLb0zdjmRkJhge7ufZk+kHJlAfd1CZfkTXu5/sexJ7zwJ/h2P/XvbN8iBaB7esRZNS9bkX35IS0OUNAUNWV6hJ7BrnQTEeH/2zF4zX8SAdwBtYO/oliLzhP9X3qm0lKlWxxAsE4h8zGPqQCBloFbMnz+Qw2Gpq373EzKtE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xTka0r3PHg+JqqX48geadQeDIgLMq8N9xv08QdEargNVWDtIzNu+1+rZcLgoLOpxgWyjIZQZGmjjFqn4K2k/yYwwR39cCMSqGRM6VmhR9e/3mVsciq5rzjZM95PbDusfZzNq2SV7hUMX9YUnZdYUR6gyvCE8lZFwaXr+CW6E1+c=; Message-ID: <852107.57254.qm@web45516.mail.sp1.yahoo.com> X-YMail-OSG: BwdE_vYVM1l_QUwItUxA19HWhxOH2XcfwADSMeBP98NOt9z5vTVug3eSdhkThEsX7o2o0yN8v6nAfjZY.e.HDmnWyEUwLc8J0n24VqIW3tDbg3._jBQdcDBpW.1ELeMAHTQcw8LrtIWYnPVT407.OBZRP5_wbpf.DQPuY4BjYJ4Bz1bgjfN0_qnL8e5jK.c5lEaFaBXE4NUIQvOhUPDyQDKU0xE4kffrku7Ye1BruQN.9Z5x1vg- Received: from [93.172.27.171] by web45516.mail.sp1.yahoo.com via HTTP; Mon, 24 Aug 2009 09:11:58 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <789539.81531.qm@web45502.mail.sp1.yahoo.com> <6D7FF41F-717B-42D2-A744-750DC874356B@free.fr> <808598.58470.qm@web45510.mail.sp1.yahoo.com> Date: Mon, 24 Aug 2009 09:11:58 -0700 (PDT) From: Gabi Nakibly To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops , Mark Townsley , 6man 6man , secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels - the 6rd case X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:11:56 -0000 Remi,=0ASee my comments inline ().=0A=0AGabi=0A=0A=0A=0A----- Original = Message ----=0AFrom: R=E9mi Despr=E9s =0ATo: Gabi Nak= ibly =0ACc: v6ops ; 6man 6man ; secdir@ietf.org; Mark Townsley =0ASent: Thu= rsday, August 20, 2009 11:34:49 AM=0ASubject: Re: Routing loop attacks usin= g IPv6 tunnels - the 6rd case=0A=0Agabi,=0A=0AThanks for your quick answer.= =0AFurther remarks in line.=0A=0ALe 19 ao=FBt 09 =E0 12:12, Gabi Nakibly a = =E9crit :=0A=0A> Remi,=0A> See my comments inline ().=0A> Gabi=0A> =0A>= From: R=E9mi Despr=E9s =0A> To: Gabi Nakibly =0A> Cc: v6ops ; 6man 6man = ; secdir@ietf.org; Mark Townsley =0A> Sent: Tuesday, Au= gust 18, 2009 8:00:42 PM=0A> Subject: Re: Routing loop attacks using IPv6 t= unnels - the 6rd case=0A> =0A> Hi Gabi,=0A> =0A> First, thanks to you and y= our colleagues for this research, and for the clear presentation of its res= ults.=0A> In my understanding, your contribution is important for transitio= n solutions to be carefully selected, and where needed improved.=0A> =0A> T= his mail is to complement the analysis with what applies to 6rd.=0A> =0A> F= or those who don't know it, 6rd, like 6to4, ISATAP and Teredo, is an automa= tic tunnel mechanism in actual use for IPv6 across IPv4 clouds.=0A> With it= , service providers can offer native IPv6 to their customers while using fo= r this their existing IPv4 infrastructures.=0A> Publication of the RFC that= describes it, RFC 5569, has been delayed since May for a reason related to= intellectual property rights applicable to independent submissions.=0A> Bu= t the draft on which 6rd is based is still available, and a new draft to ex= tend its applicability is also available:=0A> - tools.ietf.org/html/draft-d= espres-6rd-03=0A> - tools.ietf.org/html/draft-townsley-ipv6-6rd-01=0A> = =0A> I must admit that this is the first time I read the spec of 6rd so for= give me if I miss something.=0A> =0A> =0A> (1) Case of ISPs that opera= te 6rd relays and no 6to4 relays (and neither Teredo relays nor ISP-infrast= ructure NATs)=0A> =0A> In its sec. 3, draft-despres-6rd-03 says:=0A> <<<=0A= >=A0 The IPv4 anycast address of 6rd relays may be chosen independently by= =0A>=A0 each ISP.=A0 The only constraint is that routes toward the ISP that= are=0A>=A0 advertised must not include this address.=0A> >>>=0A> In view o= f your study and in my understanding, it should be completed with:=0A> "Als= o, the ISP must not forward toward the global IPv4 global Internet packets = having this address as source."=0A> =0A> With this, an ISP that operates 6r= d relays but operates neither 6to4 relays nor Teredo relays nor NATs is imm= une to the routing loop attack because:=0A> - An IPv6 packet forwarded to t= he IPv6 Internet by a 6rd relay cannot come back to an IPv4 interface of a = 6rd relay of the same ISP: there is no IPv4 route back to the ISP for its 6= rd anycast address.=0A> - An IPv6 packet received from the IPv6 Internet by= a 6rd relay cannot be sent back to the IPv4 global Internet: the source ad= dress of its IPv4 encapsulating packet is the 6rd anycast address, which pr= events it from reaching the IPv4 global Internet.=0A> =0A> Note that, if in= terfaces of the ISP to the IPv4 global Internet are already subject to ingr= ess filtering (packets received by the global Internet are discarded if the= re is no reverse path available for them), the added sentence is not necess= ary. It is just just a double precaution for cases where such ingress filte= ring doesn't apply.=0A> =0A> I agree with you that above check will wor= k. However, I might choose another way here: the relay must make the follow= ing two checks:=0A> 1) When an IPv6 packet is received from the IPv6 Intern= et the 6rd relay must ensure before encapsulation that the intended IPv4 de= stination address belongs to one of the ISP's clients (I assume it can make= this check easily). This way no IPv6 packet received from the IPv6 Interne= t will be relayed to a 6to4 relay (and then back to the 6rd relay through t= he IPv6 Internet).=0A=0AThe problem is that this check is not easy "in gene= ral" because ISPs typically have their IPv4 prefixes allocated one by one a= s they increase the number of their clients.=0A=0A=0A> 2) When an encapsula= ted packet is received from the IPv4 network side the 6rd relay must check = that the IPv6 destination does not include its own IPv4 address. For exampl= e the IPv6 destination address must not be: 2002:::/48. This will prevent the packet from ever reaching back the 6rd relay = through its IPv4 interface=0A=0AThe problem is that to be general, and as y= ou noted, this test depends on a knowledge of all formats used to embed IPv= 4 addresses in IPv6 addresses. When a new format is introduced, a security = weakness therefore holds until all relays are upgraded to support it.=0ABes= ides, and more important, some formats may use _ISP dependent prefixes_ (an= d 6rd is already in this case!). These formats cannot be recognized by a co= nstant code.=0A=0A=0AThis being noted, I agree that, to extend applicabilit= y of 6rd relays to cases where ingress filtering doesn't apply, and to deal= more simply with the case of 6rd ISPs that also operate 6to4 relays, 6rd r= elays SHOULD do as you propose:=0A*In 6rd relays, packets received on the I= Pv4 side should be discarded if their IPv6 destinations are 6to4 addresses = containing the ISP 6rd anycast address.*=0A=0A=0A> =0A> This way all the ch= ecks are done only at the 6rd relay and not in other IPv4 border routers of= the ISP which should not be aware of the 6rd deployment.=0A=0ANote that IP= v4 border routers of the ISP need not to be aware of the 6rd in particular.= =0AThey only have to make sure that ingress filtering "in general" applies = to packets sent toward the global Internet.=0A(If their downstream neighbor= s do ingress filtering as they should, these border routers have nothing sp= ecific to do. In cases where this isn't sure though, they should better pre= vent source address spoofing by filtering themselves source addresses for w= hich they have no reverse path.)=0A=0A=0A=0A- For packets coming from t= he IPv6 side:=A0if the first check I suggested=A0of the ISP's clients is no= t easy, then you can=A0instead check, as you suggested below,=A0the IPv6 so= urce address of the incoming packet to verify that it is not a 6to4 address= containing the 6rd relay IPv4 address. This can make the check of the sour= ce address in other IPv4 border routers redundant.=0A- For packets coming f= rom the IPv4 side: on second thought, if the 6rd spec already ensures that = there is no IPv4 route from an external 6to4 relay to a 6rd relay, then ind= eed the second check I proposed is redundant. Moreover, I completely agree = that=A0this check=A0can=A0only eliminate=A0routing loops=A0with a 6to4 rela= y and not with=A0relays of other types of tunnels.=A0=0A=A0=0A=0A=0A> = =0A> =0A> =0A> (2) Case of ISPs that operate 6rd relays AND 6to4 relay= s (but neither Teredo relays nor ISP-infrastructure NATs)=0A> =0A> In its s= ec. 5 on security, draft-despres-6rd-03 says:=0A> <<<=0A>=A0 o=A0 RELAY PAC= KETS TOWARD THE INTERNET: The IPv6 source must be a 6rd=0A>=A0 =A0 =A0 addr= ess that matches the IPv4 source.=A0 The IPv6 destination must=0A>=A0 =A0 = =A0 not start with the ISP 6rd prefix.=0A> ...=0A>=A0 o=A0 RELAY PACKETS FR= OM THE INTERNET: The IPv6 source must not be a 6rd=0A>=A0 =A0 =A0 address o= f the ISP.=A0 The IPv4 destination must not be multicast,=0A>=A0 =A0 =A0 i.= e. must not start with 224/3...=0A> >>>=0A> =0A> In view of your study and = in my understanding, it MUST be completed with:=0A> - after the first quote= d paragraph:=0A> "Furthermore, if the ISP also operates 6to4 relays that ad= vertise on the IPv6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 source= must be neither the 6to4 anycast address 192.88.99.0 nor any of its equiva= lent IPv4 unicast addresses."=0A> - after the second quoted paragraph:=0A> = "Furthermore, if the ISP also operates 6to4 relays that advertise on the IP= v6 network the 6to4 IPv6 prefix 2002::/16, the IPv4 destination derived fro= m the IPv6 destination must be neither the IPv4 anycast address 192.88.99.0= nor any of its equivalent IPv4 unicast addresses."=0A> =0A> Actually, = I believe that the precautions I suggested above will work here also instea= d of those checks. Won't they?=0A=0AAs explained above, it would be 100% sa= fe only if all embedded IPv4 addresses were guaranteed to be recognized, wh= ich is not the case.=0A=0A=0A> In general, I think that checks performed on= the destination address (IPv4 or IPv6) should be more robust than checks o= n a source address.=0A=0AIn my understanding, not always.=0AEach scenario h= as to be studied for what it is.=0A=0A> =0A> =0A> With this, an ISP th= at operates both 6rd and 6to4 relays is also immune to the routing-loop att= ack because:=0A> - an IPv6 packet forwarded to the global Internet by 6rd r= elays can come back to the ISP IPv4 network via one of the 6to4 relays of t= he ISP BUT cannot be accepted again by a 6rd relay: its IPv4 source address= is then one of a 6to4 relay, which, with the first added sentence, prevent= s it from being accepted by the 6rd relay.=0A> - an IPv6 packet received fr= om the IPv6 Internet by a 6rd relay cannot be sent back to the IPv4 global = Internet via one of the 6to4 relays: the IPv4 address derived from its IPv6= destination would have for this to be one of a 6to4 relays, which, with th= e second added sentence, prevents it from being forwarded by the 6rd relay.= =0A> =0A> Note: RFC 3068, where the 6to4 anycast address is introduced, say= s that "each 6to4 relay router that advertise the 6to4 anycast prefix MUST = also provide an equivalent IPv4 unicast address". Whether this is really im= portant in practice is IMHO unclear. On the other hand, if this MUST is dis= pensed with, the above security precaution can be implemented in 6rd relays= without a need to handle a variable number of addresses, and to administra= tively configure them (with the associated risks of human errors).=0A> =0A>= =0A> If you do the check on the destination address you can avoid this= administrative configuration altogether.=0A=0AAgreed for packets forwarded= to the IPv6 side (see above).=0A=0ANow, for packets from the IPv6 Internet= , rather than checking that the embedded IPv4 destination has one of the IS= P allocated prefixes, there is a better check I hadn't seen before sending = the previous e-mail:=0A*In 6rd relays, packets received on the IPv6 side sh= ould be discarded if their source addresses are 6to4 addresses containing t= he ISP 6rd anycast address.*=0A=0A=0AI fully agree.=0A<\gn>=0A=0A=A0=0A= The above administrative configuration is thus unnecessary, and the 6rd rel= ay cannot participate in a routing loop attack even if its ISP also operate= s 6to4 relays.=0A=0ANOTE: As a matter of fact, a source address check can a= lso be used to improve the Mitigation Measures you proposed for 6to4, ISATA= P and Teredo relays:=0A*In your three forwarding conditions, it would be su= fficient to add "or source" after each occurrence of "destination".*=0AThus= , each of these relays becomes protected against rooting loop attacks via a= ny other 6to4, ISATAP, and Teredo relay, even if this relay doesn't make th= e new check on destination addresses.=0A=0A=0AYou are right. This can a= dd another layer of security. However,=A0one must note=A0that for this chec= k to work the other relay=A0that participates in the routing loop=A0must=A0= indeed validate before it decapsulates a packet that its IPv4 source addres= s corresponds to=A0its IPv6 source address. If this is not true, then the c= heck of the source address you noted above is useless. I am making this not= e, since I have encountered some implementations of 6to4 and ISATAP that do= es not=A0follow their corresponding spec and do not=A0make this=A0validatio= n, as they should.=A0=0ABut, again, I agree that this check can be used as = another layer of security.=0A=0A=0A=0A> =0A> =0A> To conclude:=0A= > - Without needing to modify 6to4 relays, ISATAP relays, and Teredo relays= , ISPs that support 6rd and don't support 6to4 appear to be already protect= ed against routing loop attacks if ingress filtering is operational at thei= r interfaces to the IPv4 global Internet. With an additional simple precaut= ion in 6rd relays, they can also be immune in the absence of such filtering= ..=0A> =0A> I fully agree.=0A=0AThanks.=0AThoughts on the proposal to im= prove your mitigation measures?=0A=0ARegards,=0ARD=0A=0A> =0A> - A nec= essary additional security precaution against routing-loop attacks is now i= dentified for ISPs that support 6rd and that, having started with 6to4, wis= h to keep it for backward compatibility. Thanks again for your analysis whi= ch made it possible.=0A> =0A> =0A> Best regards,=0A> RD=0A> =0A> =0A> =0A> = Le 17 ao=FBt 09 =E0 17:21, Gabi Nakibly a =E9crit :=0A> =0A> > Hi all,=0A> = > I would like to draw the attention of the list to some research results w= hich my colleague and I at the National EW Research & Simulation Center hav= e recently published. The research presents a class of routing loop attacks= that abuses 6to4, ISATAP and Teredo. The paper can be found at: http://www= ..usenix.org/events/woot09/tech/full_papers/nakibly.pdf=0A> >=0A> > Here is = the abstract:=0A> > IPv6 is the future network layer protocol for the Inter= net. Since it is not compatible with its predecessor, some interoperability= mechanisms were designed. An important category of these mechanisms is aut= omatic tunnels, which enable IPv6 communication over an IPv4 network withou= t prior configuration. This category includes ISATAP, 6to4 and Teredo. We p= resent a novel class of attacks that exploit vulnerabilities in these tunne= ls. These attacks take advantage of inconsistencies between a tunnel's over= lay IPv6 routing state and the native IPv6 routing state. The attacks form = routing loops which can be abused as a vehicle for traffic amplification to= facilitate DoS attacks. We exhibit five attacks of this class. One of the = presented attacks can DoS a Teredo server using a single packet. The exploi= ted vulnerabilities are embedded in the design of the tunnels; hence any im= plementation of these tunnels may be vulnerable. In particular, the attacks= were tested against the ISATAP, 6to4 and Teredo implementations of Windows Vist= a and Windows Server 2008 R2.=0A> >=0A> > I think the results of the resear= ch warrant some corrective action. If this indeed shall be the general sent= iment of the list, I will be happy write an appropriate I-D. The mitigation= measures we suggested in the paper are the best we could think of to compl= etely eliminate the problem. However they are far from perfect since they w= ould require tunnel implementations to be updated in case new types of auto= matic tunnels are introduced.=0A> >=0A> > Your comments are welcome.=0A> >= =0A> > Gabi=0A> >=0A> > ---------------------------------------------------= -----------------=0A> > IETF IPv6 working group mailing list=0A> > ipv6@iet= f.org=0A> > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6=0A> > ----------------------------------------------------------------= ----=0A> =0A> =0A> =0A> =0A> =0A=0A=0A From gwz@net-zen.net Mon Aug 24 10:16:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC0E28C2C1 for ; Mon, 24 Aug 2009 10:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3ZMXtVjoZxF for ; Mon, 24 Aug 2009 10:16:24 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 41C3A28C16F for ; Mon, 24 Aug 2009 10:16:24 -0700 (PDT) Received: (qmail 3448 invoked from network); 24 Aug 2009 17:16:27 -0000 Received: from unknown (71.231.55.1) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 24 Aug 2009 17:16:26 -0000 From: "Glen Zorn" To: "'Donald Eastlake'" References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> In-Reply-To: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> Date: Mon, 24 Aug 2009 10:16:03 -0700 Organization: Network Zen Message-ID: <00b701ca24de$8f53e4a0$adfbade0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcohSMzAFHIb0qpxTrush0QZed5TLgC7jPbg Content-Language: en-us Cc: 'Dan Romascanu' , 'IETF Discussion' , secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:16:25 -0000 Donald Eastlake [mailto:d3e3e3@gmail.com] writes: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. Sorry for the rather slow response, but I honestly didn't know what to say. > This document defines seven RADIUS Attributes to support the > implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version > 1). I would guess that RADIUS can be used between the 802.16 Base > Station and an authorization server but I don't know how you could > tell. > Maybe I missed it but it looks like the RADIUS protocol isn't > mentioned anywhere in 802.16-2004. From the text in some of these > RADIUS attribute descriptions, it appears that they are not used > between the Subscriber Station and the Base Stations but may be the > basis of 802.16 Attributes that are used on that hop. Given this, I > think a paragraph is needed (maybe even accompanied by a little ASCII > art) at the beginning show what's going on would be useful. Your comments seem to suggest a lack of familiarity with RFC 2865 and the RADIUS protocol in general. Leaving aside the question of how one could expect to usefully review a document that _extends_ a protocol w/o understanding the protocol being extended, RADIUS is only defined between a NAS (in this case, an 802.16 Base Station) and a RADIUS server. > Many document have security considerations section that only refer to > other documents and may be missing specifics to the document contents. > I think this document has the opposite problem good security specifics > in the security consideration section but could usefully add > references to the 802.16-2004 and RADiUS security sections. I'm not at all sure what 802.16 security has to do with RADIUS, but I guess I can add a reference to RFC 2869 in the Security Considerations section. > The security considerations section rightly warns to protect against > modification of the PKM-Auth-Key attribute. But is it really clear > there is no problem with modification of the Security Association ID > attribute or the attribute listing cryptosuites? No, apparently not. I had originally thought that modifying the list of supported cryptosuites would just result in DoS, but that's not right. I'll fix it. > > The wording in Sections 3.1 and 3.2 see to almost be designed to allow > the possibility of the multiple *-Cert Attributes carrying a > certificate to appear in more than one Access-Request message. But I > would assume that's not meaningful and/or was not intended to allow > that. There is no way to do such a thing in standard RADIUS. > > The table of attributes in Section 4 that gives the number of times > each attribute can occur in different message types seems to have > problems. Since there is no key giving it another meaning, I assume > "0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are described > and possibly occurring multiple times due to fragmentation of > certificates. If the table is supposed to be in terms of logical > attributes so that multiple PKM-SS-Cert attributes only count as one > if they have parts of one certificate, then the table should say so. > On the other hand, the PKM-SA-Descriptor attribute is shown as "0+", > which presumably means zero or more, but the text description in 3.6 > clearly says it can occur one or more times, which presumably would be > written "1+". The relevant text from section 3.6 says "One or more instances of the PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message." RFC 2119 says about the keyword "MAY", "This word, or the adjective "OPTIONAL", mean that an item is truly optional"; this says to me that zero, one or more instances of the PKM-SA-Descriptor Attribute can be in an Access-Accept message, just in a more compact and formal way. If this is not clear, however, I'm open to suggestions for alternate text. > This whole table need to be carefully checked, the > inconsistencies resolved, and it should be clear if literal binary > attributes or some sort of logical aggregate attributes (in the case > of the "Cert" attributes at least), is being counted. I can add notes to the table regarding the "logical" vs. "physical" nature of the PKM-*-Cert Attributes, as well as a key to the meaning of "0+", etc. Is that OK? > > The text between the Section 6. header line and the Section 6.1 header > line as well as the Section 6.1 header line itself seem superfluous > and can be deleted. Fine. ... From terry.l.davis@boeing.com Mon Aug 24 10:51:04 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B4B28C2E7; Mon, 24 Aug 2009 10:51:04 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3wPetRCfJbw; Mon, 24 Aug 2009 10:51:03 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id CE30A28C25E; Mon, 24 Aug 2009 10:51:03 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OHoLrT005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Aug 2009 10:50:22 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OHoL8E019582; Mon, 24 Aug 2009 12:50:21 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OHoKA0019574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 24 Aug 2009 12:50:21 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Mon, 24 Aug 2009 10:50:20 -0700 From: "Davis, Terry L" To: "'Sam Hartman'" Date: Mon, 24 Aug 2009 10:50:19 -0700 Thread-Topic: secdir review of draft-ietf-mext-aero-reqs8 Thread-Index: AcoiyZBrlebgcXKATSa/6F5jh6ClcgCEwtUg Message-ID: <2557049CDBC35B4EBD79CFACFEC045841CCF7497@XCH-NW-CCR1V.nw.nos.boeing.com> References: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.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: "mext-chairs@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-mext-aero-reqs@tools.ietf.org" , "weddy@grc.nasa.gov" , "'Ivancic, William D. \(GRC-RHN0\)'" Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:51:04 -0000 Sam My point was: - With the current extreme level of effort required to obtain interoperabil= ity between different vendors' implementations of the various IP security p= rotocols, I don't see we can implement the security recommendations in the = draft in our continuously changing communication's environment. Take care Terry > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Friday, August 21, 2009 6:41 PM > To: Davis, Terry L > Cc: 'Sam Hartman'; secdir@ietf.org; iesg@ietf.org; 'Ivancic, William D. > (GRC-RHN0)'; weddy@grc.nasa.gov; mext-chairs@tools.ietf.org; draft-ietf- > mext-aero-reqs@tools.ietf.org > Subject: Re: secdir review of draft-ietf-mext-aero-reqs8 >=20 > >>>>> "Davis," =3D=3D Davis, Terry L writes: >=20 > Davis,> Sam One of the items that continues to seriously concern > Davis,> me across the whole IP protocol RFC set is the basic lack > Davis,> of simple vendor-to-vendor IP security interoperability! > Davis,> All of NEMO and MEXT assumes that simple, easy to > Davis,> implement, IPSec, PKI, and IKE interoperability exist; > Davis,> they do NOT. >=20 > With you so far. >=20 > Davis,> In aviation we do not have the luxury that Enterprise or > Davis,> Entity organizations have in being able to deploy "single > Davis,> vendor" solutions! In the aviation space, if someone made > Davis,> one, aviation will have it somewhere in our infrastructure > Davis,> and we need to interoperate with it as our aircraft > Davis,> operate in a truly heterogeneous global space. An > Davis,> aircraft in flight will usually 1 to 4 open communications > Davis,> links and these will be continuously changing as we hand > Davis,> off between communication providers and "Navigation > Davis,> Service Providers" who utilize entirely different vendors > Davis,> and PKIs. >=20 > I think the rest of the world is much more similar to this than you > believe. >=20 > Davis,> Nor can we have a "single PKI" global solution; > Davis,> nation/state laws preclude this in many cases as they > Davis,> reasonably require credentials that they control for > Davis,> authentication in their territory and bridge assurances, > Davis,> although fine for business level relationships, may > Davis,> reasonably not meet nation/state requirements for > Davis,> operations within their nation. >=20 > Davis,> I continue to state that the lack of easy to use/configure > Davis,> vendor interoperability parameters for our basic IP > Davis,> security protocol associations is a major failure in of > Davis,> Internet architectures. It cannot require a senior > Davis,> network engineer, a senior PKI analyst, and dozens of > Davis,> Wireshark traces to establish a secure link! Entry level > Davis,> engineers/analysts and techs need to be able to perform > Davis,> this function as we do with basic network (DHCP) > Davis,> connectivity. We need a "dynamic security association > Davis,> protocol" like DHCP for industries like aviation (and most > Davis,> the CI sectors too!). >=20 > Davis,> To me, this lack of a simple, easy to use, > Davis,> interoperability security association configuration is one > Davis,> of our most pressing issues in our efforts to establish > Davis,> "cyber space security" regardless of what CI sector we are > Davis,> looking at. >=20 > I think I'm in general agreement with you. However I don't see how > any of this applies to my comments--unless possibly you are saying > that the draft needs to be expanded with additional security > requirements. From Fred.L.Templin@boeing.com Mon Aug 24 13:04:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBD83A6922; Mon, 24 Aug 2009 13:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JR+sk4nF5g4; Mon, 24 Aug 2009 13:04:42 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 74A633A6DE7; Mon, 24 Aug 2009 13:04:42 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OK4bpE010056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 13:04:38 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OK4bvn018369; Mon, 24 Aug 2009 15:04:37 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OK4ZZJ018294; Mon, 24 Aug 2009 15:04:37 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 13:04:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 13:04:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <475898.88672.qm@web45510.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pg References: <475898.88672.qm@web45510.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 24 Aug 2009 20:04:36.0496 (UTC) FILETIME=[1AE09100:01CA24F6] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 20:04:44 -0000 Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, August 24, 2009 4:44 AM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > I=A0initially very much=A0liked your suggestion regarding the = check=A0of the neighbor cache before > forwarding a packet into the tunnel.=A0It truly addresses the root = cause of the problem ans is simple > enough to implement. However, I realized that an attacker can send a = spoofed=A0RS to the ISATAP router > as if it came from the 6to4 relay. The router would then send=A0a = RA=A0to it=A0and consequently change its > neighbor cache. So it seems=A0that this defense does not add = much.=A0Wouldn't you agree? I agree that my proposed mitigation is only useful when there is assurance of a coherent neighbor cache in the ISATAP router. That would be true in the case in which the ISATAP router is located within a site protected by border routers that perform ip-proto-41 and ingress filtering, and in which there is no untraceable IPv4 source address spoofing. So AFAICT, my proposed mitigation is still necessary for preventing attack #3 when ISATAP routers A and B are on separate ISATAP links within the same site-internal IPv4 routing region. > I completely agree with your observation on the non-feasibility of = verifying=A0that the > destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the ISATAP address may include > a private IPv4 address. On the other hand, a check on public IPv4 = addresses is acceptable.=A0If the > check would be done only on ISATAP addresses that include public IPv4 = addresses then this will > eliminate the attacks in which the two victims reside=A0at different = sites. Note that if attack #3=A0is > launched on two ISATAP routers=A0having private addresses at two = different sites then the attack will > not work anyway since one router can not send a direct=A0IPv4 packet = to the other. In addition, > to=A0mitigate attacks in which the other victim is a 6to4 relay (such = as attack #1) then a check would > have to be done on a 6to4 address, i.e. the destination address must = not be "2002: the ISATAP router>::*". In this case the IPv4 address must be public, = according to > the 6to4 spec. >=20 > As you also noted there is another problem with this check since the = string "200::5EFE" is not unique > to ISATAP links. On the other hand, it seems that the probability to = encounter a non-malicious packet > with a destination address having an IID that equals "200:5EFE:" is > pretty slim. >=20 > This check is definitely not a=A0perfect solution, and I sure hope = that someone will come up with a > better one for mitigating the routing loops. However, I would be happy = if there is some kind of other > mitigation=A0measures besides packet filtering=A0(proto-41 and = ingress) by=A0other nodes (which=A0does not > necessarily exist). You seem to be envisioning a scenario of ISATAP router operation with public IPv4 addresses and outside of any site border routers that perform ingress filtering and ip-proto-41 filtering. That has traditionally been seen as the domain of 6to4, but I am happy to discuss the possibility of what I called the "inside-out ISATAP model" in a list message long ago (which AFAICT is the scenario you are alluding to). So, if the public IPv4 Internet were considered as one gigantic "site" and we wanted to do ISATAP on that site, it would be nice to divide the site into multiple logical partitions, with each partition identified by a PRL name and a unique set of IPv6 prefixes. But then, we have the scenario you are describing in which we can't trust the integrity of the ISATAP router's neighbor cache due to the possibility for untraceable IPv4 source address spoofing such that the neighbor cache check mitigation can be subverted. This means that if we want to support the inside-out ISATAP model then the routing loops could be mitigated either by 1) implementing the destination address checks you are suggesting, or 2) by not allowing ISATAP router interfaces that are not behind filtering border routers to advertise non-link-local on-link IPv6 prefixes and/or forward packets from non-link-local prefixes in the first place. If we took the easy way out and did 2), then the entire IPv4 Internet would look like one gigantic ISATAP link that only did IPv6 link-local. So, nodes could ping6 each others' ISATAP link-local addresses but that's about it.=20 If we took the more ambitious route and allowed ISATAP to flourish fully within the global IPv4 Internet, then we would essentially be deprecating 6to4 - so it isn't surprising that your address checks mostly involve 6to4 suppression. Assuming this, if I read your attack scenarios 1 through 3 correctly then scenarios 1 and 3 are mitigated by a receive-side check and scenario 2 is mitigated by a send-side check. In particular, the pseudo-code would be: isatap_rcv() { ... if (dst =3D=3D "2002:::*") drop_pkt(); /* attack #1 mitigation */ if (dst =3D=3D "*::0200:5efe:") drop_pkt(); /* attack #3 mitigation */ ... } isatap_xmt() { ... if (dst =3D=3D "*::0200:5efe:192.88.99.1") drop_pkt(); /* attack #2 mitigation */ ... } Does the above look right to you? And is this everything, or are there other scenarios we need to consider? Thanks - Fred fred.l.templin@boeing.com >=20 > Gabi >=20 > ----- Original Message ---- > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Wednesday, August 19, 2009 6:16:18 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Hi Gabi, >=20 > I'm sorry to have to keep turning this into plaintext, > but annotation is difficult otherwise. See below for > my responses (=3D=3D>): >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Wednesday, August 19, 2009 1:49 AM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > See my comments inline (). >=20 > ________________________________________ > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Tuesday, August 18, 2009 6:48:45 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Gabi, >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Tuesday, August 18, 2009 3:29 AM > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Indeed the ISATAP interface of the ISATAP router is meant > > to be an enterprise-interior (note that=A0it is still=A0assumed > > that the associated IPv4 address is=A0non-private). As=A0we > > explicitly note in the paper, the first three attacks=A0will > > be mitigated=A0if proper protocol-41 filtering is deployed on > > the site's border. However, note that RFC5214 does not mandate > > or require this filtering. >=20 > The RFC5214 Security Considerations makes clear the > consequences of not implementing IPv4 ingress filtering > and ip-protocol-41 filtering (i.e., a possible spooing > attack in which spurious ip-protocol-41 packets are > injected into an ISATAP link from outside). RFC5214 > Section 6.2 additionally requires that an ISATAP interface's > locator set MUST NOT span multiple sites. This means that the > ISATAP interface must not decapsulate nor source ip-proto-41 > packets within multiple sites, where the enterprise interior > is site #1 and the global Internet is site #2. ip-protocol-41 > filtering is the way in which the ISATAP interface is > restricted to a single site. > > Now let me see that I understand Section 6.2 correctly. In > attack #2, for example, I assume the ISATAP router has two > physical interfaces. A site-internal IPv4 interface with an > address IPisatap and a site-external IPv6 interface. I also > assume that there=A0is another border router which connects the > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP > interface with a single locator: (IPisatap, site-internal > interface).=A0When the ISATAP router gets an IPv6 via its > external interface it will encapsulate the packet accordingly > and forward it through the internal IPv4 interface. If the > encapsulated packet is=A0destined to a node outside the site > then the only thing that stops it is=A0a proto-41 filtering > at the=A0other border router of the site. Did I get this right? > >=20 > =3D=3D> In this case, yes - the ip-proto-41 filtering is at a > =3D=3D> border router. I know of at least one major enterprise > =3D=3D> network that does this. >=20 > > It is only mentioned as a possible mitigation against > > incoming spurious protocol-41 packets. In addition, > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > > filtering.=A0Hence it=A0will not stop attack #2. >=20 > We are now talking about ip-proto-41 filtering; not ingress > filtering. ip-proto-41 filtering is in both directions. It > prevents ip-proto-41 packets from entering the enterprise > interior ISATAP site from the Internet and prevents > ip-proto-41 packets from entering the Internet ISATAP > site from the enterprise interior. Else the ISATAP > interface would span multiple sites. >=20 > Besides, "ingress" filtering is not about packets coming > from the Internet into the end site, but rather it is > about packets leaving the end site and going out into > the Internet. RFC2827 (BCP38) documents ingress filtering. > > OK. I see what you are saying here. > >=20 > =3D=3D> OK. >=20 > > In addition, > > as mentioned, protocol-41 filtering is not helpful when > > attack #3 is launched on two routers that reside in the > > same site. Note that=A0it=A0may be=A0possible for=A0the attack > > packet=A0to be sourced from outside the site unless proper > > filtering of incoming IPv6 packets is deployed. If the > > attacker resides in the site, usually ingress filtering > > will not be helpful since it is deployed in general on > > the site's border. >=20 > Here, we have the ISATAP router in both cases sourcing a > packet from a foreign prefix. > > Well, I do not see how this is correct. In attacks #1 and #3 the = ISATAP router sources (actually > forwards) an IPv6=A0packet with=A0a source address having=A0the = corresponding=A0prefix of the ISATAP tunnel. > In attacks #2 and #3 the ISATAP router sources and IPv4 packet with = its own IPv4 address as the > source address. > >=20 > =3D=3D> There were a number of errors in what I said in my last > =3D=3D> message, so let me see if I can get it right here: > =3D=3D> > =3D=3D> In attacks #1 and #2 there are two cases to consider. Case > =3D=3D> 1 in which a border router separates the 6to4 relay from the > =3D=3D> ISATAP router, and case 2 in which no border router separates > =3D=3D> the 6to4 relay from the ISATAP router. > =3D=3D> > =3D=3D> In attack #1, we have an IPv6 packet with a local source > =3D=3D> address entering the site from the outside. IPv6 ingress > =3D=3D> filtering at the site border router should prevent the > =3D=3D> packet from entering the site in the first place. If the > =3D=3D> 6to4 relay router is outside the site then ip-proto-41 > =3D=3D> filtering at the border router will block the attack in > =3D=3D> the first place anyway. If the relay router is *inside* > =3D=3D> the site, then the IPv6 ingress filtering is the lone > =3D=3D> mitigation. The end result is that the 6to4 relay should > =3D=3D> really be positioned outside of the site's border routers; > =3D=3D> otherwise, it could be spoofed into thinking that the > =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router. > =3D=3D> > =3D=3D> In attack #2, we have an IPv6 packet with a foreign source > =3D=3D> address being forwarded by the ISATAP router to a 6to4 > =3D=3D> relay, but I mis-spoke when I said that this would be a > =3D=3D> case of the ISATAP router forwarding a packet with a foreign > =3D=3D> source address out of the ISATAP link. For all the ISATAP > =3D=3D> router knows, the 6to4 relay is just an ordinary host on > =3D=3D> the ISATAP link, so the ISATAP router actually believes it > =3D=3D> is forwarding the packet *into* the ISATAP link (not out of > =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41 > =3D=3D> filtering at the border router between the ISATAP router and > =3D=3D> the 6to4 relay. If there is no border router between the = ISATAP > =3D=3D> router and the 6to4 relay, then we have an identical instance > =3D=3D> to attack #3 which I will discuss below. But, the best > =3D=3D> operational practice would again be to have the 6to4 relay > =3D=3D> oriented outside of a border router that filters ip-proto-41. > =3D=3D> > =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks it > =3D=3D> is talking to a 6to4 router and not an ISATAP router. In > =3D=3D> attack #2, the ISATAP router thinks it is talking to a > =3D=3D> simple host on the link and not a 6to4 relay. In both cases, > =3D=3D> the attacks are mitigated when there is an ip-proto-41 > =3D=3D> filtering border router between the ISATAP router and the > =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- > =3D=3D> interface router that implements 6to4 on a site-external > =3D=3D> IPv4 interface and implements ISATAP on a site-internal > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packets > =3D=3D> from outside the site with an IPv4 destination corresponding > =3D=3D> to the ISATAP interface. I will discuss attack #3 below: >=20 > This attack is mitigated by > IPv6 ingress filtering which is an IPv6 security consideration > and not an ISATAP nor IPv4 security consideration. BCP > recommendations for network ingress filtering are documented > in RFC2827 and it is expected that IPv6 routers that configure > ISATAP interfaces will implement IPv6 ingress filtering > according to the BCP. > > So If my last comment is correct than I do not see how ingress = filtering would help here. The only > case where=A0ingress filtering can help is in case of attack #3 when = the routers reside at the same > site. In that case if the attack packet (packet 0) is sent from = outside the site then ingress > filtering on the border of the site will drop the packet. > >=20 > =3D=3D> Correct about the IPv6 ingress filtering at the border, > =3D=3D> but as with attack #2 my error in the previous message > =3D=3D> was in thinking the ISATAP router A was forwarding the > =3D=3D> packet *out* of the ISATAP link when in fact from the > =3D=3D> ISATAP router's perspective it is forwarding the packet > =3D=3D> to a simple host *inside* of the link. > =3D=3D> > =3D=3D> The problem here is that the ISATAP router is blindly > =3D=3D> forwarding a packet to a node that it assumes is a simple > =3D=3D> host on the ISATAP link without first verifying that the > =3D=3D> node has demonstrated a willingness to participate as a > =3D=3D> host on the link. As you have pointed out, this can lead > =3D=3D> to strange scenarios when the anonymous node is a tunnel > =3D=3D> router of some sort that does not participate in the > =3D=3D> ISATAP link. > =3D=3D> > =3D=3D> It would not generally be possible for the ISATAP router > =3D=3D> to check whether the IPv6 destination address is an ISATAP > =3D=3D> address that embeds one of its own IPv4 addresses, because > =3D=3D> when IPv4 private addresses are used the same IPv4 address > =3D=3D> can (and often does) occur in multiple sites. So for example, > =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 > =3D=3D> and is asked to forward an IPv6 packet with ISATAP > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the > =3D=3D> IPv6 prefix is foreign, the router can't very well drop the > =3D=3D> packet as this would block legitimate communications. It > =3D=3D> is also not generally possible to check whether a foreign > =3D=3D> link is an ISATAP link by looking for the magic token > =3D=3D> "0:5EFE" as that token only has significance for ISATAP > =3D=3D> links and not other link types. > =3D=3D> > =3D=3D> Instead, the mitigation I think makes the most sense is > =3D=3D> for the ISATAP router to first verify that the node which > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a > =3D=3D> willingness to participate in the link. That can be done > =3D=3D> by having the ISATAP router first check the neighbor cache > =3D=3D> when it has a packet to send to verify that there is a > =3D=3D> cached entry corresponding to the destination. For nodes > =3D=3D> that are willing ISATAP hosts on the link, there would > =3D=3D> have been a neighbor cache entry created when the node > =3D=3D> sends a Router Solicitation to the ISATAP router for the > =3D=3D> purpose of discovering default router lifetimes and on- > =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP > =3D=3D> router to forward the packet only if there is a pre-existing > =3D=3D> neighbor cache entry and drop the packet otherwise. This > =3D=3D> implies that the router should keep neighbor cache entires > =3D=3D> for the duration of the minimum lifetime of the prefixes > =3D=3D> it advertises in its Router Advertisements. >=20 > > In general, I would like to point out that indeed as in > > most other attacks these attacks may also be mitigated by > > proper firewall rules. However, I do not believe that this > > should be our only answer against these attacks. I believe > > that since these attacks are made possible due to the > > inherent characteristics of the tunnels they=A0should be > > stopped intrinsically as much as possible by the tunnel > > participants and not relay on outside filtering rules. >=20 > In RFC5214, Section 10 we have: "restricting access to the > link can be achieved by restricting access to the site". The > mitigations do exactly that, and in such a way that ISATAP > nodes can operate with only the necessary and sufficient > checks. So on this point, I do not share your opinion. > > What about two ISATAP tunnels that reside on the same site like in = attack #3. Do you=A0also think that > proto-41 filtering should barrier between the two tunnels within the = site? > >=20 > =3D=3D> I think this may be overcome by the discussion above. > =3D=3D> Short story is that operational practices must be > =3D=3D> employed whereby an ISATAP router is not mistaken for > =3D=3D> a 6to4 router. This is through proper arrangement of > =3D=3D> 6to4 router/relay interfaces outside of the site border > =3D=3D> rather than inside, and ISATAP router interfaces inside > =3D=3D> of the site border rather than outside. Also proper > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at > =3D=3D> site borders. > =3D=3D> > =3D=3D> Also, when there are multiple ISATAP links within the > =3D=3D> same local IPv4 routing region, an ISATAP router should > =3D=3D> first verify a node's willingness to act as a host on > =3D=3D> the ISATAP link before blindly sending a packet to it. > =3D=3D> > =3D=3D> Fred > =3D=3D> fred.l.templin@boeing.com >=20 > Fred > fred.l.templin@boeing.com >=20 > ________________________________________ > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Monday, August 17, 2009 8:35:08 PM > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 >=20 > Gabi, >=20 > Thanks for publishing this work. In the document, attacks A, B and C > correspond to a configuration that violates section 6.2 of RFC5214: >=20 > > 6.2.=A0 ISATAP Interface Address Configuration > > > > =A0=A0Each ISATAP interface configures a set of locators consisting = of IPv4 > >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP > >=A0=A0 interface's locator set MUST NOT span multiple sites. >=20 > In particular, in scenarios A, B and C the IPv4 locator used for = ISATAP > is seen both within the enterprise as site #1 and within the global = Internet > itself as site #2. If the ISATAP interface is to be used as an = enterprise- > interior interface, it should therefore not accept IP-proto-41 packets > coming from an IPv4 source outside of the enterprise nor source > IP-proto-41 packets that are destined to an IPv4 node outside of the > enterprise. This condition should be satisfied by having the site = border > routers implement IPv4 ingress filtering and ip-protocol-41 filtering = as > required in Section 10 of RFC5214. >=20 > It is mentioned that attack C could also occur when the routers reside > in the same site, where their addresses may be private. This would > correspond to a case in which an attacker within the site attacks the > site itself, which can easily be traced - especially when source = address > spoofing from a node within the site is prevented through proper = ingress > filtering. >=20 > Fred > fred.l.templin@boeing.com >=20 > ________________________________________ > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Monday, August 17, 2009 8:21 AM > To: v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Routing loop attacks using IPv6 tunnels >=20 > Hi all, > I would like to draw the attention of the list = to=A0some=A0research=A0results which my colleague and I at > the National EW Research=A0& Simulation=A0Center have recently = published. The research presents a=A0class > of routing loop attacks that abuses 6to4, ISATAP and Teredo. = The=A0paper can be found at: > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf >=20 > Here is the abstract: > IPv6 is the future network layer protocol for the Internet. Since it = is not compatible with its > predecessor, some interoperability mechanisms were designed. An = important category of these > mechanisms is automatic tunnels, which enable IPv6 communication over = an IPv4 network without prior > configuration. This category includes ISATAP, 6to4 and Teredo. We = present a novel class of attacks > that exploit vulnerabilities in these tunnels. These attacks take = advantage of inconsistencies > between a tunnel's overlay IPv6 routing state and the native IPv6 = routing state. The attacks form > routing loops which can be abused as a vehicle for traffic = amplification to facilitate DoS attacks. > We exhibit five attacks of this class. One of the presented attacks = can DoS a Teredo server using a > single packet. The exploited vulnerabilities are embedded in the = design of the tunnels; hence any > implementation of these tunnels may be vulnerable. In particular, the = attacks were tested > against the ISATAP, 6to4 and Teredo implementations of Windows Vista = and Windows Server 2008 R2. >=20 > I think the results of the research warrant some corrective action. If = this=A0indeed shall be the > general sentiment of the list, I will be happy write an appropriate = I-D. The mitigation measures we > suggested in the paper are the best we could think of to completely = eliminate the problem. However > they are far from perfect since=A0they would require=A0tunnel = implementations to be updated in case new > types of automatic tunnels are introduced. >=20 > Your comments are welcome. >=20 > Gabi >=20 >=20 >=20 From Fred.L.Templin@boeing.com Mon Aug 24 13:53:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FB928C372; Mon, 24 Aug 2009 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-BbvKHnJzLv; Mon, 24 Aug 2009 13:53:04 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 8D50B28C36D; Mon, 24 Aug 2009 13:53:04 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7OKr6D2007877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 13:53:06 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7OKr6bd005336; Mon, 24 Aug 2009 13:53:06 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7OKr5xV005279; Mon, 24 Aug 2009 13:53:06 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 13:53:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Aug 2009 13:53:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pgAAhXLcA= References: <475898.88672.qm@web45510.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 24 Aug 2009 20:53:02.0615 (UTC) FILETIME=[DF0F2270:01CA24FC] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 20:53:05 -0000 Slight correction: > if (dst =3D=3D "*::0200:5efe:") > drop_pkt(); /* attack #3 mitigation */ should be: if (dst =3D=3D "::0200:5efe:") drop_pkt(); /* attack #3 mitigation */ Fred fred.l.templin@boeing.com From kent@bbn.com Mon Aug 24 19:10:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4693A6E5A; Mon, 24 Aug 2009 19:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFdfmp7szVG6; Mon, 24 Aug 2009 19:10:24 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A7D643A6963; Mon, 24 Aug 2009 19:10:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.4.160]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MfkYN-0006Eg-Fo; Mon, 24 Aug 2009 21:10:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> References: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.com> Date: Mon, 24 Aug 2009 22:10:28 -0400 To: "Davis, Terry L" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "mext-chairs@tools.ietf.org" , "secdir@ietf.org" , 'Sam Hartman' , "iesg@ietf.org" , "draft-ietf-mext-aero-reqs@tools.ietf.org" , "weddy@grc.nasa.gov" , "'Ivancic, William D. \(GRC-RHN0\)'" Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 02:10:25 -0000 At 3:48 PM -0700 8/21/09, Davis, Terry L wrote: >Sam > >One of the items that continues to seriously concern me across the >whole IP protocol RFC set is the basic lack of simple >vendor-to-vendor IP security interoperability! All of NEMO and MEXT >assumes that simple, easy to implement, IPSec, PKI, and IKE >interoperability exist; they do NOT. Terry, IPsec (not IPSec :-)) and IKE have been available in major host operating systems for a few years, so the phrase "easy to implement" is not generally a true assertion. Are you stating that the aviation industry needs to implement its own versions of these and analogous Interent protocols? Also, as for interoperability, I believe Paul Hoffman has reported a number of good results through his VPNC testing experiences. As for PKI, there are relying party implementations in all browsers, and in some OSes, and OpenSSL. The browsers interoperate with web servers (using SSL) developed by a few different vendors, which is a decent demo of interoperability for core PKI features. OpenCA and OpenSSL are decent (not perfect) examples of open source software for both RP and CA functions. Later you seem to be arguing that a single PKI (vs. IETF PKI and IPsec/IKE standards) is an essential feature for IPsec solutions. This is clearly not true in general. Is this another situation where aviation is "special?" I will not disagree with your assertion that many of the Ipsec/IKE and PKI products have hard to configure admin interfaces. But, that is an issue outside the scope of IETF standards. Also, I would observe that the typical CLI for a router is not an easy to use interface either. Steve From gwz@net-zen.net Mon Aug 24 19:32:03 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F1228C367 for ; Mon, 24 Aug 2009 19:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw6gjWsblxwc for ; Mon, 24 Aug 2009 19:32:03 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 7282B28C34F for ; Mon, 24 Aug 2009 19:32:03 -0700 (PDT) Received: (qmail 1996 invoked from network); 25 Aug 2009 02:31:51 -0000 Received: from unknown (71.231.55.1) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 25 Aug 2009 02:31:51 -0000 From: "Glen Zorn" To: , , "'Benoit Lourdelet \(blourdel\)'" , , "'Brian Haberman'" , "'Karen O'Donoghue'" Date: Mon, 24 Aug 2009 19:31:26 -0700 Organization: Network Zen Message-ID: <016001ca252c$25904100$70b0c300$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcolLCTTApFFO1pSRNWe+MFZxKd61g== Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 02:32:03 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. EDITORIAL Global: s/an NTP/a NTP/ s/an FQDN/a FQDN/ In section 2., the acronym "DHCPv6" should be expanded on first usage. The first paragraph of section 2.1 says: When using DHCPv6 to offer NTP Server location, and if there is a need to distribute a device with a hardcoded configuration, this configuration MUST NOT include server location that is not part of the organization that distribute this device. s/distribute/distributes in the last line. I don't understand what device is under discussion. Is it a DHCP server? A DHCP client? Also, Typical usage of this option is to specify an NTP Server that is part of the organization that operates the DHCPv6 server. This seems less clear than it should be to me; suggest rephrasing, perhaps as This option will typically be used by the organization operating the DHCPv6 server to provide data regarding the location of its own NTP server. The second paragraph of section 2.1 says: DNS can be used to redirect misconfigured clients to an unexisting IPv6 address instead of having to change the address of the NTP server itself. I don't know exactly what an "unexisting IPv6 address" is, nor why it would be a good thing to redirect misconfigured clients to one. Also, the acronym "FQDN" should be expanded on first usage. The third paragraph of section 2.1 says: "The DHCPv6 option for NTP is then restricted to server location." This construction is a little bit clumsy, I think; suggest changing to "The DHCPv6 option for NTP is therefore restricted to server location." In the first paragraph of section 3.0, the acronym "SNTP" should be expanded upon first usage; suggest changing "This option serves as a container for all the information related to one NTP server or SNTP server." to "This option serves as a container for all the information related to one NTP or Simple Network Time Protocol (SNTP) [RFC4335] server." This will also take care of one of the unused references mentioned below. The second paragraph of section 3.0 says: While the FQDN option offers the most deployment flexibility, resiliency as well as security, the IP address options are defined to cover cases where a dependancy to DNS is not desirable. I think that the readability of this sentence could be improved; suggest changing to While the FQDN option offers the most deployment Flexibility and resiliency as well as security, the IP address options are defined to cover cases where a DNS dependency is not desirable. The last paragraph of section 3.0 says: This document does not define any priority between the client's embedded configuration and the NTP servers or SNTP servers discovered via this option. Suggest changing to This document does not define any priority relationship between the client's embedded configuration (if any) and the NTP or SNTP servers discovered via this option. In the heading of section 4, capitalize "use" or just change the heading from "Examples of use" to "Examples". Section 4 seems somewhat less than useful to me, especially since the examples are inconsistent: the FQDN example uses the exact encoding of the FQDN, but the unicast and multicast address examples do not. I suggest either making the examples consistent by putting the actual address encoding of the addresses in the address examples or just getting rid of section 4 altogether. The references to RFC 4075 and RFC 4330 are defined but never used. Hope this helps. ~gwz From kent@bbn.com Mon Aug 24 20:42:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22793A6D1D for ; Mon, 24 Aug 2009 20:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAlEzOVKu7Eq for ; Mon, 24 Aug 2009 20:42:47 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E697B3A6C9F for ; Mon, 24 Aug 2009 20:42:46 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.4.160]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mflzj-0006UF-D4; Mon, 24 Aug 2009 22:42:47 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 24 Aug 2009 23:42:52 -0400 To: secdir@ietf.org, matthew.meyer@bt.com, jpv@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: swallow@cisco.com, adrian.farrel@huawei.com, loa@pi.nu Subject: [secdir] secdir review of draft-ietf-mpls-soft-preemption-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 03:42:51 -0000 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document (draft-ietf-mpls-soft-preemption-18.txt) defines a set of modifications to MPLS RSVP-TE to accommodate _soft_ preemption. The preemption facility is intended to offer a less draconian alternative to the basic preemption facility of MPLS RSVP, i.e., immediate displacement of a preempted LSP (label-switched path). The approach described here adopts a _make before break_ strategy, to minimize the impact of rerouting an LSP that is being preempted. In this model, preemption is initiated at some midpoint along an LSP, e.g., because another, higher priority traffic flow has been assigned to traverse the router in question. The authors note that if the cause of the preemption is the allocation of resources for a new flow, rather than actual data plane congestion, the hard preemption option is unduly disruptive. This is especially true if the environment in which the traffic is being carried supports multiple Diff-Serv levels. The security considerations section of this document refers to RFC 3209, the RSVP-TE (Extensions to RSVP for LSP tunnels) spec, stating that no new security issues arise as a result of defining the soft preemption capability introduced here. Since soft preemption is less intrusive than the (default) hard preemption, it seems likely that any DoS security concerns for LSPs that are preempted are subsumed by the more general RSVP security concerns addressed in 3209. An attack that would cause one or more router to inappropriately preempt traffic would have a less severe impact in this context, than in the current RSVP preemption model. However, as the authors note, soft preemption can cause temporary under provisioning of one of more nodes/links in a path, and this does represent a new security concern. I suggest that the authors notes this explicitly in the Security Considerations section. (They cite under-provisioning as a possible effect of this preemption approach, so it seems reasonable to cite this as a possible security issue.) RFC 3209 has a one paragraph security considerations section. For the most part this paragraph refers to the base RSVP spec (RFC 2205). It does note that the use of LSP tunnels reduces the filtering options available to an ?administration? and thus it suggests using address family SESSION objects of type IPv4 or IPv6. (This seems to be a very minimal filtering capability compared to normal IP source/destination address pair filtering.) A quick look at RFC 2205 shows that it contains a non-trivial security section (not the security considerations section mandated in later RFCs, but still about a page of text). This discussion is a bit superficial and uses technically poor security terminology. It also refers to a "work in progress" for "a part of the base RSVP specification" despite the normative nature of the cited document, (which was not issued as an RFC for over 2 years). RFC 2205 says that node authentication is effected via an Integrity object, an odd terminology mismatch. 2205 also uses the term "encrypted hash function" in pointing to the document that was later issued as RFC 2747. RFC 2747 describes use of a "keyed hash function" for integrity, and cites HMAC-MD5 as mandatory. The correct, generic terminology is a hash-based MAC, but the security AD at the time was not a stickler for technically accurate terminology, c.f. the TCP-MD5 "signature" option :. This suggests that an update to these earlier document may be in order. There are several minor typos in the text, but I'm confident that the RFC Editor will fix them during the AUTH48 interval. From sra@hactrn.net Tue Aug 25 09:30:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B353A6AFE; Tue, 25 Aug 2009 09:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1bI2ztVoliU; Tue, 25 Aug 2009 09:30:39 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) by core3.amsl.com (Postfix) with ESMTP id B4A1D3A6B32; Tue, 25 Aug 2009 09:30:39 -0700 (PDT) Received: from orodruin.hactrn.net (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "orodruin.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id F0765BA9E; Tue, 25 Aug 2009 16:30:12 +0000 (UTC) Received: from orodruin.hactrn.net (localhost [IPv6:::1]) by orodruin.hactrn.net (Postfix) with ESMTP id B6A8440C5; Tue, 25 Aug 2009 12:30:13 -0400 (EDT) Date: Tue, 25 Aug 2009 12:30:13 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090825163013.B6A8440C5@orodruin.hactrn.net> Cc: draft-ietf-opsawg-syslog-alarm@tools.ietf.org, opsawg-chairs@tools.ietf.org Subject: [secdir] Review of draft-ietf-opsawg-syslog-alarm-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 16:30:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft proposes an encoding of certain elements from the RFC 3877 Alarm MIB as "structed data" within the (IETF-flavored RFC 5424) syslog protocol, in effect using syslog as a transport for data semantically equivilent to SNMP traps. This draft only documents encodings for a small subset of the data available in the Alarm MIB, presumably this was not accidental (the Alarm MIB is a complex beast). The security considerations section of this draft covers the obvious issue (potential disclosure of sensitive information to unknown parties), but does not discuss rate limiting except by reference to RFC 5424's security considerations. The discussion of alarm throttling in the Alarm MIB may be relevant here: it requires a two second gap between repeated traps of the same type to reduce the risk of alarm flooding, and warns that even with this restriction there's still a risk of alarm flooding when multiple alarms of different types are active. A sentence or two in the security considerations section of this draft mentioning the alarm flooding issue and giving a more explicit reference to the rate limiting discussion in RFC 5424 would suffice, although a more detailed treatment would not be a bad thing if the WG has something more to say on the topic. Minor editorial note: I found the repeated phrasing "MUST be implemented" confusing when used in reference to optional fields. I understand the difference between "MUST be implemented" and "MUST be used," but the intent wasn't obvious until I re-read the normative text after reading the examples. From catherine.meadows@nrl.navy.mil Tue Aug 25 15:00:09 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFB028C32E; Tue, 25 Aug 2009 15:00:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlJ4Reyq1Uv3; Tue, 25 Aug 2009 15:00:08 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A64E928C32F; Tue, 25 Aug 2009 15:00:08 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n7PM06aG028555; Tue, 25 Aug 2009 18:00:06 -0400 (EDT) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n7PLxx30024915; Tue, 25 Aug 2009 18:00:03 -0400 (EDT) Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009082517595919456 ; Tue, 25 Aug 2009 17:59:59 -0400 Message-Id: <3DA42F93-811C-456E-983B-59102B9BB11F@nrl.navy.mil> From: Catherine Meadows To: secdir@ietf.org, iesg@ietf.org, hongseok.jeon@gmail.com, maximilian.riegel@nsn.com, sjjeong@etri.re.kr, gmonte@microsoft.com Content-Type: multipart/alternative; boundary=Apple-Mail-11-199974167 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 17:59:57 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] Secdir review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 22:00:09 -0000 --Apple-Mail-11-199974167 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This ID describes the transmission of IP4/IP6 over Ethernet in an access network deploying IEEE 802.16. Security is mentioned only in the Security Considerations section, which reads This document does not introduce any new vulnerabilities to IPv4 and IPv6 specifications or operations. The security of the IEEE 802.16 air interface between SSs and BS is the subject of [802.16] and the security issues of Ethernet bridging are the subjects of [802.1D]. The generic IP over Ethernet network using IEEE 802.16 emulates Ethernet link, since existing IPv4 and IPv6 security mechanisms over Ethernet can be still used. While the public access network ensures secure isolation of each of upstream link between hosts and AR, it still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing neighbor discovery processes and it does not introduce any new vulnerabilities over those of Ethernet bridging. This I found very hard to draw any conclusions from, although that may be partly because I don't have access to 802.16 or 802.1D. However, I would like to see a little more than just a blanket statement that this document does not introduce any new vulnerabilities, e.g. some supporting information. How are the security mechanisms of IPv4 and IPv6 supposed to work together with those of 802.16? How do the security issues of Ethernet bridging as described in 802.1D impact the security of IPv4 and IPv6? I don't think you need to go into a whole lot of detail here, since this is not the main focus of the document, but I would like to see more evidence than this. If there are other documents that address those issues you can just point to them. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail-11-199974167 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have reviewed this document = as part of the security directorate's ongoing effort to review all IETF = documents being processed by the IESG. 
These comments were = written primarily for the benefit of the security area = directors. 
 Document editors and WG chairs should = treat these comments just like any other last call = comments. 


This ID describes the = transmission of IP4/IP6 over Ethernet in an access network = deploying
IEEE 802.16.   Security is mentioned only in the = Security Considerations section, which = reads 

This document does =
not introduce any new vulnerabilities to IPv4 and
   IPv6 specifications or operations.  The security of the IEEE 802.16
   air interface between SSs and BS is the subject of [802.16] and the
   security issues of Ethernet bridging are the subjects of [802.1D].
   The generic IP over Ethernet network using IEEE 802.16 emulates
   Ethernet link, since existing IPv4 and IPv6 security mechanisms over
   Ethernet can be still used.  While the public access network ensures
   secure isolation of each of upstream link between hosts and AR, it
   still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing

   neighbor discovery processes and it does =
not introduce any new
   vulnerabilities over those of Ethernet bridging.
catherine.meadows@nrl.navy.= mil
=

= --Apple-Mail-11-199974167-- From terry.l.davis@boeing.com Tue Aug 25 16:35:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA163A6ACC; Tue, 25 Aug 2009 16:35:22 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU+NAXuXjYCS; Tue, 25 Aug 2009 16:35:21 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9C92F3A6A8F; Tue, 25 Aug 2009 16:35:21 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7PNYU56006068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2009 18:34:30 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7PNYU4n024877; Tue, 25 Aug 2009 18:34:30 -0500 (CDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7PNYTIP024872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 25 Aug 2009 18:34:30 -0500 (CDT) Received: from XCH-NW-CCR1V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 25 Aug 2009 16:34:29 -0700 From: "Davis, Terry L" To: "'Stephen Kent'" Date: Tue, 25 Aug 2009 16:34:28 -0700 Thread-Topic: [secdir] secdir review of draft-ietf-mext-aero-reqs8 Thread-Index: AcolKTpEqc8kjEfESqeUwuQ4EIDytQAraaew Message-ID: <2557049CDBC35B4EBD79CFACFEC045841CCF74B2@XCH-NW-CCR1V.nw.nos.boeing.com> References: <2557049CDBC35B4EBD79CFACFEC045841CCF748F@XCH-NW-CCR1V.nw.nos.boeing.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: "mext-chairs@tools.ietf.org" , "secdir@ietf.org" , 'Sam Hartman' , "iesg@ietf.org" , "draft-ietf-mext-aero-reqs@tools.ietf.org" , "weddy@grc.nasa.gov" , "'Ivancic, William D. \(GRC-RHN0\)'" Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 23:35:22 -0000 Steve Sorry if I confused this issue in this way. Aviation does not want to be "= special" in any area; PKIs or protocols. And aviation has long recognized = that no single PKI will ever serve it; hence our creation of the Exostar Ce= rtipath bridge. By governmental requirements around the globe, we will dea= l with a multitude of different PKIs and specific key/hash requirements in = our environment. We want to use generic standard Internet services but our= security environment will be more demanding than a typical enterprise or a= gency as we move from OSI to IP for new aviation communications. Aviation will be the first try (I'm aware of) at utilizing the IP security = protocols in a truly dynamic global heterogeneous environment. - An aircraft will have generally 1 to 4 active communications links at any= given time. - These will change almost continually between service providers and ground= portals. - Some aircraft, especially those that do continuous global circle routes, = will have 20 or more service providers for those various links in a 48 hour= period. - Each service provider is likely to have its' own unique security environm= ent and PKI. - There is no onboard IT staff! It all has to happen automatically to make= new security associations with the next link provider. Hence my skepticism on our ability to utilize the IP security protocols (re= gardless how you spell IPSec ;-) in a dynamic global mobile environment. If the IETF had not adopted the DHCP protocols they were provided with over= 15 years ago, we would not have global roaming connectivity today. No hot= spots, no international hotel usage, no laptop portability even between sit= es within the laptop's own enterprise, etc. =20 And providing global "dynamic security association negotiation" is outside = of the scope of IETF standards? To me, not providing a simple "dynamic security association" to insure that= our security protocols are fully interoperable and easily implementable in= a heterogeneous environment between different vendors would be an abdicati= on of our responsibility to the security of the Internet. I'll leave at "I think we have some more work to do!" Take care Terry PS: You can see some of these same issues in the various CI sectors also as= they attempt interoperation of between the various entities within sectors= . > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, August 24, 2009 7:10 PM > To: Davis, Terry L > Cc: 'Sam Hartman'; secdir@ietf.org; iesg@ietf.org; 'Ivancic, William D. > (GRC-RHN0)'; weddy@grc.nasa.gov; draft-ietf-mext-aero-reqs@tools.ietf.org= ; > mext-chairs@tools.ietf.org > Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8 >=20 > At 3:48 PM -0700 8/21/09, Davis, Terry L wrote: > >Sam > > > >One of the items that continues to seriously concern me across the > >whole IP protocol RFC set is the basic lack of simple > >vendor-to-vendor IP security interoperability! All of NEMO and MEXT > >assumes that simple, easy to implement, IPSec, PKI, and IKE > >interoperability exist; they do NOT. >=20 > Terry, >=20 > IPsec (not IPSec :-)) and IKE have been available in major host > operating systems for a few years, so the phrase "easy to implement" > is not generally a true assertion. Are you stating that the aviation > industry needs to implement its own versions of these and analogous > Interent protocols? Also, as for interoperability, I believe Paul > Hoffman has reported a number of good results through his VPNC > testing experiences. >=20 > As for PKI, there are relying party implementations in all browsers, > and in some OSes, and OpenSSL. The browsers interoperate with web > servers (using SSL) developed by a few different vendors, which is a > decent demo of interoperability for core PKI features. OpenCA and > OpenSSL are decent (not perfect) examples of open source software for > both RP and CA functions. >=20 > Later you seem to be arguing that a single PKI (vs. IETF PKI and > IPsec/IKE standards) is an essential feature for IPsec solutions. > This is clearly not true in general. Is this another situation where > aviation is "special?" >=20 > I will not disagree with your assertion that many of the Ipsec/IKE > and PKI products have hard to configure admin interfaces. But, that > is an issue outside the scope of IETF standards. Also, I would > observe that the typical CLI for a router is not an easy to use > interface either. >=20 >=20 > Steve From lha@kth.se Wed Aug 26 00:33:19 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA2028C16B; Wed, 26 Aug 2009 00:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv82hK0acrDf; Wed, 26 Aug 2009 00:33:18 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 48F0A28C1BF; Wed, 26 Aug 2009 00:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 8AB9D155920; Wed, 26 Aug 2009 09:32:43 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nzC8xJCh0Jdl; Wed, 26 Aug 2009 09:32:42 +0200 (CEST) Received: from [IPv6:2002:6334:ca6c::21e:c2ff:fec5:249f] (unknown [IPv6:2002:6334:ca6c:0:21e:c2ff:fec5:249f]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 949FB1558ED; Wed, 26 Aug 2009 09:32:39 +0200 (CEST) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 26 Aug 2009 00:32:06 -0700 Message-Id: To: IESG , Security-Directorat Directorat , bmwg-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) Cc: cpignata@cisco.com, aakhter@cisco.com, rajiva@cisco.com Subject: [secdir] secdir review: draft-ietf-bmwg-mpls-forwarding-meth-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 07:33:19 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes benchmarking activities for mpls networks. By documenting that they should happen only on private disconnected network make no security issues, even though the equipment should be configured as in production environments, so it should already be secured. I see no addition security consideration then whats already documented in the draft. Love From cpignata@cisco.com Wed Aug 26 06:39:01 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE683A691C for ; Wed, 26 Aug 2009 06:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+Iguk7MT99p for ; Wed, 26 Aug 2009 06:39:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E72AD3A67B1 for ; Wed, 26 Aug 2009 06:38:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,279,1249257600"; d="scan'208";a="55562181" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Aug 2009 13:36:25 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7QDaPYW005258; Wed, 26 Aug 2009 09:36:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7QDaPfU007996; Wed, 26 Aug 2009 13:36:25 GMT Received: from xmb-rtp-204.amer.cisco.com ([64.102.31.25]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 09:36:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 09:36:23 -0400 Message-ID: <6608454B8B7792499037C8D3AE5B63E3046FC240@xmb-rtp-204.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review: draft-ietf-bmwg-mpls-forwarding-meth-05.txt Thread-Index: AcomH26W9KSTSaszTSux7u/0lywMYQAMq/hA References: From: "Carlos Pignataro (cpignata)" To: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= , "Ron Bonica" , "Security-Directorat Directorat" , X-OriginalArrivalTime: 26 Aug 2009 13:36:25.0159 (UTC) FILETIME=[34FC1570:01CA2652] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1170; t=1251293785; x=1252157785; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpignata@cisco.com; z=From:=20=22Carlos=20Pignataro=20(cpignata)=22=20 |Subject:=20RE=3A=20secdir=20review=3A=20draft-ietf-bmwg-mp ls-forwarding-meth-05.txt |Sender:=20 |To:=20=3D?iso-8859-1?Q?Love_H=3DF6rnquist_=3DC5strand?=3D= 20,=0A=20=20=20=20=20=20=20=20=22Ron=20Bonica=22 =20,=0A=20=20=20=20=20=20=20=20=22Secur ity-Directorat=20Directorat=22=20,=0A=20=20 =20=20=20=20=20=20; bh=sKHc8S7EYUFHLs6dQ7u/B7ZvkI4XAnBFQYsBGeaB7zc=; b=a+b9oLVUaUhKCLQNelttGo1xM9n2qVlrAjyyXctDoMvv23Y2vHxkfIL5bn UUfm+I8kQ/5Ubdkm1lD0zl+In3VVqRWhO9q+TPTsaIgx3IynRbirsZv7NrKO TMJdVbzOIM; Authentication-Results: rtp-dkim-2; header.From=cpignata@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "Aamer Akhter \(aakhter\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [secdir] secdir review: draft-ietf-bmwg-mpls-forwarding-meth-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:39:01 -0000 Love, Many thanks for your review ! -- Carlos. -----Original Message----- From: Love H=F6rnquist =C5strand [mailto:lha@kth.se]=20 Sent: Wednesday, August 26, 2009 3:32 AM To: IESG; Security-Directorat Directorat; bmwg-chairs@tools.ietf.org Cc: Aamer Akhter (aakhter); Rajiv Asati (rajiva); Carlos Pignataro = (cpignata) Subject: secdir review: draft-ietf-bmwg-mpls-forwarding-meth-05.txt Hi, I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. This document describes benchmarking activities for mpls networks. By =20 documenting that they should happen only on private disconnected =20 network make no security issues, even though the equipment should be =20 configured as in production environments, so it should already be =20 secured. I see no addition security consideration then whats already documented =20 in the draft. Love From d3e3e3@gmail.com Wed Aug 26 06:49:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AEC3A6A48; Wed, 26 Aug 2009 06:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=1.282, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAzYap-U-WSu; Wed, 26 Aug 2009 06:49:10 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 99ABD3A67B1; Wed, 26 Aug 2009 06:49:09 -0700 (PDT) Received: by ewy3 with SMTP id 3so167952ewy.42 for ; Wed, 26 Aug 2009 06:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3vIwDDYeQsXcZFZ85gqy7kUuBAbbaEJrvurilCO/+fI=; b=HI5JK24XamBRW1UdgZl/QoiI8CTNs0jdXQWLr+DEXUfb3ify7piqW7dvU+UgeDa0h0 cnppIprYjq7YfkMeOC9m36OggCmudb6duhm6C3FT18e9Cxle/agmKNg2KRqXJZjS6F6d jx3yHMBuAdeBWUDRuaL4FMExMOYR1HZXm28BQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=inMxCuDbddzDgQZrhvE0pr/2ICjJEC1oFZzNtSllhQAydfVFIzHs7otG3+cNFzbvLe UNPAhfDrRivzprgRnKYKaUkDjjEaFfIUApBXXVWeSFlNURl0koGngMLJB8yyG/ucp37w wV+VTvFm0fub4ZFjDWKo4dYT5xXWy75jZgA1o= MIME-Version: 1.0 Received: by 10.216.86.73 with SMTP id v51mr1561982wee.89.1251292947325; Wed, 26 Aug 2009 06:22:27 -0700 (PDT) In-Reply-To: <00b701ca24de$8f53e4a0$adfbade0$@net> References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> Date: Wed, 26 Aug 2009 09:22:27 -0400 Message-ID: <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> From: Donald Eastlake To: Glen Zorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dan Romascanu , IETF Discussion , secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 13:49:11 -0000 Hi Glen, See below... On Mon, Aug 24, 2009 at 1:16 PM, Glen Zorn wrote: > Donald Eastlake [mailto:d3e3e3@gmail.com] writes: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0Document editors and WG chairs should treat these comments just >> like any other last call comments. > > Sorry for the rather slow response, but I honestly didn't know what to sa= y. OK. >> This document defines seven RADIUS Attributes to support the >> implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version >> 1). I would guess that RADIUS can be used between the 802.16 Base >> Station and an authorization server but I don't know how you could >> tell. >> Maybe I missed it but it looks like the RADIUS protocol isn't >> mentioned anywhere in 802.16-2004. From the text in some of these >> RADIUS attribute descriptions, it appears that they are not used >> between the Subscriber Station and the Base Stations but may be the >> basis of 802.16 Attributes that are used on that hop. Given this, I >> think a paragraph is needed (maybe even accompanied by a little ASCII >> art) at the beginning show what's going on would be useful. > > Your comments seem to suggest a lack of familiarity with RFC 2865 and the > RADIUS protocol in general. =A0Leaving aside the question of how one coul= d > expect to usefully review a document that _extends_ a protocol w/o > understanding the protocol being extended, RADIUS is only defined between= a > NAS (in this case, an 802.16 Base Station) and a RADIUS server. You have missed my point entirely. To evaluate extensions to RADIUS whose purpose is to support 802.16 seems to me to require not just a knowledge of RAIDUS but some knowledge of how RADIUS fits into 802.16 and what is needed for RADIUS, with these extensions, to support 802.16 security. My point was that, so far as I can tell, how RADIUS fits into 802.16 isn't documented in your draft or any document referenced by it. Doing a little more research, 802.16e-2005, which you don't reference, does begin to touch on this by at least specifying how EAP fits into 802.16. If above you are saying that the security of these new RADIUS attributes can be evaluated entirely based on a knowledge of RADIUS, I do not agree with this. If above, you are saying is that there is no need for there to be some explanation, in your draft or in some document referenced by it, of how RADIUS fits into 802.16 and that people who don't have an a priori knowledge of this should just keep their noses out of your document, I don't agree with that either. RFCs are supposed to be for the Internet community and there is presumably a reason that, for example, the RFC Editor requires acronyms that are not widely known to be expanded. Of course, it is not necessary or possible for most RFCs to be self contained and understandable in isolation, but I think it is reasonable to expect them to refer to other documents so that someone willing read enough and follow the reference chains can get a clear picture of what is going on. Thinking about it, I suggest that the Abstract be changed to something like the following and a similar change be made in the Introduction. (I note that the Introduction has a fairly long paragraph giving many details about 802.16 PKMV1 while failing to shed much light on how RADIUS or EAP fit into 802.16.) "RADIUS can be used by an IEEE 802.16 Base Station, acting as an EAP Authenticator, to communicate with a remote Authentication Server to authenticate 802.16 Subscriber Stations and support 802.16 Privacy Key Management Version 1. This document defines a set of additional RADIUS Attributes which are designed to enable this support." If you make this change and, due to my inferior knowledge, I've made any errors in the above paragraph, I'm sure you can fix it. >> Many document have security considerations section that only refer to >> other documents and may be missing specifics to the document contents. >> I think this document has the opposite problem good security specifics >> in the security consideration section but could usefully add >> references to the 802.16-2004 and RADiUS security sections. > > I'm not at all sure what 802.16 security has to do with RADIUS, but I gue= ss > I can add a reference to RFC 2869 in the Security Considerations section. Because you are extending RADIUS for the express purpose of supporting the 802.16 base station security function of authenticating subscriber stations. This is a base station function whose mechanism, as far as I can see, is glossed over in IEEE Standard 802.16-2004, which you reference but which has absolutely no mention RADIUS, NAS, AAA, EAP, Authentication Server, or anything along those lines. As above, by further research, I found that the IEEE 802.16e-2005 amendment to 802.1-2004 at least mentions EAP. I believe that 802.16e-2005 should be added to the references in the draft. Is it really such a burden, to provide some security context for what you are doing, to say something like: "Security consideration for IEEE 802.16 appear in Section 7 of 802.16-2004 and of 802.16e-2005. Security considerations for RADIUS extensions appear in RFC 2869." or the like? >> The security considerations section rightly warns to protect against >> modification of the PKM-Auth-Key attribute. But is it really clear >> there is no problem with modification of the Security Association ID >> attribute or the attribute listing cryptosuites? > > No, apparently not. =A0I had originally thought that modifying the list o= f > supported cryptosuites would just result in DoS, but that's not right. = =A0I'll > fix it. > >> The wording in Sections 3.1 and 3.2 see to almost be designed to allow >> the possibility of the multiple *-Cert Attributes carrying a >> certificate to appear in more than one Access-Request message. But I >> would assume that's not meaningful and/or was not intended to allow >> that. > > There is no way to do such a thing in standard RADIUS. That's what I thought and why I was puzzled as to why there was a more complex wording that appears to permit this. I suppose it is just the way the words struck me at the time I read them. But I would, instead of If multiple PKM-SS-Cert Attributes are contained within an Access-Request packet, they MUST be in order and MUST be consecutive attributes in the packet. have said These multiple PKM-SS-Cert Attributes MUST appear consecutively and in order within an Access-Request packet. and similarly for PKM-CA-Cert. Looking at this more closely now, I also think that the final "s" should be removed from "instances of the PKM-SS-Cert Attributes" and "instances of the PKM-CA-Cert Attributes". >> The table of attributes in Section 4 that gives the number of times >> each attribute can occur in different message types seems to have >> problems. Since there is no key giving it another meaning, I assume >> "0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are described >> as possibly occurring multiple times due to fragmentation of >> certificates. If the table is supposed to be in terms of logical >> attributes so that multiple PKM-SS-Cert attributes only count as one >> if they have parts of one certificate, then the table should say so. >> On the other hand, the PKM-SA-Descriptor attribute is shown as "0+", >> which presumably means zero or more, but the text description in 3.6 >> clearly says it can occur one or more times, which presumably would be >> written "1+". > > The relevant text from section 3.6 says "One or more instances of the > PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message." =A0RF= C > 2119 says about the keyword "MAY", "This word, or the adjective "OPTIONAL= ", > mean that an item is truly optional"; this says to me that zero, one or m= ore > instances of the PKM-SA-Descriptor Attribute can be in an =A0Access-Accep= t > message, just in a more compact and formal way. =A0If this is not clear, > however, I'm open to suggestions for alternate text. The wording is OK but I would suggest making it one letter longer so it starts "Zero or more ...". >> This whole table needs to be carefully checked, the >> inconsistencies resolved, and it should be clear if literal binary >> attributes or some sort of logical aggregate attributes (in the case >> of the "Cert" attributes at least), is being counted. > > I can add notes to the table regarding the "logical" vs. "physical" natur= e > of the PKM-*-Cert Attributes, as well as a key to the meaning of "0+", et= c. > Is that OK? Yes. >> The text between the Section 6. header line and the Section 6.1 header >> line as well as the Section 6.1 header line itself seem superfluous >> and can be deleted. > > Fine. > > ... > Thanks, Donald From gwz@net-zen.net Wed Aug 26 09:58:50 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A6D28C28B for ; Wed, 26 Aug 2009 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=1.957, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Af63k0TZk7p for ; Wed, 26 Aug 2009 09:58:49 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id E0D3B3A68E9 for ; Wed, 26 Aug 2009 09:58:48 -0700 (PDT) Received: (qmail 7131 invoked from network); 26 Aug 2009 16:58:55 -0000 Received: from unknown (71.231.55.1) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 26 Aug 2009 16:58:54 -0000 From: "Glen Zorn" To: "'Donald Eastlake'" References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> In-Reply-To: <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> Date: Wed, 26 Aug 2009 09:58:49 -0700 Organization: Network Zen Message-ID: <001501ca266e$7bd0f3f0$7372dbd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcomUEf16wCeDaZiTCOBHwvBgKiHxwAEIXvw Content-Language: en-us x-cr-hashedpuzzle: Bfjt Fsdp JYb/ Je5M N1Po P06Z U2Jy ZnBH b3i5 cm34 fNqY f41R gRXc gj8Q hcWt iH3W; 4; ZAAzAGUAMwBlADMAQABnAG0AYQBpAGwALgBjAG8AbQA7AGQAcgBvAG0AYQBzAGMAYQBAAGEAdgBhAHkAYQAuAGMAbwBtADsAaQBlAHQAZgBAAGkAZQB0AGYALgBvAHIAZwA7AHMAZQBjAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {29146CB4-ACC6-48CB-8CCD-A93F679ACD90}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Wed, 26 Aug 2009 16:58:41 GMT; UgBFADoAIABkAHIAYQBmAHQALQB6AG8AcgBuAC0AcgBhAGQAaQB1AHMALQBwAGsAbQB2ADEALQAwADUALgB0AHgAdAA= x-cr-puzzleid: {29146CB4-ACC6-48CB-8CCD-A93F679ACD90} Cc: 'Dan Romascanu' , 'IETF Discussion' , secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:58:50 -0000 Donald Eastlake [mailto:d3e3e3@gmail.com] writes:=20 ... > >> This document defines seven RADIUS Attributes to support the > >> implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management > version > >> 1). I would guess that RADIUS can be used between the 802.16 Base > >> Station and an authorization server but I don't know how you could > >> tell. > >> Maybe I missed it but it looks like the RADIUS protocol isn't > >> mentioned anywhere in 802.16-2004. From the text in some of these > >> RADIUS attribute descriptions, it appears that they are not used > >> between the Subscriber Station and the Base Stations but may be the > >> basis of 802.16 Attributes that are used on that hop. Given this, I > >> think a paragraph is needed (maybe even accompanied by a little > ASCII > >> art) at the beginning show what's going on would be useful. > > > > Your comments seem to suggest a lack of familiarity with RFC 2865 = and > the > > RADIUS protocol in general. =A0Leaving aside the question of how one > could > > expect to usefully review a document that _extends_ a protocol w/o > > understanding the protocol being extended, RADIUS is only defined > between a > > NAS (in this case, an 802.16 Base Station) and a RADIUS server. >=20 > You have missed my point entirely. To evaluate extensions to RADIUS > whose purpose is to support 802.16 seems to me to require not just a > knowledge of RAIDUS but some knowledge of how RADIUS fits into 802.16 > and what is needed for RADIUS, with these extensions, to support > 802.16 security. My point was that, so far as I can tell, how RADIUS > fits into 802.16 isn't documented in your draft or any document > referenced by it.=20 Right, that's because, as you have discovered & is the raison d'=EAtre = of this draft, RADIUS does not fit in with 802.16-2004 at all. The relationship between RADIUS and 802.16-2004 is basically identical to that between = RADIUS & PPP: RADIUS is a simple bolt-on allowing the centralization of authentication & authorization data (& concomitant scaling & = configuration benefits). You can search the set of RFCs defining PPP for a mention of RADIUS, but that search would be in vain even though RADIUS has been (& still is) used in virtually every PPP (PPPoE, PPPoA, ...) deployment. > Doing a little more research, 802.16e-2005, which > you don't reference, does begin to touch on this by at least > specifying how EAP fits into 802.16. I don't reference 802.16e-2005 because it's irrelevant to the draft; in fact, it's an almost completely different protocol. 802.16-2004 defines what is colloquially referred to as "fixed WiMAX", while 802.16e-2005 = forms the basis of "mobile WiMAX". Mobile WiMAX has a lot more features, is arguably more secure and is just generally sexier (mobility is all the = rage, you know ;-). For all these reasons & undoubtedly more of which I am unaware, the 802.16 WG has moved on & is no longer interested in fixed WiMAX; that doesn't mean that it is not useful, though. For example, = the public access network at the recent Olympic games in Beijing was based = upon 802.11 using 802.16 backhaul to a pre-existing FDDI ring. This made networking basically the entire city a project of months rather than = years, since the nearly impossible task of running physical cables was = unnecessary. As it stands, fixed WiMAX is well suited for this kind of relatively = static application, since the appropriate credentials, authorization data, etc. = can be configured into the base stations and left pretty much alone. = However, this kind of network design (.11<->.16<->some kind of wire) is also very appropriate in more dynamic situations; for example, building access networks in developing countries where the challenges & costs of running physical cabling would be even more problematic. Tack up a few .11/.16 gateways, plug in a .16 base station & voila! Instant Internet. So why = not just use mobile WiMAX & just not move (much ;-)? The problem is that = all those sexy mobility features make designing, testing & manufacturing = mobile WiMAX equipment much more expensive (obviously a major consideration). = The problem is that these instant networks are also quite dynamic & the base stations themselves may not be conveniently located, so it would be nice = to not have to configure the BS every time somebody hangs a new .11/.16 = gateway on a tent pole or schoolhouse wall. RADIUS support solves this problem = for fixed WiMAX in the same way it did for PPP. > If above you are saying that the security of these new RADIUS > attributes can be evaluated entirely based on a knowledge of RADIUS, I > do not agree with this.=20 Why not? > If above, you are saying is that there is no > need for there to be some explanation, in your draft or in some > document referenced by it, of how RADIUS fits into 802.16 and that > people who don't have an a priori knowledge of this should just keep > their noses out of your document, I don't agree with that either. RFCs > are supposed to be for the Internet community and there is presumably > a reason that, for example, the RFC Editor requires acronyms that are > not widely known to be expanded. Of course, it is not necessary or > possible for most RFCs to be self contained and understandable in > isolation, but I think it is reasonable to expect them to refer to > other documents so that someone willing read enough and follow the > reference chains can get a clear picture of what is going on. >=20 > Thinking about it, I suggest that the Abstract be changed to something > like the following and a similar change be made in the Introduction. > (I note that the Introduction has a fairly long paragraph giving many > details about 802.16 PKMV1 while failing to shed much light on how > RADIUS or EAP fit into 802.16.) As I mentioned above, that's because neither EAP nor RADIUS fit into 802.16-2004, which is the only standard that is relevant. >=20 > "RADIUS can be used by an IEEE 802.16 Base Station, acting as an EAP > Authenticator, to communicate with a remote Authentication Server to > authenticate 802.16 Subscriber Stations and support 802.16 Privacy Key > Management Version 1. This document defines a set of additional RADIUS > Attributes which are designed to enable this support." >=20 > If you make this change and, due to my inferior knowledge, I've made > any errors in the above paragraph, I'm sure you can fix it. Fine. The thing is that, except for the "acting as an EAP = Authenticator" part (which is false), I can't really see how this imparts much more information than the existing text (assuming familiarity w/RADIUS). But = if it will make you happy... >=20 > >> Many document have security considerations section that only refer > to > >> other documents and may be missing specifics to the document > contents. > >> I think this document has the opposite problem good security > specifics > >> in the security consideration section but could usefully add > >> references to the 802.16-2004 and RADiUS security sections. > > > > I'm not at all sure what 802.16 security has to do with RADIUS, but = I > guess > > I can add a reference to RFC 2869 in the Security Considerations > section. >=20 > Because you are extending RADIUS for the express purpose of supporting > the 802.16 base station security function of authenticating subscriber > stations. This is a base station function whose mechanism, as far as I > can see, is glossed over in IEEE Standard 802.16-2004, which you > reference but which has absolutely no mention RADIUS, NAS, AAA, EAP, > Authentication Server, or anything along those lines. As above, by > further research, I found that the IEEE 802.16e-2005 amendment to > 802.1-2004 at least mentions EAP. I believe that 802.16e-2005 should > be added to the references in the draft. As I mentioned above, 802.16e-2005 is completely irrelevant to this = draft. =20 >=20 > Is it really such a burden, to provide some security context for what > you are doing, to say something like: > "Security consideration for IEEE 802.16 appear in Section 7 of > 802.16-2004 and of 802.16e-2005. Security considerations for RADIUS > extensions appear in RFC 2869." or the like? No, it's not much of a burden for me. OTOH, I've read section 7 of 802.16-2004 a bunch of times & really haven't found anything like the Security Considerations section of an RFC. Furthermore, there's a huge amount of stuff (e.g., traffic encryption key management, etc.) in there that is, again, irrelevant to the draft and potentially confusing to the non-experts that I assume would be the intended audience. ... > >> The wording in Sections 3.1 and 3.2 see to almost be designed to > allow > >> the possibility of the multiple *-Cert Attributes carrying a > >> certificate to appear in more than one Access-Request message. But = I > >> would assume that's not meaningful and/or was not intended to allow > >> that. > > > > There is no way to do such a thing in standard RADIUS. >=20 > That's what I thought and why I was puzzled as to why there was a more > complex wording that appears to permit this. I suppose it is just the > way the words struck me at the time I read them. But I would, instead > of >=20 > If multiple PKM-SS-Cert > Attributes are contained within an Access-Request packet, they > MUST be in order and MUST be consecutive attributes in the > packet. >=20 > have said >=20 > These multiple PKM-SS-Cert Attributes MUST appear consecutively > and in order within an Access-Request packet. >=20 > and similarly for PKM-CA-Cert. Fine. >=20 > Looking at this more closely now, I also think that the final "s" > should be removed from "instances of the PKM-SS-Cert Attributes" and > "instances of the PKM-CA-Cert Attributes". Fine. > >> The table of attributes in Section 4 that gives the number of times > >> each attribute can occur in different message types seems to have > >> problems. Since there is no key giving it another meaning, I assume > >> "0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are > described > >> as possibly occurring multiple times due to fragmentation of > >> certificates. If the table is supposed to be in terms of logical > >> attributes so that multiple PKM-SS-Cert attributes only count as = one > >> if they have parts of one certificate, then the table should say = so. > >> On the other hand, the PKM-SA-Descriptor attribute is shown as = "0+", > >> which presumably means zero or more, but the text description in = 3.6 > >> clearly says it can occur one or more times, which presumably would > be > >> written "1+". > > > > The relevant text from section 3.6 says "One or more instances of = the > > PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message." > =A0RFC > > 2119 says about the keyword "MAY", "This word, or the adjective > "OPTIONAL", > > mean that an item is truly optional"; this says to me that zero, one > or more > > instances of the PKM-SA-Descriptor Attribute can be in an =A0Access- > Accept > > message, just in a more compact and formal way. =A0If this is not > clear, > > however, I'm open to suggestions for alternate text. >=20 > The wording is OK but I would suggest making it one letter longer so > it starts "Zero or more ...". Isn't that redundant? ... From hilarie@purplestreak.com Wed Aug 26 16:49:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DB13A6B02; Wed, 26 Aug 2009 16:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoE-2G-RF63x; Wed, 26 Aug 2009 16:49:38 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 40C413A68A8; Wed, 26 Aug 2009 16:49:38 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtp (Exim 4.62) (envelope-from ) id 1MgSFa-0007pg-EM; Wed, 26 Aug 2009 17:49:58 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MgSFI-00020P-Lr; Wed, 26 Aug 2009 17:49:41 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n7QNlY7t025790; Wed, 26 Aug 2009 17:47:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n7QNlXCp025786; Wed, 26 Aug 2009 17:47:33 -0600 Date: Wed, 26 Aug 2009 17:47:33 -0600 Message-Id: <200908262347.n7QNlXCp025786@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: rja@extremenetworks.com, mjbarnes@cisco.com, mfanto@aegisdatasecurity.com, tony.li@tony.li, acee@redback.com, manav@alcatel-lucent.com, akr@cisco.com, riw@cisco.com Subject: [secdir] Review of draft-ietf-ospf-hmac-sha-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 23:49:39 -0000 Review of draft-ietf-ospf-hmac-sha-06.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. My only comment on this greatly improved document concerns the last paragraph of section 4: Use of full digital signatures would ... eliminat[e] the replay issue that was noted above. Replay can remain a problem even with signed data, can't it? I think that two-way communication is may be a requirement for eliminating the possibility of replay. Hilarie From Radia.Perlman@sun.com Wed Aug 26 17:49:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2215D3A6BD0; Wed, 26 Aug 2009 17:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS6X8viBBB4Y; Wed, 26 Aug 2009 17:49:22 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 832E63A6A6B; Wed, 26 Aug 2009 17:49:22 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KP000L0RFMBQC00@mail-mta.sfvic.sunlabs.com>; Wed, 26 Aug 2009 17:49:23 -0700 (PDT) Received: from [192.168.29.100] ([96.240.113.234]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KP000FEQFM9XDK1@mail.sunlabs.com>; Wed, 26 Aug 2009 17:49:21 -0700 (PDT) Date: Wed, 26 Aug 2009 17:49:22 -0700 From: Radia Perlman To: secdir@ietf.org, iesg@ietf.org, stbryant@cisco.com, mshand@cisco.com Message-id: <4A95D812.8000304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Subject: [secdir] review of draft-ietf-rtgwg-lf-conv-frmwk-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 00:49:23 -0000 This is a "framework" document about various types of solutions for "microloops", which are temporary loops while a topology is stabilizing. I discussed my issues already with the authors, and other than two edits which they've agreed to, no problems. The two edits a) put in a definition of "microloop" b) rewrite the security considerations section, which is basically saying that this document is not actually proposing specific solutions, but instead is talking about the range of solutions that have been proposed, and that being specific about the security considerations of a solution would be done in the separate document that specifies the specifics of that solution. Radia From gwz@net-zen.net Wed Aug 26 18:31:03 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F9728C18C for ; Wed, 26 Aug 2009 18:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLnORM8rcMdA for ; Wed, 26 Aug 2009 18:31:02 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id C514C28C177 for ; Wed, 26 Aug 2009 18:31:02 -0700 (PDT) Received: (qmail 6634 invoked from network); 27 Aug 2009 01:24:29 -0000 Received: from unknown (71.231.55.1) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 27 Aug 2009 01:24:29 -0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'Donald Eastlake'" References: <006b01ca2692$fcda3500$f68e9f00$@net> In-Reply-To: <006b01ca2692$fcda3500$f68e9f00$@net> Date: Wed, 26 Aug 2009 18:24:21 -0700 Organization: Network Zen Message-ID: <00a001ca26b5$1b6e9b10$524bd130$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01CA267A.6F0FC310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcombVTUQ7+mO5CJSm21fdbLMgEuJAAAojfwABEe+oA= Content-Language: en-us Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:31:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01CA267A.6F0FC310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . PKMv1 has some fairly serious security problems that are described here: http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138 So I think the question is whether this document can make those serious security problems even worse, in a way that has not already been documented. AFAICT, this is not the case. The use of RADIUS doesn't improve the security of PKMv2 but it doesn't seem to reduce it either . The suggested use of the MS-MPPE-Send-Key Attribute may be problematic but seems pretty much unavoidable at present. I'd suggest that the document reference the known security issues that are covered in other documents, such as the ones above and others (such as RFC 3579) that describe weaknesses in the MPPE-Key attributes. OK The Security Considerations section now looks like this: 7. Security Considerations Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the RADIUS protocol. Section 3 of the paper "Security Enhancements for Privacy and Key Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the operation and vulnerabilities of the PKMv1 protocol. If the Access-Request message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Cryptosuite-List Attribute, weakening 802.16 security or disabling data encryption altogether. If the Access-Accept message is not subject to strong integrity protection, an attacker may be able to modify the contents of the PKM-Auth-Key Attribute. For example, the Key field could be replaced with a key known to the attacker. Although it is necessary for a plaintext copy of the Key field in the PKM-AUTH-Key Attribute to be transmitted in the Access-Accept message, this document does not define a method for doing so securely. In order to transfer the key securely, it is RECOMMENDED that it be encapsulated in an instance of the MS-MPPE-Send-Key Attribute [RFC2548]; however, see section 4.3.4 of RFC 3579 [RFC3579] for details regarding weaknesses in the encryption scheme used. Is that OK? . ------=_NextPart_000_00A1_01CA267A.6F0FC310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

…
PKMv1 has some fairly serious security problems that are described here:
http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138

So I think the question is whether this document can make those = serious
security problems even worse, in a way that has not already been
documented.

AFAICT, this is = not the case.  The use of RADIUS doesn’t improve the security of = PKMv2 but it doesn’t seem to reduce it either .  The suggested use of = the MS-MPPE-Send-Key Attribute may be problematic but seems pretty much unavoidable at = present.



I'd suggest that the document reference the known security
issues that are covered in other documents, such as the ones above = and
others (such as RFC 3579) that describe weaknesses in the MPPE-Key
attributes.

OK

The Security Considerations section now looks like this:

7.  Security = Considerations

 

   Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the

   RADIUS = protocol.

 

   Section 3 of the paper = "Security Enhancements for Privacy and Key

   Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the

   operation and vulnerabilities of = the PKMv1 protocol.

 

   If the Access-Request message is = not subject to strong integrity

   protection, an attacker may be = able to modify the contents of the

   PKM-Cryptosuite-List Attribute, weakening 802.16 security or

   disabling data encryption = altogether.

 

   If the Access-Accept message is = not subject to strong integrity

   protection, an attacker may be = able to modify the contents of the

   PKM-Auth-Key Attribute.  = For example, the Key field could be replaced

   with a key known to the = attacker.

 

   Although it is necessary for a plaintext copy of the Key field in the

   PKM-AUTH-Key Attribute to be transmitted in the Access-Accept

   message, this document does not = define a method for doing so

   securely.  In order to = transfer the key securely, it is RECOMMENDED

   that it be encapsulated in an = instance of the MS-MPPE-Send-Key

   Attribute [RFC2548]; however, = see section 4.3.4 of RFC 3579 [RFC3579]

   for details regarding weaknesses = in the encryption scheme used.

Is that OK?
…

------=_NextPart_000_00A1_01CA267A.6F0FC310-- From gwz@net-zen.net Wed Aug 26 18:40:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A923A70A6 for ; Wed, 26 Aug 2009 18:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o6eBOgWmRei for ; Wed, 26 Aug 2009 18:40:39 -0700 (PDT) Received: from smtpout06.prod.mesa1.secureserver.net (smtpout06-01.prod.mesa1.secureserver.net [64.202.165.224]) by core3.amsl.com (Postfix) with SMTP id 55C043A7095 for ; Wed, 26 Aug 2009 18:40:38 -0700 (PDT) Received: (qmail 28859 invoked from network); 27 Aug 2009 01:40:45 -0000 Received: from unknown (71.231.55.1) by smtpout06.prod.mesa1.secureserver.net (64.202.165.224) with ESMTP; 27 Aug 2009 01:40:45 -0000 From: "Glen Zorn" To: "'Donald Eastlake'" References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> In-Reply-To: <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> Date: Wed, 26 Aug 2009 18:40:37 -0700 Organization: Network Zen Message-ID: <00b101ca26b7$615bfe90$2413fbb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcomUEf16wCeDaZiTCOBHwvBgKiHxwAZYc7Q Content-Language: en-us Cc: 'Dan Romascanu' , 'IETF Discussion' , secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:40:40 -0000 Donald Eastlake [mailto:d3e3e3@gmail.com] writes: ... > >> The wording in Sections 3.1 and 3.2 see to almost be designed to > allow > >> the possibility of the multiple *-Cert Attributes carrying a > >> certificate to appear in more than one Access-Request message. But I > >> would assume that's not meaningful and/or was not intended to allow > >> that. > > > > There is no way to do such a thing in standard RADIUS. > > That's what I thought and why I was puzzled as to why there was a more > complex wording that appears to permit this. I suppose it is just the > way the words struck me at the time I read them. But I would, instead > of > > If multiple PKM-SS-Cert > Attributes are contained within an Access-Request packet, they > MUST be in order and MUST be consecutive attributes in the > packet. > > have said > > These multiple PKM-SS-Cert Attributes MUST appear consecutively > and in order within an Access-Request packet. > > and similarly for PKM-CA-Cert. OK. ... > >> This whole table needs to be carefully checked, the > >> inconsistencies resolved, and it should be clear if literal binary > >> attributes or some sort of logical aggregate attributes (in the case > >> of the "Cert" attributes at least), is being counted. > > > > I can add notes to the table regarding the "logical" vs. "physical" > nature > > of the PKM-*-Cert Attributes, as well as a key to the meaning of > "0+", etc. > > Is that OK? > > Yes. You were right, the entries for the PKM*Cert Attributes should have been 0+ instead of 0-1. The Table of Attributes now looks like this: The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Acct-Req # Attribute 0+ 0 0 0 0 TBD1 PKM-SS-Cert [Note 1] 0+ 0 0 0 0 TBD2 PKM-CA-Cert [Note 2] 0 0-1 0 0 0 TBD3 PKM-Config-Settings 0-1 0 0 0 0 TBD4 PKM-Cryptosuite-List 0-1 0 0 0 0 TBD5 PKM-SAID 0 0+ 0 0 0 TBD6 PKM-SA-Descriptor 0 0-1 0 0 0 TBD7 PKM-Auth-Key [Note 1] No more than one Subscriber Station Certificate may be transferred in an Access-Request packet. [Note 1] No more than one CA Certificate may be transferred in an Access- Request packet. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet 0+ Zero or more instances of this attribute MAY be present in packet 0-1 Zero or one instance of this attribute MAY be present in packet 1 Exactly one instance of this attribute MUST be present in packet Is that OK? ... From d3e3e3@gmail.com Wed Aug 26 18:47:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82BF28C37C; Wed, 26 Aug 2009 18:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2muqJ40yOwb; Wed, 26 Aug 2009 18:47:29 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 4FD8E28C369; Wed, 26 Aug 2009 18:47:29 -0700 (PDT) Received: by ewy3 with SMTP id 3so757295ewy.42 for ; Wed, 26 Aug 2009 18:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yaF0D/ZqPrC4EjeBHpWOyCOymXrmV1dY9T8Hnz7ln+k=; b=N+seEZuaOgaX6sByzK84MqTxhiAEE8i5RG+Cmrl20qWlVHqPAhWOL7FNQ3ISZ5hNLC M6FfhOcE/txAG2BeT1QuEqTe1flwFsR7GLG7xSLEWViY7lHiSnEn9vVv6/8RqupULpz1 /OFDULGZY8xVVrK874IrBKmuxy1Kvyq5upEmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nB0KnYUl94ADdx4qm8SZul50Ksx8spA7AepBFryUxpHnQHe9VISqH68lVOAYHZcQdH W1ERtxXmlMkKh4e1pYzvcUXEHdUtizyusHehxP5Mo8nO4bZ6qsk0LxZGg6gsUsAqsuB1 YmPBl00EwXf+j7LaUf9afZ5qccY1JvOBRuk38= MIME-Version: 1.0 Received: by 10.216.90.14 with SMTP id d14mr1793047wef.30.1251337650786; Wed, 26 Aug 2009 18:47:30 -0700 (PDT) In-Reply-To: <00b101ca26b7$615bfe90$2413fbb0$@net> References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com> <00b701ca24de$8f53e4a0$adfbade0$@net> <1028365c0908260622w507eafbbo6a35227be005f5ce@mail.gmail.com> <00b101ca26b7$615bfe90$2413fbb0$@net> Date: Wed, 26 Aug 2009 21:47:30 -0400 Message-ID: <1028365c0908261847k72154761kda2ba49f64ca158d@mail.gmail.com> From: Donald Eastlake To: Glen Zorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dan Romascanu , IETF Discussion , secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:47:30 -0000 Yes, the changes below look good to me. Thanks, Donald On Wed, Aug 26, 2009 at 9:40 PM, Glen Zorn wrote: > Donald Eastlake [mailto:d3e3e3@gmail.com] writes: > > ... > >> >> The wording in Sections 3.1 and 3.2 see to almost be designed to >> allow >> >> the possibility of the multiple *-Cert Attributes carrying a >> >> certificate to appear in more than one Access-Request message. But I >> >> would assume that's not meaningful and/or was not intended to allow >> >> that. >> > >> > There is no way to do such a thing in standard RADIUS. >> >> That's what I thought and why I was puzzled as to why there was a more >> complex wording that appears to permit this. I suppose it is just the >> way the words struck me at the time I read them. But I would, instead >> of >> >> =A0 =A0 =A0 =A0 =A0 If multiple PKM-SS-Cert >> =A0 =A0 =A0 Attributes are contained within an Access-Request packet, th= ey >> =A0 =A0 =A0 MUST be in order and MUST be consecutive attributes in the >> packet. >> >> have said >> >> =A0 =A0 =A0 These multiple PKM-SS-Cert Attributes MUST appear consecutiv= ely >> =A0 =A0 =A0 and in order within an Access-Request packet. >> >> and similarly for PKM-CA-Cert. > > OK. > > ... > >> >> This whole table needs to be carefully checked, the >> >> inconsistencies resolved, and it should be clear if literal binary >> >> attributes or some sort of logical aggregate attributes (in the case >> >> of the "Cert" attributes at least), is being counted. >> > >> > I can add notes to the table regarding the "logical" vs. "physical" >> nature >> > of the PKM-*-Cert Attributes, as well as a key to the meaning of >> "0+", etc. >> > Is that OK? >> >> Yes. > > You were right, the entries for the PKM*Cert Attributes should have been = 0+ > instead of 0-1. =A0The Table of Attributes now looks like this: > > =A0 The following table provides a guide to which attributes may be found > =A0 in which kinds of packets, and in what quantity. > > =A0 =A0 Request Accept Reject Challenge Acct-Req =A0# =A0 Attribute > =A0 =A0 0+ =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 = =A0 =A0 =A0TBD1 PKM-SS-Cert [Note 1] > =A0 =A0 0+ =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 = =A0 =A0 =A0TBD2 PKM-CA-Cert [Note 2] > =A0 =A0 0 =A0 =A0 =A0 0-1 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0TBD3 PKM-Config-Settings > =A0 =A0 0-1 =A0 =A0 0 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0TBD4 PKM-Cryptosuite-List > =A0 =A0 0-1 =A0 =A0 0 =A0 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0TBD5 PKM-SAID > =A0 =A0 0 =A0 =A0 =A0 0+ =A0 =A0 0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0TBD6 PKM-SA-Descriptor > =A0 =A0 0 =A0 =A0 =A0 0-1 =A0 =A00 =A0 =A0 =A00 =A0 =A0 =A0 =A0 0 =A0 =A0= =A0 =A0TBD7 PKM-Auth-Key > > =A0 [Note 1] > =A0 =A0 =A0No more than one Subscriber Station Certificate may be transfe= rred > =A0 =A0 =A0in an Access-Request packet. > > =A0 [Note 1] > =A0 =A0 =A0No more than one CA Certificate may be transferred in an Acces= s- > =A0 =A0 =A0Request packet. > > =A0 The following table defines the meaning of the above table entries. > > =A0 0 =A0 This attribute MUST NOT be present in packet > =A0 0+ =A0Zero or more instances of this attribute MAY be present in pack= et > =A0 0-1 Zero or one instance of this attribute MAY be present in packet > =A0 1 =A0 Exactly one instance of this attribute MUST be present in packe= t > > Is that OK? > > ... > > > From d3e3e3@gmail.com Wed Aug 26 19:36:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFF23A6AAA; Wed, 26 Aug 2009 19:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeoEdqKL0-fz; Wed, 26 Aug 2009 19:36:41 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 43DFD3A6805; Wed, 26 Aug 2009 19:36:41 -0700 (PDT) Received: by ewy3 with SMTP id 3so781417ewy.42 for ; Wed, 26 Aug 2009 19:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=71U6AQHRnftJUF0iO3/n2LcPhq2hCCgq/gGeonrry2E=; b=blYRkRkJqjOn6kc6qlcJSffmnLOqKNFTQjrcSJMmwnh/aCIuf+ram8dZ5zhjD+6i1U a13FFlLYkE+iZ/p6O8UOm3e+ZchpWtEbaMoFL96yYxIkpN8d9wK5T4MjRBqnrtiduGHf Pc/w5IeBaT6b1uayD+nKcbUXCLUJ8J/J5HIBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZAFi56HNIXb5PjV3Ia5JaQNoUP+m4wN0YPgolRtWrcbCnN0FjaUNufEVaH7H56qfZg +dKZeAx2lwn0IBfyCgo9cwJc8jpAY402EZruCkQw7fAWmP9VWTafJ/HSGPme2ZXvPSRQ FKEib6N2CL9rETeopicNbdHd/c7sbF7ZAQiZI= MIME-Version: 1.0 Received: by 10.216.11.84 with SMTP id 62mr1543326wew.148.1251340602397; Wed, 26 Aug 2009 19:36:42 -0700 (PDT) In-Reply-To: <00a001ca26b5$1b6e9b10$524bd130$@net> References: <006b01ca2692$fcda3500$f68e9f00$@net> <00a001ca26b5$1b6e9b10$524bd130$@net> Date: Wed, 26 Aug 2009 22:36:42 -0400 Message-ID: <1028365c0908261936k4ca79f30i5051be4ae8f11699@mail.gmail.com> From: Donald Eastlake To: Glen Zorn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 02:36:42 -0000 Looks OK to me, Donald On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorn wrote: > =85 > PKMv1 has some fairly serious security problems that are described here: > http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138 > > So I think the question is whether this document can make those serious > security problems even worse, in a way that has not already been > documented. > > AFAICT, this is not the case.=A0 The use of RADIUS doesn=92t improve the > security of PKMv2 but it doesn=92t seem to reduce it either .=A0 The sugg= ested > use of the MS-MPPE-Send-Key Attribute may be problematic but seems pretty > much unavoidable at present. > > I'd suggest that the document reference the known security > issues that are covered in other documents, such as the ones above and > others (such as RFC 3579) that describe weaknesses in the MPPE-Key > attributes. > > OK > > The Security Considerations section now looks like this: > > 7.=A0 Security Considerations > > > > =A0=A0 Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the > > =A0=A0 RADIUS protocol. > > > > =A0=A0 Section 3 of the paper "Security Enhancements for Privacy and Key > > =A0=A0 Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the > > =A0=A0 operation and vulnerabilities of the PKMv1 protocol. > > > > =A0=A0 If the Access-Request message is not subject to strong integrity > > =A0=A0 protection, an attacker may be able to modify the contents of the > > =A0=A0 PKM-Cryptosuite-List Attribute, weakening 802.16 security or > > =A0=A0 disabling data encryption altogether. > > > > =A0=A0 If the Access-Accept message is not subject to strong integrity > > =A0=A0 protection, an attacker may be able to modify the contents of the > > =A0=A0 PKM-Auth-Key Attribute.=A0 For example, the Key field could be rep= laced > > =A0=A0 with a key known to the attacker. > > > > =A0=A0 Although it is necessary for a plaintext copy of the Key field in = the > > =A0=A0 PKM-AUTH-Key Attribute to be transmitted in the Access-Accept > > =A0=A0 message, this document does not define a method for doing so > > =A0=A0 securely.=A0 In order to transfer the key securely, it is RECOMMEN= DED > > =A0=A0 that it be encapsulated in an instance of the MS-MPPE-Send-Key > > =A0=A0 Attribute [RFC2548]; however, see section 4.3.4 of RFC 3579 [RFC35= 79] > > =A0=A0 for details regarding weaknesses in the encryption scheme used. > > Is that OK? > =85 From bernard_aboba@hotmail.com Wed Aug 26 23:45:44 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4933A6A58; Wed, 26 Aug 2009 23:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=1.516, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ah5GNV0EitU; Wed, 26 Aug 2009 23:45:42 -0700 (PDT) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by core3.amsl.com (Postfix) with ESMTP id 7AD813A67AC; Wed, 26 Aug 2009 23:45:42 -0700 (PDT) Received: from BLU137-W26 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 23:45:49 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_34923521-8e13-4155-a168-27cdd70bea90_" X-Originating-IP: [97.120.168.211] From: Bernard Aboba To: , Date: Wed, 26 Aug 2009 23:45:48 -0700 Importance: Normal In-Reply-To: <1028365c0908261936k4ca79f30i5051be4ae8f11699@mail.gmail.com> References: <006b01ca2692$fcda3500$f68e9f00$@net> <00a001ca26b5$1b6e9b10$524bd130$@net> <1028365c0908261936k4ca79f30i5051be4ae8f11699@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2009 06:45:49.0331 (UTC) FILETIME=[034CCE30:01CA26E2] X-Mailman-Approved-At: Thu, 27 Aug 2009 00:23:38 -0700 Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 06:45:44 -0000 --_34923521-8e13-4155-a168-27cdd70bea90_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes=2C this looks good.=20 > Date: Wed=2C 26 Aug 2009 22:36:42 -0400 > Subject: Re: draft-zorn-radius-pkmv1-05.txt > From: d3e3e3@gmail.com > To: gwz@net-zen.net > CC: bernard_aboba@hotmail.com=3B ietf@ietf.org=3B secdir@ietf.org >=20 > Looks OK to me=2C > Donald >=20 > On Wed=2C Aug 26=2C 2009 at 9:24 PM=2C Glen Zorn wrote: > > =85 > > PKMv1 has some fairly serious security problems that are described here= : > > http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138 > > > > So I think the question is whether this document can make those serious > > security problems even worse=2C in a way that has not already been > > documented. > > > > AFAICT=2C this is not the case. The use of RADIUS doesn=92t improve th= e > > security of PKMv2 but it doesn=92t seem to reduce it either . The sugg= ested > > use of the MS-MPPE-Send-Key Attribute may be problematic but seems pret= ty > > much unavoidable at present. > > > > I'd suggest that the document reference the known security > > issues that are covered in other documents=2C such as the ones above an= d > > others (such as RFC 3579) that describe weaknesses in the MPPE-Key > > attributes. > > > > OK > > > > The Security Considerations section now looks like this: > > > > 7. Security Considerations > > > > > > > > Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the > > > > RADIUS protocol. > > > > > > > > Section 3 of the paper "Security Enhancements for Privacy and Key > > > > Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the > > > > operation and vulnerabilities of the PKMv1 protocol. > > > > > > > > If the Access-Request message is not subject to strong integrity > > > > protection=2C an attacker may be able to modify the contents of the > > > > PKM-Cryptosuite-List Attribute=2C weakening 802.16 security or > > > > disabling data encryption altogether. > > > > > > > > If the Access-Accept message is not subject to strong integrity > > > > protection=2C an attacker may be able to modify the contents of the > > > > PKM-Auth-Key Attribute. For example=2C the Key field could be repla= ced > > > > with a key known to the attacker. > > > > > > > > Although it is necessary for a plaintext copy of the Key field in th= e > > > > PKM-AUTH-Key Attribute to be transmitted in the Access-Accept > > > > message=2C this document does not define a method for doing so > > > > securely. In order to transfer the key securely=2C it is RECOMMENDE= D > > > > that it be encapsulated in an instance of the MS-MPPE-Send-Key > > > > Attribute [RFC2548]=3B however=2C see section 4.3.4 of RFC 3579 [RFC= 3579] > > > > for details regarding weaknesses in the encryption scheme used. > > > > Is that OK? > > =85 --_34923521-8e13-4155-a168-27cdd70bea90_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes=2C this looks good.

<= tbody>



>=3B Date: Wed=2C 26 Aug 200= 9 22:36:42 -0400
>=3B Subject: Re: draft-zorn-radius-pkmv1-05.txt
&= gt=3B From: d3e3e3@gmail.com
>=3B To: gwz@net-zen.net
>=3B CC: be= rnard_aboba@hotmail.com=3B ietf@ietf.org=3B secdir@ietf.org
>=3B
&= gt=3B Looks OK to me=2C
>=3B Donald
>=3B
>=3B On Wed=2C Aug= 26=2C 2009 at 9:24 PM=2C Glen Zorn<=3Bgwz@net-zen.net>=3B wrote:
&g= t=3B >=3B =85
>=3B >=3B PKMv1 has some fairly serious security pro= blems that are described here:
>=3B >=3B http://www2.computer.org/po= rtal/web/csdl/doi/10.1109/SNPD.2008.138
>=3B >=3B
>=3B >=3B S= o I think the question is whether this document can make those serious
&= gt=3B >=3B security problems even worse=2C in a way that has not already = been
>=3B >=3B documented.
>=3B >=3B
>=3B >=3B AFAICT= =2C this is not the case. =3B The use of RADIUS doesn=92t improve the>=3B >=3B security of PKMv2 but it doesn=92t seem to reduce it either= . =3B The suggested
>=3B >=3B use of the MS-MPPE-Send-Key Attri= bute may be problematic but seems pretty
>=3B >=3B much unavoidable = at present.
>=3B >=3B
>=3B >=3B I'd suggest that the document= reference the known security
>=3B >=3B issues that are covered in o= ther documents=2C such as the ones above and
>=3B >=3B others (such = as RFC 3579) that describe weaknesses in the MPPE-Key
>=3B >=3B attr= ibutes.
>=3B >=3B
>=3B >=3B OK
>=3B >=3B
>=3B >= =3B The Security Considerations section now looks like this:
>=3B >= =3B
>=3B >=3B 7. =3B Security Considerations
>=3B >=3B>=3B >=3B
>=3B >=3B
>=3B >=3B  =3B =3B Section 4= of RFC 3579 [RFC3579] discusses vulnerabilities of the
>=3B >=3B>=3B >=3B  =3B =3B RADIUS protocol.
>=3B >=3B
>=3B= >=3B
>=3B >=3B
>=3B >=3B  =3B =3B Section 3 of the= paper "Security Enhancements for Privacy and Key
>=3B >=3B
>= =3B >=3B  =3B =3B Management Protocol in IEEE 802.16e-2005" [SecE= n] discusses the
>=3B >=3B
>=3B >=3B  =3B =3B operati= on and vulnerabilities of the PKMv1 protocol.
>=3B >=3B
>=3B &g= t=3B
>=3B >=3B
>=3B >=3B  =3B =3B If the Access-Reque= st message is not subject to strong integrity
>=3B >=3B
>=3B &g= t=3B  =3B =3B protection=2C an attacker may be able to modify the c= ontents of the
>=3B >=3B
>=3B >=3B  =3B =3B PKM-Crypt= osuite-List Attribute=2C weakening 802.16 security or
>=3B >=3B
&= gt=3B >=3B  =3B =3B disabling data encryption altogether.
>= =3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B  =3B = =3B If the Access-Accept message is not subject to strong integrity
>= =3B >=3B
>=3B >=3B  =3B =3B protection=2C an attacker may = be able to modify the contents of the
>=3B >=3B
>=3B >=3B &nb= sp=3B =3B PKM-Auth-Key Attribute. =3B For example=2C the Key field = could be replaced
>=3B >=3B
>=3B >=3B  =3B =3B with a= key known to the attacker.
>=3B >=3B
>=3B >=3B
>=3B >= =3B
>=3B >=3B  =3B =3B Although it is necessary for a plaint= ext copy of the Key field in the
>=3B >=3B
>=3B >=3B  =3B=  =3B PKM-AUTH-Key Attribute to be transmitted in the Access-Accept
&= gt=3B >=3B
>=3B >=3B  =3B =3B message=2C this document doe= s not define a method for doing so
>=3B >=3B
>=3B >=3B  = =3B =3B securely. =3B In order to transfer the key securely=2C it i= s RECOMMENDED
>=3B >=3B
>=3B >=3B  =3B =3B that it be= encapsulated in an instance of the MS-MPPE-Send-Key
>=3B >=3B
&g= t=3B >=3B  =3B =3B Attribute [RFC2548]=3B however=2C see section = 4.3.4 of RFC 3579 [RFC3579]
>=3B >=3B
>=3B >=3B  =3B = =3B for details regarding weaknesses in the encryption scheme used.
>= =3B >=3B
>=3B >=3B Is that OK?
>=3B >=3B =85
= --_34923521-8e13-4155-a168-27cdd70bea90_-- From SCHISHOL@nortel.com Thu Aug 27 09:15:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72D33A68EB; Thu, 27 Aug 2009 09:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJge01xlfJkm; Thu, 27 Aug 2009 09:15:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5DBF73A6BB6; Thu, 27 Aug 2009 09:15:11 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7RGD2Q22174; Thu, 27 Aug 2009 16:13:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Aug 2009 12:15:09 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41A6CA365@zcarhxm2.corp.nortel.com> In-Reply-To: <20090825163013.B6A8440C5@orodruin.hactrn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-opsawg-syslog-alarm-02 Thread-Index: AcomPpkXTZuVHYX3Qamtd2NC4O2elgA8mdGQ References: <20090825163013.B6A8440C5@orodruin.hactrn.net> From: "Sharon Chisholm" To: "Rob Austein" , , X-Mailman-Approved-At: Thu, 27 Aug 2009 09:40:08 -0700 Cc: draft-ietf-opsawg-syslog-alarm@tools.ietf.org, opsawg-chairs@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-opsawg-syslog-alarm-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:15:12 -0000 Hi Thanks for the review. Rate limiting alarms is an interesting point and agree when you said "A sentence or two in the security considerations section of this draft mentioning the alarm flooding issue and giving a more explicit reference to the rate limiting discussion in RFC 5424 would suffice" We can add that. I'm at a bit of a loss as to how better to represent 'conditional mandatory' fields. Suggestions welcome. Sharon -----Original Message----- From: Rob Austein [mailto:sra@hactrn.net]=20 Sent: Tuesday, August 25, 2009 12:30 PM To: iesg@ietf.org; secdir@ietf.org Cc: draft-ietf-opsawg-syslog-alarm@tools.ietf.org; opsawg-chairs@tools.ietf.org Subject: Review of draft-ietf-opsawg-syslog-alarm-02 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft proposes an encoding of certain elements from the RFC 3877 Alarm MIB as "structed data" within the (IETF-flavored RFC 5424) syslog protocol, in effect using syslog as a transport for data semantically equivilent to SNMP traps. This draft only documents encodings for a small subset of the data available in the Alarm MIB, presumably this was not accidental (the Alarm MIB is a complex beast). The security considerations section of this draft covers the obvious issue (potential disclosure of sensitive information to unknown parties), but does not discuss rate limiting except by reference to RFC 5424's security considerations. The discussion of alarm throttling in the Alarm MIB may be relevant here: it requires a two second gap between repeated traps of the same type to reduce the risk of alarm flooding, and warns that even with this restriction there's still a risk of alarm flooding when multiple alarms of different types are active. A sentence or two in the security considerations section of this draft mentioning the alarm flooding issue and giving a more explicit reference to the rate limiting discussion in RFC 5424 would suffice, although a more detailed treatment would not be a bad thing if the WG has something more to say on the topic. Minor editorial note: I found the repeated phrasing "MUST be implemented" confusing when used in reference to optional fields. I understand the difference between "MUST be implemented" and "MUST be used," but the intent wasn't obvious until I re-read the normative text after reading the examples. From weiler+secdir@watson.org Thu Aug 27 18:54:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7762628C199 for ; Thu, 27 Aug 2009 18:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5MGQ0Mg6W99 for ; Thu, 27 Aug 2009 18:54:39 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 808D23A67B4 for ; Thu, 27 Aug 2009 18:54:39 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n7S1sjtt063616 for ; Thu, 27 Aug 2009 21:54:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n7S1sipR063612 for ; Thu, 27 Aug 2009 21:54:45 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 27 Aug 2009 21:54:44 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: 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.0.1 (fledge.watson.org [127.0.0.1]); Thu, 27 Aug 2009 21:54:45 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 01:54:40 -0000 Yaron Sheffer is next in the rotation. Please try to complete last call reviews by the end of the last call. For documents on telechat, note that the deadline field shown below reflects the telechat date, even though last call likely expires (or expired) before then. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-09-10 Reviewer Deadline Draft Barry Leiba TR2009-09-08 draft-drage-sipping-service-identification-03 Russ Mundy T 2009-09-08 draft-ietf-hip-nat-traversal-08 Magnus Nystrom T 2009-09-08 draft-ietf-pcn-baseline-encoding-05 Hilarie Orman T 2009-09-08 draft-ietf-pwe3-segmented-pw-13 Joe Salowey TR2009-09-08 draft-ietf-sipping-service-identification-03 Joe Salowey T 2009-09-08 draft-ietf-mip4-generic-notification-message-09 For telechat 2009-09-24 Reviewer Deadline Draft Derek Atkins TR2009-09-22 draft-ietf-roll-building-routing-reqs-06 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-08-17 draft-turner-deviceowner-attribute-01 Shawn Emery 2009-08-04 draft-ietf-alto-problem-statement-02 Phillip Hallam-Baker 2009-08-18 draft-ietf-pmol-sip-perf-metrics-03 Steve Hanna 2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04 Paul Hoffman 2009-08-31 draft-ietf-eai-imap-utf8-07 Love Hornquist-Astrand 2009-03-31 draft-ietf-ipfix-mib-07 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman 2009-06-29 draft-ietf-ipsecme-ikev2-redirect-13 Charlie Kaufman 2009-08-31 draft-ietf-mpls-3209-patherr-05 Scott Kelly 2009-08-31 draft-ietf-mpls-gmpls-lsp-reroute-04 Julien Laganier 2009-01-22 draft-ietf-sip-certs-08 Julien Laganier 2009-06-09 draft-ietf-enum-3761bis-04 Barry Leiba 2009-09-17 draft-iana-ipv4-examples-01 Chris Lonvick 2009-09-17 draft-daboo-srv-email-02 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy 2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14 Sandy Murphy 2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05 Eric Rescorla 2009-09-07 draft-ietf-tls-rfc4366-bis-05 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-11 Stefan Santesson 2009-09-08 draft-ietf-l3vpn-2547bis-mcast-bgp-07 Juergen Schoenwaelder 2009-09-08 draft-ietf-l3vpn-2547bis-mcast-08 Hannes Tschofenig 2009-04-23 draft-ietf-pce-monitoring-05 Hannes Tschofenig 2009-07-25 draft-ietf-pkix-ta-format-03 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-03 Nico Williams 2009-08-04 draft-ietf-dime-nai-routing-03 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-03 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 From scott@hyperthought.com Thu Aug 27 20:31:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3883628C34E for ; Thu, 27 Aug 2009 20:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ucbg4r-yyEd for ; Thu, 27 Aug 2009 20:31:39 -0700 (PDT) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by core3.amsl.com (Postfix) with ESMTP id 1363528C33C for ; Thu, 27 Aug 2009 20:31:39 -0700 (PDT) Received: from relay6.relay.iad.emailsrvr.com (localhost [127.0.0.1]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id 1D5247B829D; Thu, 27 Aug 2009 23:31:44 -0400 (EDT) Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 48A587B81E8; Thu, 27 Aug 2009 23:31:43 -0400 (EDT) Message-ID: <4A974FA1.6010400@hyperthought.com> Date: Thu, 27 Aug 2009 20:31:45 -0700 From: "Scott G. Kelly" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@ietf.org, lberger@labn.net, Dimitri.Papadimitriou@alcatel-lucent.be, jpv@cisco.com, mpls-chairs@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 03:31:39 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract does a good job of summarizing: This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. The security considerations section says the document introduces no new security considerations as it describes usage of existing formats and mechanisms, and I agree. It also points the reader to the security considerations sections of RFC4920 and RFC4736, and these do seem to do a reasonable job of summarizing. I see no issues of concern for the security area ADs with this document. --Scott From lberger@labn.net Fri Aug 28 04:45:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7341428C235 for ; Fri, 28 Aug 2009 04:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+0kkUuWqj51 for ; Fri, 28 Aug 2009 04:45:29 -0700 (PDT) Received: from outbound-mail-114.bluehost.com (outbound-mail-114.bluehost.com [69.89.24.4]) by core3.amsl.com (Postfix) with SMTP id 9F36D28C20C for ; Fri, 28 Aug 2009 04:45:29 -0700 (PDT) Received: (qmail 5013 invoked by uid 0); 28 Aug 2009 11:45:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 28 Aug 2009 11:45:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ja23Y9OSic60Ew5ygHikz+261M61HQXDNLR6KRsyJck0IeuzNMCAAm8vdg9GRDIA4Cmjwbs9yWitQ1Y0oJ6fWyi9OJQos0Oid+7y9VqVX4Be7u1AImNDPQBizPBOOcYw; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mgztg-0004jD-7A; Fri, 28 Aug 2009 05:45:36 -0600 Message-ID: <4A97C363.5030809@labn.net> Date: Fri, 28 Aug 2009 07:45:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: "Scott G. Kelly" References: <4A974FA1.6010400@hyperthought.com> In-Reply-To: <4A974FA1.6010400@hyperthought.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: iesg@ietf.org, mpls-chairs@tools.ietf.org, Dimitri.Papadimitriou@alcatel-lucent.be, jpv@cisco.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:45:30 -0000 Thank you for the review! Lou On 8/27/2009 11:31 PM, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The abstract does a good job of summarizing: This document describes how > Resource ReserVation Protocol (RSVP) PathErr Messages may be used to > trigger rerouting of Multi-Protocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label > Switched Paths (LSPs) without first removing LSP state or resources. > > The security considerations section says the document introduces no new > security considerations as it describes usage of existing formats and > mechanisms, and I agree. It also points the reader to the security > considerations sections of RFC4920 and RFC4736, and these do seem to do > a reasonable job of summarizing. > > I see no issues of concern for the security area ADs with this document. > > --Scott > > > From paul.hoffman@vpnc.org Fri Aug 28 09:14:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEBC3A699C for ; Fri, 28 Aug 2009 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.774 X-Spam-Level: X-Spam-Status: No, score=-4.774 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhgV-k5spi9B for ; Fri, 28 Aug 2009 09:14:37 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B75163A698C for ; Fri, 28 Aug 2009 09:14:37 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7SGEYIe072458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 09:14:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 28 Aug 2009 09:14:31 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Pete Resnick , Harald Alvestrand , Chris Newman , Xiaodong Lee Subject: [secdir] SecDir review of draft-ietf-eai-imap-utf8-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:14:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The security sections of this document are fine. The Security Considerations section says, in full: The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] apply to this specification, particularly with respect to use of UTF-8 in user names and passwords. Otherwise, this is not believed to alter the security considerations of IMAP4rev1. That should actually sufficient for implementers of this document. The new uses of UTF-8 described here should not cause an additional security problems beyond what IMAP implementers already face. The language used in the document is probably appropriate for an IMAP developer who has read lots of other IMAP extensions, but is quite rough for people reading this from an i18n or EAI perspective. The document *is not ready* for IESG review, however. In fact, it should not have been placed in IETF Last Call in its current state. Did anyone even read the Abstract, for crying out loud? Further, the I-D Nits checker finds two hard errors: a line the is obviously too long, and an obsolete normative reference. Even though this document hasn't garnered any other IETF Last Call comments, it really needs a careful review from the authors and the document shepherd. (The I-D tracker does not say who the document shepherd is, so I have Cc'd the two WG chairs on this note, assuming one of the two of them was the shepherd but that did not get reported to the tracker.) --Paul Hoffman, Director --VPN Consortium From Fred.L.Templin@boeing.com Fri Aug 28 09:23:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75963A6942; Fri, 28 Aug 2009 09:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19KFhrET1uV3; Fri, 28 Aug 2009 09:23:34 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 7D5773A6C6A; Fri, 28 Aug 2009 09:23:09 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SGNDxX025191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2009 09:23:13 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7SGNCeL017183; Fri, 28 Aug 2009 11:23:12 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7SGN6ew016973; Fri, 28 Aug 2009 11:23:12 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 09:23:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 09:23:03 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcoksCuqHixy6VRJRM+9z8CEAFFcGAAKv6pgAAhXLcAAv7YZEA== References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 28 Aug 2009 16:23:06.0629 (UTC) FILETIME=[D326CB50:01CA27FB] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:23:34 -0000 Gabi, Correct me if I am wrong, but if there were a new version of ISATAP that did not use ip-proto-41 encapsulation but instead used a different kind of encapsulation, then it need not concern itself with routing loop interactions with 6to4 relays since 6to4 relays only know about ip-proto-41. Does that match your understanding?=20 Thanks - Fred fred.l.templin@boeing.com From alexey.melnikov@isode.com Fri Aug 28 11:51:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0139C3A6A78 for ; Fri, 28 Aug 2009 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1h8vY1Pz4DH for ; Fri, 28 Aug 2009 11:51:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E34C83A6A67 for ; Fri, 28 Aug 2009 11:51:14 -0700 (PDT) Received: from [92.40.233.26] (92.40.233.26.sub.mbb.three.co.uk [92.40.233.26]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 28 Aug 2009 19:51:20 +0100 Message-ID: <4A98271A.2020601@isode.com> Date: Fri, 28 Aug 2009 19:51:06 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Harald Alvestrand , Chris Newman , Xiaodong Lee , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-eai-imap-utf8-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 18:51:16 -0000 Hi Paul, Thanks for the review. Paul Hoffman wrote: >The document *is not ready* for IESG review, however. In fact, it should not have been placed in IETF Last Call in its current state. > Arguably this is my fault, I was eager to get this document to IESG review due to external deadlines on EAI work. >Did anyone even read the Abstract, for crying out loud? > Well, Ok, I haven't read it recently. And nobody in the WG has spotted this: This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. which I will ask to remove. >Further, the I-D Nits checker finds two hard errors: a line the is obviously too long, and an obsolete normative reference. > While I agree that these should have been fixed, I personally don't think it is a big deal. In particular outdated references are regularly fixed by RFC Editor and frequently spotted during IESG review. (As a side note: on the last IESG telechat I saw a reference to a document that was obsoleted 3 times. This was quite impressive :-)). From gnakibly@yahoo.com Fri Aug 28 12:02:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DAA3A6ED7 for ; Fri, 28 Aug 2009 12:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+umdEVFpRXQ for ; Fri, 28 Aug 2009 12:02:31 -0700 (PDT) Received: from web45503.mail.sp1.yahoo.com (web45503.mail.sp1.yahoo.com [68.180.197.71]) by core3.amsl.com (Postfix) with SMTP id 79FE53A7184 for ; Fri, 28 Aug 2009 12:02:09 -0700 (PDT) Received: (qmail 27272 invoked by uid 60001); 28 Aug 2009 19:02:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251486135; bh=1rWX6Ca2vyI34/6hckZmzscZXLqhYMhK1M9hGa9EkCc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XxbgmzTAHKDDo72y1ls0UlSIB3baN74mwAEycMqKmANdeWGWJMrX5H9vG/6JQF1KazWtYAJCXEfeTODSDkkIGoR6SNd82bg6YtA6QwvVqQjnGBrAwPZE011jTJsMRGjgzORfAnmq/eUG9lXriPwvqX+Sth1mL/lhMbiCRTj/uEQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2mFoFaAGGoF25aNACEsW+AnHlymvWqCuQGNTAEEfH+C7GaiSLO24F7VLI6YwZ3VYIshw3w5kfnGfiUzYwGSVib5mQgQpTarI82ntDGdGow7cYhU993zrLtJFSlxZWZAH43uj6KNKBB25PB8Vqe4/CV8IJMGS4H6T8MSJiEl4PMY=; Message-ID: <31484.26522.qm@web45503.mail.sp1.yahoo.com> X-YMail-OSG: CDAsN4sVM1kTTvXTgBHqq7Z2wFNUjk8VQxgQHHWi_tcmAnJIrjN7fZtNrNsE2cXdyZwSlBL2wU08RYdAQPNQYPM38cauY5ebgxB4XzLKHIN6bJEhD6Q26L0ico8FF9Iz7vV9hCoUW5k0379fS.UJq.Rsd4q9Y93iUghJLT1TJNtJ1pXhn984eYSgmG55cQ44RyhXcRbzdv61xlTngNacRpOuZlh86KCKmJU9ymqwHnmPEAzLhNfTpN6lWgnPq5pbNISIBY1_ Received: from [89.138.8.21] by web45503.mail.sp1.yahoo.com via HTTP; Fri, 28 Aug 2009 12:02:14 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 Date: Fri, 28 Aug 2009 12:02:14 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:02:34 -0000 Fred,=0AA quick summary of our discussion up until now: the best mitigation= of=A0most of these=A0attacks is indeed the proto-41 and ingress filtering = on the border of the ISATAP site. If it is indeed implemented. I=A0assume t= hat not all sites deploy such filtering for lack of awareness or since the = proto-41 filtering may break other tunnels the site may employ. However, I = do not have hard evidence on this. I would be happy if others on the list w= ill refute or justify this assumption.=0A=A0=0AIf this assumption is (even = partially) correct than I think that the ISATAP router should defend itself= . Moreover, as I mention below the proo-41 filtering is not effective in ca= se of attack #3=A0and=A0the attacker is internal to the site. So IMHO the b= est way is the mitigations I suggested and that you illustrated below in ps= eudo-code.=0A=A0=0ASee=A0further comments inline.=0A=A0=0AGabi=0A=0A----- O= riginal Message ----=0A> From: "Templin, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A>= Cc: ipv6@ietf.org; secdir@ietf.org=0A> Sent: Monday, August 24, 2009 10:04= :34 PM=0A> Subject: RE: Routing loop attacks using IPv6 tunnels=0A> =0A> Ga= bi,=0A> =0A> > -----Original Message-----=0A> > From: Gabi Nakibly [mailto:= gnakibly@yahoo.com]=0A> > Sent: Monday, August 24, 2009 4:44 AM=0A> > To: T= emplin, Fred L; v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Subjec= t: Re: Routing loop attacks using IPv6 tunnels=0A> > =0A> > Fred,=0A> > I= =A0initially very much=A0liked your suggestion regarding the check=A0of the= =0A> neighbor cache before=0A> > forwarding a packet into the tunnel.=A0It= truly addresses the root cause of the =0A> problem ans is simple=0A> > eno= ugh to implement. However, I realized that an attacker can send a =0A> spoo= fed=A0RS to the ISATAP router=0A> > as if it came from the 6to4 relay. The = router would then send=A0a RA=A0to it=A0and =0A> consequently change its=0A= > > neighbor cache. So it seems=A0that this defense does not add much.=A0Wo= uldn't you =0A> agree?=0A> =0A> I agree that my proposed mitigation is only= useful when there=0A> is assurance of a coherent neighbor cache in the ISA= TAP router.=0A> That would be true in the case in which the ISATAP router i= s=0A> located within a site protected by border routers that perform=0A> ip= -proto-41 and ingress filtering, and in which there is no=0A> untraceable I= Pv4 source address spoofing. So AFAICT, my proposed=0A> mitigation is still= necessary for preventing attack #3 when=0A> ISATAP routers A and B are on = separate ISATAP links within=0A> the same site-internal IPv4 routing region= .=0A> =0A=0AThis is only true when the attacker is outside the site and pro= to-41 filtering is employed. If the attacker is internal to the site then t= he proto-41 filtering will not help and the neighbor cache can be poisoned.= =0A=0A> > I completely agree with your observation on the non-feasibility o= f =0A> verifying=A0that the=0A> > destination=A0ISATAP address does not inc= lude=A0a local=A0IPv4 address=A0since the =0A> ISATAP address may include= =0A> > a private IPv4 address. On the other hand, a check on public IPv4 ad= dresses is =0A> acceptable.=A0If the=0A> > check would be done only on ISAT= AP addresses that include public IPv4 =0A> addresses then this will=0A> > e= liminate the attacks in which the two victims reside=A0at different sites. = Note =0A> that if attack #3=A0is=0A> > launched on two ISATAP routers=A0hav= ing private addresses at two different sites =0A> then the attack will=0A> = > not work anyway since one router can not send a direct=A0IPv4 packet to t= he =0A> other. In addition,=0A> > to=A0mitigate attacks in which the other = victim is a 6to4 relay (such as attack =0A> #1) then a check would=0A> > ha= ve to be done on a 6to4 address, i.e. the destination address must not be = =0A> "2002:> > the ISATAP router>::*". In this case the IPv4 address must b= e public, =0A> according to=0A> >=A0 the 6to4 spec.=0A> > =0A> > As you als= o noted there is another problem with this check since the string =0A> "200= ::5EFE" is not unique=0A> > to ISATAP links. On the other hand, it seems th= at the probability to encounter =0A> a non-malicious packet=0A> > with a de= stination address having an IID that equals "200:5EFE:> IPv4 address>" is= =0A> > pretty slim.=0A> > =0A> > This check is definitely not a=A0perfect s= olution, and I sure hope that someone =0A> will come up with a=0A> > better= one for mitigating the routing loops. However, I would be happy if =0A> th= ere is some kind of other=0A> > mitigation=A0measures besides packet filter= ing=A0(proto-41 and ingress) by=A0other =0A> nodes (which=A0does not=0A> > = necessarily exist).=0A> =0A> You seem to be envisioning a scenario of ISATA= P router operation=0A> with public IPv4 addresses and outside of any site b= order routers=0A> that perform ingress filtering and ip-proto-41 filtering.= That has=0A> traditionally been seen as the domain of 6to4, but I am happy= to=0A> discuss the possibility of what I called the "inside-out ISATAP=0A>= model" in a list message long ago (which AFAICT is the scenario=0A> you ar= e alluding to).=0A> =0A=0AWell,=A0I am referring to any=A0ISATAP deployment= =A0with public IPv4 addresses and no proto-41 filtering. I imagine that in = practice there are such deployments which are not the "inside-out ISATAP mo= del"=A0. However, I must admit that I do not rely here on hard evidence.=0A= =0A> So, if the public IPv4 Internet were considered as one gigantic=0A> "s= ite" and we wanted to do ISATAP on that site, it would be nice=0A> to divid= e the site into multiple logical partitions, with each=0A> partition identi= fied by a PRL name and a unique set of IPv6=0A> prefixes. But then, we have= the scenario you are describing in=0A> which we can't trust the integrity = of the ISATAP router's=0A> neighbor cache due to the possibility for untrac= eable IPv4=0A> source address spoofing such that the neighbor cache check= =0A> mitigation can be subverted.=0A> =0A> This means that if we want to su= pport the inside-out ISATAP=0A> model then the routing loops could be mitig= ated either by=0A> 1) implementing the destination address checks you are= =0A> suggesting, or 2) by not allowing ISATAP router interfaces=0A> that ar= e not behind filtering border routers to advertise=0A> non-link-local on-li= nk IPv6 prefixes and/or forward packets=0A> from non-link-local prefixes in= the first place.=0A> =0A> If we took the easy way out and did 2), then the= entire=0A> IPv4 Internet would look like one gigantic ISATAP link that=0A>= only did IPv6 link-local. So, nodes could ping6 each others'=0A> ISATAP li= nk-local addresses but that's about it. =0A> =0A> If we took the more ambit= ious route and allowed ISATAP to=0A> flourish fully within the global IPv4 = Internet, then we=0A> would essentially be deprecating 6to4 - so it isn't= =0A> surprising that your address checks mostly involve 6to4=0A> suppressio= n. Assuming this, if I read your attack scenarios=0A> 1 through 3 correctly= then scenarios 1 and 3 are mitigated=0A> by a receive-side check and scena= rio 2 is mitigated by a=0A> send-side check. In particular, the pseudo-code= would be:=0A> =0A> =A0 isatap_rcv() {=0A> =A0 =A0 ...=0A> =A0 =A0 if (dst = =3D=3D "2002:::*")=0A> =A0 =A0 =A0 drop_pkt(); /* attack #1 m= itigation */=0A> =0A> =A0 =A0 if (dst =3D=3D "*::0200:5efe:")= =0A> =A0=A0=A0 drop_pkt(); /* attack #3 mitigation */=0A> =A0 =A0 ...=0A> = =A0 }=0A> =0A=A0=0ACorrect (with the correction you sent after this email).= =0A=0A> =A0 isatap_xmt() {=0A> =A0 =A0 ...=0A> =A0 =A0 if (dst =3D=3D "*::0= 200:5efe:192.88.99.1")=0A> =A0 =A0 =A0 drop_pkt(); /* attack #2 mitigation = */=0A> =A0 =A0 ...=0A> =A0 }=0A=A0=0AThis will not necessarily work, since = the 6to4 relay may have a=A0unicast address the ISATAP router may not be aw= are of. The best way to mitigate attack #2 is=A0by the 6to4 relay with a ch= eck similar to that of attack #2 above. IMO, the second best way, as Remi s= uggested on another thread, is for the ISATAP router to drop the packet if = (src=A0 =3D=3D 2002:::*"). However, this check is useful only= when the 6to4 relay validates that the IPv6 source address corresponds to = the IPv4 one (this is in=A0accordance=A0with the 6to4 spec, however it does= not always get implemented). If this is not true then the attacker does no= t have to send the attack packet with such an address.=0A=A0=0A> =0A> Does = the above look right to you? And is this everything,=0A> or are there other= scenarios we need to consider?=0A>=A0=0A=0A=0A> Thanks - Fred=0A> fred.l.t= emplin@boeing.com=0A> =0A> > =0A> > Gabi=0A> > =0A> > ----- Original Messag= e ----=0A> > From: "Templin, Fred L" =0A> > To: Gabi Nakibly ; v6ops =0A> >= Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Sent: Wednesday, August 19, 2009 = 6:16:18 PM=0A> > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> >= =0A> > Hi Gabi,=0A> > =0A> > I'm sorry to have to keep turning this into p= laintext,=0A> > but annotation is difficult otherwise. See below for=0A> > = my responses (=3D=3D>):=0A> > =0A> > ______________________________________= __=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Wednesd= ay, August 19, 2009 1:49 AM=0A> > To: Templin, Fred L; v6ops=0A> > Cc: ipv6= @ietf.org; secdir@ietf.org=0A> > Subject: Re: Routing loop attacks using IP= v6 tunnels=0A> > =0A> > Fred,=0A> > See my comments inline ().=0A> > =0A> >= ________________________________________=0A> > From: "Templin, Fred L" =0A= > > To: Gabi Nakibly ; v6ops =0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> = > Sent: Tuesday, August 18, 2009 6:48:45 PM=0A> > Subject: RE: Routing loop= attacks using IPv6 tunnels=0A> > =0A> > Gabi,=0A> > =0A> > _______________= _________________________=0A> > From: Gabi Nakibly [mailto:gnakibly@yahoo.c= om]=0A> > Sent: Tuesday, August 18, 2009 3:29 AM=0A> > To: Templin, Fred L;= v6ops=0A> > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Subject: Re: Rout= ing loop attacks using IPv6 tunnels=0A> > >=0A> > > Indeed the ISATAP inter= face of the ISATAP router is meant=0A> > > to be an enterprise-interior (no= te that=A0it is still=A0assumed=0A> > > that the associated IPv4 address is= =A0non-private). As=A0we=0A> > > explicitly note in the paper, the first th= ree attacks=A0will=0A> > > be mitigated=A0if proper protocol-41 filtering i= s deployed on=0A> > > the site's border. However, note that RFC5214 does no= t mandate=0A> > > or require this filtering.=0A> > =0A> > The RFC5214 Secur= ity Considerations makes clear the=0A> > consequences of not implementing I= Pv4 ingress filtering=0A> > and ip-protocol-41 filtering (i.e., a possible = spooing=0A> > attack in which spurious ip-protocol-41 packets are=0A> > inj= ected into an ISATAP link from outside). RFC5214=0A> > Section 6.2 addition= ally requires that an ISATAP interface's=0A> > locator set MUST NOT span mu= ltiple sites. This means that the=0A> > ISATAP interface must not decapsula= te nor source ip-proto-41=0A> > packets within multiple sites, where the en= terprise interior=0A> > is site #1 and the global Internet is site #2. ip-p= rotocol-41=0A> > filtering is the way in which the ISATAP interface is=0A> = > restricted to a single site.=0A> > =0A> > Now let me see that I understan= d Section 6.2 correctly. In=0A> > attack #2, for example, I assume the ISAT= AP router has two=0A> > physical interfaces. A site-internal IPv4 interface= with an=0A> > address IPisatap and a site-external IPv6 interface. I also= =0A> > assume that there=A0is another border router which connects the=0A> = > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0A> > interf= ace with a single locator: (IPisatap, site-internal=0A> > interface).=A0Whe= n the ISATAP router gets an IPv6 via its=0A> > external interface it will e= ncapsulate the packet accordingly=0A> > and forward it through the internal= IPv4 interface. If the=0A> > encapsulated packet is=A0destined to a node o= utside the site=0A> > then the only thing that stops it is=A0a proto-41 fil= tering=0A> > at the=A0other border router of the site. Did I get this right= ?=0A> > =0A> > =0A> > =3D=3D> In this case, yes - the ip-proto-41 filtering= is at a=0A> > =3D=3D> border router. I know of at least one major enterpri= se=0A> > =3D=3D> network that does this.=0A> > =0A> > > It is only mentione= d as a possible mitigation against=0A> > > incoming spurious protocol-41 pa= ckets. In addition,=0A> > > Section 10 of RFC5214 only mentions=A0ingress n= ot=A0egress=0A> > > filtering.=A0Hence it=A0will not stop attack #2.=0A> > = =0A> > We are now talking about ip-proto-41 filtering; not ingress=0A> > fi= ltering. ip-proto-41 filtering is in both directions. It=0A> > prevents ip-= proto-41 packets from entering the enterprise=0A> > interior ISATAP site fr= om the Internet and prevents=0A> > ip-proto-41 packets from entering the In= ternet ISATAP=0A> > site from the enterprise interior. Else the ISATAP=0A> = > interface would span multiple sites.=0A> > =0A> > Besides, "ingress" filt= ering is not about packets coming=0A> > from the Internet into the end site= , but rather it is=0A> > about packets leaving the end site and going out i= nto=0A> > the Internet. RFC2827 (BCP38) documents ingress filtering.=0A> > = =0A> > OK. I see what you are saying here.=0A> > =0A> > =0A> > =3D=3D> OK.= =0A> > =0A> > > In addition,=0A> > > as mentioned, protocol-41 filtering is= not helpful when=0A> > > attack #3 is launched on two routers that reside = in the=0A> > > same site. Note that=A0it=A0may be=A0possible for=A0the atta= ck=0A> > > packet=A0to be sourced from outside the site unless proper=0A> >= > filtering of incoming IPv6 packets is deployed. If the=0A> > > attacker = resides in the site, usually ingress filtering=0A> > > will not be helpful = since it is deployed in general on=0A> > > the site's border.=0A> > =0A> > = Here, we have the ISATAP router in both cases sourcing a=0A> > packet from = a foreign prefix.=0A> > =0A> > Well, I do not see how this is correct. In a= ttacks #1 and #3 the ISATAP router =0A> sources (actually=0A> > forwards) a= n IPv6=A0packet with=A0a source address having=A0the corresponding=A0prefix= =0A> of the ISATAP tunnel.=0A> > In attacks #2 and #3 the ISATAP router so= urces and IPv4 packet with its own =0A> IPv4 address as the=0A> > source ad= dress.=0A> > =0A> > =0A> > =3D=3D> There were a number of errors in what I = said in my last=0A> > =3D=3D> message, so let me see if I can get it right = here:=0A> > =3D=3D>=0A> > =3D=3D> In attacks #1 and #2 there are two cases = to consider. Case=0A> > =3D=3D> 1 in which a border router separates the 6t= o4 relay from the=0A> > =3D=3D> ISATAP router, and case 2 in which no borde= r router separates=0A> > =3D=3D> the 6to4 relay from the ISATAP router.=0A>= > =3D=3D>=0A> > =3D=3D> In attack #1, we have an IPv6 packet with a local = source=0A> > =3D=3D> address entering the site from the outside. IPv6 ingre= ss=0A> > =3D=3D> filtering at the site border router should prevent the=0A>= > =3D=3D> packet from entering the site in the first place. If the=0A> > = =3D=3D> 6to4 relay router is outside the site then ip-proto-41=0A> > =3D=3D= > filtering at the border router will block the attack in=0A> > =3D=3D> the= first place anyway. If the relay router is *inside*=0A> > =3D=3D> the site= , then the IPv6 ingress filtering is the lone=0A> > =3D=3D> mitigation. The= end result is that the 6to4 relay should=0A> > =3D=3D> really be positione= d outside of the site's border routers;=0A> > =3D=3D> otherwise, it could b= e spoofed into thinking that the=0A> > =3D=3D> ISATAP router is a 6to4 rout= er and not an ISATAP router.=0A> > =3D=3D>=0A> > =3D=3D> In attack #2, we h= ave an IPv6 packet with a foreign source=0A> > =3D=3D> address being forwar= ded by the ISATAP router to a 6to4=0A> > =3D=3D> relay, but I mis-spoke whe= n I said that this would be a=0A> > =3D=3D> case of the ISATAP router forwa= rding a packet with a foreign=0A> > =3D=3D> source address out of the ISATA= P link. For all the ISATAP=0A> > =3D=3D> router knows, the 6to4 relay is ju= st an ordinary host on=0A> > =3D=3D> the ISATAP link, so the ISATAP router = actually believes it=0A> > =3D=3D> is forwarding the packet *into* the ISAT= AP link (not out of=0A> > =3D=3D> it). But as in attack #1, the attack is b= locked by ip-proto-41=0A> > =3D=3D> filtering at the border router between = the ISATAP router and=0A> > =3D=3D> the 6to4 relay. If there is no border r= outer between the ISATAP=0A> > =3D=3D> router and the 6to4 relay, then we h= ave an identical instance=0A> > =3D=3D> to attack #3 which I will discuss b= elow. But, the best=0A> > =3D=3D> operational practice would again be to ha= ve the 6to4 relay=0A> > =3D=3D> oriented outside of a border router that fi= lters ip-proto-41.=0A> > =3D=3D>=0A> > =3D=3D> Short summary is that in att= ack #1, the 6to4 relay thinks it=0A> > =3D=3D> is talking to a 6to4 router = and not an ISATAP router. In=0A> > =3D=3D> attack #2, the ISATAP router thi= nks it is talking to a=0A> > =3D=3D> simple host on the link and not a 6to4= relay. In both cases,=0A> > =3D=3D> the attacks are mitigated when there i= s an ip-proto-41=0A> > =3D=3D> filtering border router between the ISATAP r= outer and the=0A> > =3D=3D> 6to4 relay. Oftentimes, the "border router" wil= l be a two-=0A> > =3D=3D> interface router that implements 6to4 on a site-e= xternal=0A> > =3D=3D> IPv4 interface and implements ISATAP on a site-intern= al=0A> > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on packe= ts=0A> > =3D=3D> from outside the site with an IPv4 destination correspondi= ng=0A> > =3D=3D> to the ISATAP interface. I will discuss attack #3 below:= =0A> > =0A> > This attack is mitigated by=0A> > IPv6 ingress filtering whic= h is an IPv6 security consideration=0A> > and not an ISATAP nor IPv4 securi= ty consideration. BCP=0A> > recommendations for network ingress filtering a= re documented=0A> > in RFC2827 and it is expected that IPv6 routers that co= nfigure=0A> > ISATAP interfaces will implement IPv6 ingress filtering=0A> >= according to the BCP.=0A> > =0A> > So If my last comment is correct than I= do not see how ingress filtering would =0A> help here. The only=0A> > case= where=A0ingress filtering can help is in case of attack #3 when the router= s =0A> reside at the same=0A> > site. In that case if the attack packet (pa= cket 0) is sent from outside the =0A> site then ingress=0A> > filtering on = the border of the site will drop the packet.=0A> > =0A> > =0A> > =3D=3D> Co= rrect about the IPv6 ingress filtering at the border,=0A> > =3D=3D> but as = with attack #2 my error in the previous message=0A> > =3D=3D> was in thinki= ng the ISATAP router A was forwarding the=0A> > =3D=3D> packet *out* of the= ISATAP link when in fact from the=0A> > =3D=3D> ISATAP router's perspectiv= e it is forwarding the packet=0A> > =3D=3D> to a simple host *inside* of th= e link.=0A> > =3D=3D>=0A> > =3D=3D> The problem here is that the ISATAP rou= ter is blindly=0A> > =3D=3D> forwarding a packet to a node that it assumes = is a simple=0A> > =3D=3D> host on the ISATAP link without first verifying t= hat the=0A> > =3D=3D> node has demonstrated a willingness to participate as= a=0A> > =3D=3D> host on the link. As you have pointed out, this can lead= =0A> > =3D=3D> to strange scenarios when the anonymous node is a tunnel=0A>= > =3D=3D> router of some sort that does not participate in the=0A> > =3D= =3D> ISATAP link.=0A> > =3D=3D>=0A> > =3D=3D> It would not generally be pos= sible for the ISATAP router=0A> > =3D=3D> to check whether the IPv6 destina= tion address is an ISATAP=0A> > =3D=3D> address that embeds one of its own = IPv4 addresses, because=0A> > =3D=3D> when IPv4 private addresses are used = the same IPv4 address=0A> > =3D=3D> can (and often does) occur in multiple = sites. So for example,=0A> > =3D=3D> if the ISATAP router configures an IPv= 4 address 10.0.0.1=0A> > =3D=3D> and is asked to forward an IPv6 packet wit= h ISATAP=0A> > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where = the=0A> > =3D=3D> IPv6 prefix is foreign, the router can't very well drop t= he=0A> > =3D=3D> packet as this would block legitimate communications. It= =0A> > =3D=3D> is also not generally possible to check whether a foreign=0A= > > =3D=3D> link is an ISATAP link by looking for the magic token=0A> > =3D= =3D> "0:5EFE" as that token only has significance for ISATAP=0A> > =3D=3D> = links and not other link types.=0A> > =3D=3D>=0A> > =3D=3D> Instead, the mi= tigation I think makes the most sense is=0A> > =3D=3D> for the ISATAP route= r to first verify that the node which=0A> > =3D=3D> it assumes to be a simp= le ISATAP host has demonstrated a=0A> > =3D=3D> willingness to participate = in the link. That can be done=0A> > =3D=3D> by having the ISATAP router fir= st check the neighbor cache=0A> > =3D=3D> when it has a packet to send to v= erify that there is a=0A> > =3D=3D> cached entry corresponding to the desti= nation. For nodes=0A> > =3D=3D> that are willing ISATAP hosts on the link, = there would=0A> > =3D=3D> have been a neighbor cache entry created when the= node=0A> > =3D=3D> sends a Router Solicitation to the ISATAP router for th= e=0A> > =3D=3D> purpose of discovering default router lifetimes and on-=0A>= > =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP=0A> = > =3D=3D> router to forward the packet only if there is a pre-existing=0A> = > =3D=3D> neighbor cache entry and drop the packet otherwise. This=0A> > = =3D=3D> implies that the router should keep neighbor cache entires=0A> > = =3D=3D> for the duration of the minimum lifetime of the prefixes=0A> > =3D= =3D> it advertises in its Router Advertisements.=0A> > =0A> > > In general,= I would like to point out that indeed as in=0A> > > most other attacks the= se attacks may also be mitigated by=0A> > > proper firewall rules. However,= I do not believe that this=0A> > > should be our only answer against these= attacks. I believe=0A> > > that since these attacks are made possible due = to the=0A> > > inherent characteristics of the tunnels they=A0should be=0A>= > > stopped intrinsically as much as possible by the tunnel=0A> > > partic= ipants and not relay on outside filtering rules.=0A> > =0A> > In RFC5214, S= ection 10 we have: "restricting access to the=0A> > link can be achieved by= restricting access to the site". The=0A> > mitigations do exactly that, an= d in such a way that ISATAP=0A> > nodes can operate with only the necessary= and sufficient=0A> > checks. So on this point, I do not share your opinion= .=0A> > =0A> > What about two ISATAP tunnels that reside on the same site l= ike in attack #3. =0A> Do you=A0also think that=0A> > proto-41 filtering sh= ould barrier between the two tunnels within the site?=0A> > =0A> > =0A> > = =3D=3D> I think this may be overcome by the discussion above.=0A> > =3D=3D>= Short story is that operational practices must be=0A> > =3D=3D> employed w= hereby an ISATAP router is not mistaken for=0A> > =3D=3D> a 6to4 router. Th= is is through proper arrangement of=0A> > =3D=3D> 6to4 router/relay interfa= ces outside of the site border=0A> > =3D=3D> rather than inside, and ISATAP= router interfaces inside=0A> > =3D=3D> of the site border rather than outs= ide. Also proper=0A> > =3D=3D> ip-proto-41 filtering and IPv6 ingress filte= ring at=0A> > =3D=3D> site borders.=0A> > =3D=3D>=0A> > =3D=3D> Also, when = there are multiple ISATAP links within the=0A> > =3D=3D> same local IPv4 ro= uting region, an ISATAP router should=0A> > =3D=3D> first verify a node's w= illingness to act as a host on=0A> > =3D=3D> the ISATAP link before blindly= sending a packet to it.=0A> > =3D=3D>=0A> > =3D=3D> Fred=0A> > =3D=3D> fre= d.l.templin@boeing.com=0A> > =0A> > Fred=0A> > fred.l.templin@boeing.com=0A= > > =0A> > ________________________________________=0A> > From: "Templin, F= red L" =0A> > To: Gabi Nakibly ; v6ops =0A> > Cc: ipv6@ietf.org; secdir@iet= f.org=0A> > Sent: Monday, August 17, 2009 8:35:08 PM=0A> > Subject: RE: Rou= ting loop attacks using IPv6 tunnels=0A> > =0A> > =0A> > Gabi,=0A> > =0A> >= Thanks for publishing this work. In the document, attacks A, B and C=0A> >= correspond to a configuration that violates section 6.2 of RFC5214:=0A> > = =0A> > > 6.2.=A0 ISATAP Interface Address Configuration=0A> > >=0A> > > =A0= =A0Each ISATAP interface configures a set of locators consisting of IPv4=0A= > > >=A0=A0 address-to-interface mappings from a single site; i.e., an ISAT= AP=0A> > >=A0=A0 interface's locator set MUST NOT span multiple sites.=0A> = > =0A> > In particular, in scenarios A, B and C the IPv4 locator used for I= SATAP=0A> > is seen both within the enterprise as site #1 and within the gl= obal Internet=0A> > itself as site #2. If the ISATAP interface is to be use= d as an enterprise-=0A> > interior interface, it should therefore not accep= t IP-proto-41 packets=0A> > coming from an IPv4 source outside of the enter= prise nor source=0A> > IP-proto-41 packets that are destined to an IPv4 nod= e outside of the=0A> > enterprise. This condition should be satisfied by ha= ving the site border=0A> > routers implement IPv4 ingress filtering and ip-= protocol-41 filtering as=0A> > required in Section 10 of RFC5214.=0A> > =0A= > > It is mentioned that attack C could also occur when the routers reside= =0A> > in the same site, where their addresses may be private. This would= =0A> > correspond to a case in which an attacker within the site attacks th= e=0A> > site itself, which can easily be traced - especially when source ad= dress=0A> > spoofing from a node within the site is prevented through prope= r ingress=0A> > filtering.=0A> > =0A> > Fred=0A> > fred.l.templin@boeing.co= m=0A> > =0A> > ________________________________________=0A> > From: Gabi Na= kibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Monday, August 17, 2009 8:21 = AM=0A> > To: v6ops=0A> > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > Subject: = Routing loop attacks using IPv6 tunnels=0A> > =0A> > Hi all,=0A> > I would = like to draw the attention of the list to=A0some=A0research=A0results which= =0A> my colleague and I at=0A> > the National EW Research=A0& Simulation= =A0Center have recently published. The =0A> research presents a=A0class=0A>= > of routing loop attacks that abuses 6to4, ISATAP and Teredo. The=A0paper= can be =0A> found at:=0A> > http://www.usenix.org/events/woot09/tech/full_= papers/nakibly.pdf=0A> > =0A> > Here is the abstract:=0A> > IPv6 is the fut= ure network layer protocol for the Internet. Since it is not =0A> compatibl= e with its=0A> > predecessor, some interoperability mechanisms were designe= d. An important =0A> category of these=0A> > mechanisms is automatic tunnel= s, which enable IPv6 communication over an IPv4 =0A> network without prior= =0A> > configuration. This category includes ISATAP, 6to4 and Teredo. We pr= esent a =0A> novel class of attacks=0A> > that exploit vulnerabilities in t= hese tunnels. These attacks take advantage of =0A> inconsistencies=0A> > be= tween a tunnel's overlay IPv6 routing state and the native IPv6 routing =0A= > state. The attacks form=0A> > routing loops which can be abused as a vehi= cle for traffic amplification to =0A> facilitate DoS attacks.=0A> > We exhi= bit five attacks of this class. One of the presented attacks can DoS a =0A>= Teredo server using a=0A> > single packet. The exploited vulnerabilities a= re embedded in the design of the =0A> tunnels; hence any=0A> > implementati= on of these tunnels may be vulnerable. In particular, the attacks =0A> were= tested=0A> > against the ISATAP, 6to4 and Teredo implementations of Window= s Vista and =0A> Windows Server 2008 R2.=0A> > =0A> > I think the results o= f the research warrant some corrective action. If =0A> this=A0indeed shall = be the=0A> > general sentiment of the list, I will be happy write an approp= riate I-D. The =0A> mitigation measures we=0A> > suggested in the paper are= the best we could think of to completely eliminate =0A> the problem. Howev= er=0A> > they are far from perfect since=A0they would require=A0tunnel impl= ementations to =0A> be updated in case new=0A> > types of automatic tunnels= are introduced.=0A> > =0A> > Your comments are welcome.=0A> > =0A> > Gabi= =0A> > =0A> > =0A> > =0A=0A=0A From alexey.melnikov@isode.com Fri Aug 28 12:06:17 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F4C3A71A9 for ; Fri, 28 Aug 2009 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URKMf2d-OVcE for ; Fri, 28 Aug 2009 12:06:16 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CB2F53A71BC for ; Fri, 28 Aug 2009 12:04:48 -0700 (PDT) Received: from [92.40.233.26] (92.40.233.26.sub.mbb.three.co.uk [92.40.233.26]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 28 Aug 2009 20:04:54 +0100 Message-ID: <4A982A48.2020205@isode.com> Date: Fri, 28 Aug 2009 20:04:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en References: <4A98271A.2020601@isode.com> In-Reply-To: <4A98271A.2020601@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Xiaodong Lee , secdir@ietf.org, Paul Hoffman , Harald Alvestrand , Pete Resnick , Chris Newman Subject: Re: [secdir] SecDir review of draft-ietf-eai-imap-utf8-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:06:17 -0000 Alexey Melnikov wrote: >> Further, the I-D Nits checker finds two hard errors: a line the is >> obviously too long, and an obsolete normative reference. > Actually, I think the latter was intentional, but I need to double check. From gnakibly@yahoo.com Fri Aug 28 12:07:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0333A7181 for ; Fri, 28 Aug 2009 12:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHYf+7S+j44y for ; Fri, 28 Aug 2009 12:07:42 -0700 (PDT) Received: from web45502.mail.sp1.yahoo.com (web45502.mail.sp1.yahoo.com [68.180.197.62]) by core3.amsl.com (Postfix) with SMTP id 05CFA28C4D9 for ; Fri, 28 Aug 2009 12:06:59 -0700 (PDT) Received: (qmail 99142 invoked by uid 60001); 28 Aug 2009 19:07:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251486423; bh=u9sTV+ETcDmLh9HMJ0AxLWBOytdZazWudvXsvE1vMDA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UMyWe38nLkLyql3gAKR6UXbSZjAwlLDHbMI7hwgY9qfVM4tbjcXcl1CAh3OwcGVIosd8eGG4IUaNis1At+h0HhhHTD8WwK/AbPeC7QdqfpYE4SP+IiEKHf+zH5VTfZzARkFyiofQbwZdzb44qD0l0EY0X1TxlKMjuLAHGXi1PQI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pPlx7cL2MRce1y2zN2UZIkbdnTGxw/vd4In+hSEKzoVgANfmN5Tb1PFezkjjL3FbeytRDV20BeWUaJ3B1UcpjejYDKs5gY+UUbYsAyWZVsHgJO6LrWaIHerR1ZroEtxDXlGuVoEkLKfXpilfHvD/8sAPbJaYSRhQ017qWuOo9Is=; Message-ID: <212591.98462.qm@web45502.mail.sp1.yahoo.com> X-YMail-OSG: iGaZMakVM1mFX9CKJHXfcLiq7rG9hdY0Y7gK4pPx.r41WoxfvWLEkxQcDn42bT6GcfqU_g5xZQUFluLaFnxoRF9lmoI_mlOTT9doHOeG2w04Rb94PbQv05qCrT8gFHuCerMyCwbAor7rkumyLA3pNSSS4iBxJZ59JVaAhmb9ivvMyR.qXhRcemhkU_usZsBn0Olyb_gHXos1olcD2r3G5ib6VvNmb7yDM6jFLdtph19sIkJyH0OnhU79fUCYcaR4Axh8VNBP Received: from [89.138.8.21] by web45502.mail.sp1.yahoo.com via HTTP; Fri, 28 Aug 2009 12:07:03 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> Date: Fri, 28 Aug 2009 12:07:03 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:07:42 -0000 Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same encapsulation type. ----- Original Message ---- > From: "Templin, Fred L" > To: Gabi Nakibly ; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Sent: Friday, August 28, 2009 7:23:03 PM > Subject: RE: Routing loop attacks using IPv6 tunnels > > Gabi, > > Correct me if I am wrong, but if there were a new version > of ISATAP that did not use ip-proto-41 encapsulation but > instead used a different kind of encapsulation, then it > need not concern itself with routing loop interactions > with 6to4 relays since 6to4 relays only know about > ip-proto-41. Does that match your understanding? > > Thanks - Fred > fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Fri Aug 28 13:23:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CEB3A6A75; Fri, 28 Aug 2009 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.634 X-Spam-Level: X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29tGvlBFRJwx; Fri, 28 Aug 2009 13:23:40 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 207E13A6A5E; Fri, 28 Aug 2009 13:23:39 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SKNicT027530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:23:44 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7SKNiE0006208; Fri, 28 Aug 2009 13:23:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7SKNhkh006170; Fri, 28 Aug 2009 13:23:43 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:23:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 13:23:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <31484.26522.qm@web45503.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooEhDsb5iTYmmfSmCH2zbFJmnM8QACX3Vw References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 28 Aug 2009 20:23:43.0525 (UTC) FILETIME=[70364D50:01CA281D] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:23:42 -0000 Gabi, Thanks for your continued correspondence, and see below: > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:02 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Fred, > A quick summary of our discussion up until now: the best mitigation = of=A0most of these=A0attacks is > indeed the proto-41 and ingress filtering on the border of the ISATAP = site. If it is indeed > implemented. I=A0assume that not all sites deploy such filtering for = lack of awareness or since the > proto-41 filtering may break other tunnels the site may employ. = However, I do not have hard evidence > on this. I would be happy if others on the list will refute or justify = this assumption. >=20 > If this assumption is (even partially) correct than I think that the = ISATAP router should defend > itself. If there is operational assurance of filtering, then I think there is no problem. For the other cases, I am beginning to come around to your opinion. > Moreover, as I mention below the proo-41 filtering is not effective in = case of attack > #3=A0and=A0the attacker is internal to the site. I'll speak more on this below. > So IMHO the best way is the mitigations I suggested and > that you illustrated below in pseudo-code. OK. > See=A0further comments inline. >=20 > Gabi >=20 > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Monday, August 24, 2009 10:04:34 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > > -----Original Message----- > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 24, 2009 4:44 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > I=A0initially very much=A0liked your suggestion regarding the = check=A0of the > > neighbor cache before > > > forwarding a packet into the tunnel.=A0It truly addresses the root = cause of the > > problem ans is simple > > > enough to implement. However, I realized that an attacker can send = a > > spoofed=A0RS to the ISATAP router > > > as if it came from the 6to4 relay. The router would then send=A0a = RA=A0to it=A0and > > consequently change its > > > neighbor cache. So it seems=A0that this defense does not add = much.=A0Wouldn't you > > agree? > > > > I agree that my proposed mitigation is only useful when there > > is assurance of a coherent neighbor cache in the ISATAP router. > > That would be true in the case in which the ISATAP router is > > located within a site protected by border routers that perform > > ip-proto-41 and ingress filtering, and in which there is no > > untraceable IPv4 source address spoofing. So AFAICT, my proposed > > mitigation is still necessary for preventing attack #3 when > > ISATAP routers A and B are on separate ISATAP links within > > the same site-internal IPv4 routing region. > > >=20 > This is only true when the attacker is outside the site and proto-41 = filtering is employed. If the > attacker is internal to the site then the proto-41 filtering will not = help and the neighbor cache can > be poisoned. Since the ISATAP checks require that the IPv6 source embed the IPv4 source and/or the IPv4 source is a PRL router, you must be speaking here about IPv4 source address spoofing from within the site. For sites that allow intra-site source address spoofing, I think much more serious problems could manifest themselves that would be completely unrelated to ISATAP. I believe you will also find other automatic tunneling protocols besides ISATAP that operate under an assumption of no intra-site IPv4 source address spoofing.=20 > > > I completely agree with your observation on the non-feasibility of > > verifying=A0that the > > > destination=A0ISATAP address does not include=A0a local=A0IPv4 = address=A0since the > > ISATAP address may include > > > a private IPv4 address. On the other hand, a check on public IPv4 = addresses is > > acceptable.=A0If the > > > check would be done only on ISATAP addresses that include public = IPv4 > > addresses then this will > > > eliminate the attacks in which the two victims reside=A0at = different sites. Note > > that if attack #3=A0is > > > launched on two ISATAP routers=A0having private addresses at two = different sites > > then the attack will > > > not work anyway since one router can not send a direct=A0IPv4 = packet to the > > other. In addition, > > > to=A0mitigate attacks in which the other victim is a 6to4 relay = (such as attack > > #1) then a check would > > > have to be done on a 6to4 address, i.e. the destination address = must not be > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must = be public, > > according to > > >=A0 the 6to4 spec. > > > > > > As you also noted there is another problem with this check since = the string > > "200::5EFE" is not unique > > > to ISATAP links. On the other hand, it seems that the probability = to encounter > > a non-malicious packet > > > with a destination address having an IID that equals "200:5EFE:> = IPv4 address>" is > > > pretty slim. > > > > > > This check is definitely not a=A0perfect solution, and I sure hope = that someone > > will come up with a > > > better one for mitigating the routing loops. However, I would be = happy if > > there is some kind of other > > > mitigation=A0measures besides packet filtering=A0(proto-41 and = ingress) by=A0other > > nodes (which=A0does not > > > necessarily exist). > > > > You seem to be envisioning a scenario of ISATAP router operation > > with public IPv4 addresses and outside of any site border routers > > that perform ingress filtering and ip-proto-41 filtering. That has > > traditionally been seen as the domain of 6to4, but I am happy to > > discuss the possibility of what I called the "inside-out ISATAP > > model" in a list message long ago (which AFAICT is the scenario > > you are alluding to). > > >=20 > Well,=A0I am referring to any=A0ISATAP deployment=A0with public IPv4 = addresses and no proto-41 filtering. I > imagine that in practice there are such deployments which are not the = "inside-out ISATAP model"=A0. > However, I must admit that I do not rely here on hard evidence. >=20 > > So, if the public IPv4 Internet were considered as one gigantic > > "site" and we wanted to do ISATAP on that site, it would be nice > > to divide the site into multiple logical partitions, with each > > partition identified by a PRL name and a unique set of IPv6 > > prefixes. But then, we have the scenario you are describing in > > which we can't trust the integrity of the ISATAP router's > > neighbor cache due to the possibility for untraceable IPv4 > > source address spoofing such that the neighbor cache check > > mitigation can be subverted. > > > > This means that if we want to support the inside-out ISATAP > > model then the routing loops could be mitigated either by > > 1) implementing the destination address checks you are > > suggesting, or 2) by not allowing ISATAP router interfaces > > that are not behind filtering border routers to advertise > > non-link-local on-link IPv6 prefixes and/or forward packets > > from non-link-local prefixes in the first place. > > > > If we took the easy way out and did 2), then the entire > > IPv4 Internet would look like one gigantic ISATAP link that > > only did IPv6 link-local. So, nodes could ping6 each others' > > ISATAP link-local addresses but that's about it. > > > > If we took the more ambitious route and allowed ISATAP to > > flourish fully within the global IPv4 Internet, then we > > would essentially be deprecating 6to4 - so it isn't > > surprising that your address checks mostly involve 6to4 > > suppression. Assuming this, if I read your attack scenarios > > 1 through 3 correctly then scenarios 1 and 3 are mitigated > > by a receive-side check and scenario 2 is mitigated by a > > send-side check. In particular, the pseudo-code would be: > > > > =A0 isatap_rcv() { > > =A0 =A0 ... > > =A0 =A0 if (dst =3D=3D "2002:::*") > > =A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */ > > > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:") > > =A0=A0=A0 drop_pkt(); /* attack #3 mitigation */ > > =A0 =A0 ... > > =A0 } > > >=20 > Correct (with the correction you sent after this email). OK. =20 > > =A0 isatap_xmt() { > > =A0 =A0 ... > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:192.88.99.1") > > =A0 =A0 =A0 drop_pkt(); /* attack #2 mitigation */ > > =A0 =A0 ... > > =A0 } >=20 > This will not necessarily work, since the 6to4 relay may have = a=A0unicast address the ISATAP router may > not be aware of. The best way to mitigate attack #2 is=A0by the 6to4 = relay with a check similar to that > of attack #2 above. IMO, the second best way, as Remi suggested on = another thread, is for the ISATAP > router to drop the packet if (src=A0 =3D=3D 2002:::*"). = However, this check is useful only > when the 6to4 relay validates that the IPv6 source address corresponds = to the IPv4 one (this is > in=A0accordance=A0with the 6to4 spec, however it does not always get = implemented). If this is not true > then the attacker does not have to send the attack packet with such an = address. Keeping with the philosophy of the ISATAP router defending itself, I believe it would be best to take Remi's suggestion and lay any complications at the doorstep of the 6to4 relay if it fails to adhere to the spec. Thanks - Fred fred.l.templin@boeing.com > > Does the above look right to you? And is this everything, > > or are there other scenarios we need to consider? > > >=20 >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > > > > Gabi > > > > > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Wednesday, August 19, 2009 6:16:18 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Hi Gabi, > > > > > > I'm sorry to have to keep turning this into plaintext, > > > but annotation is difficult otherwise. See below for > > > my responses (=3D=3D>): > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Wednesday, August 19, 2009 1:49 AM > > > To: Templin, Fred L; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > Fred, > > > See my comments inline (). > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Tuesday, August 18, 2009 6:48:45 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Tuesday, August 18, 2009 3:29 AM > > > To: Templin, Fred L; v6ops > > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > > > > > Indeed the ISATAP interface of the ISATAP router is meant > > > > to be an enterprise-interior (note that=A0it is still=A0assumed > > > > that the associated IPv4 address is=A0non-private). As=A0we > > > > explicitly note in the paper, the first three attacks=A0will > > > > be mitigated=A0if proper protocol-41 filtering is deployed on > > > > the site's border. However, note that RFC5214 does not mandate > > > > or require this filtering. > > > > > > The RFC5214 Security Considerations makes clear the > > > consequences of not implementing IPv4 ingress filtering > > > and ip-protocol-41 filtering (i.e., a possible spooing > > > attack in which spurious ip-protocol-41 packets are > > > injected into an ISATAP link from outside). RFC5214 > > > Section 6.2 additionally requires that an ISATAP interface's > > > locator set MUST NOT span multiple sites. This means that the > > > ISATAP interface must not decapsulate nor source ip-proto-41 > > > packets within multiple sites, where the enterprise interior > > > is site #1 and the global Internet is site #2. ip-protocol-41 > > > filtering is the way in which the ISATAP interface is > > > restricted to a single site. > > > > > > Now let me see that I understand Section 6.2 correctly. In > > > attack #2, for example, I assume the ISATAP router has two > > > physical interfaces. A site-internal IPv4 interface with an > > > address IPisatap and a site-external IPv6 interface. I also > > > assume that there=A0is another border router which connects the > > > site to the IPv4 Internet.=A0The ISATAP router has an ISATAP > > > interface with a single locator: (IPisatap, site-internal > > > interface).=A0When the ISATAP router gets an IPv6 via its > > > external interface it will encapsulate the packet accordingly > > > and forward it through the internal IPv4 interface. If the > > > encapsulated packet is=A0destined to a node outside the site > > > then the only thing that stops it is=A0a proto-41 filtering > > > at the=A0other border router of the site. Did I get this right? > > > > > > > > > =3D=3D> In this case, yes - the ip-proto-41 filtering is at a > > > =3D=3D> border router. I know of at least one major enterprise > > > =3D=3D> network that does this. > > > > > > > It is only mentioned as a possible mitigation against > > > > incoming spurious protocol-41 packets. In addition, > > > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress > > > > filtering.=A0Hence it=A0will not stop attack #2. > > > > > > We are now talking about ip-proto-41 filtering; not ingress > > > filtering. ip-proto-41 filtering is in both directions. It > > > prevents ip-proto-41 packets from entering the enterprise > > > interior ISATAP site from the Internet and prevents > > > ip-proto-41 packets from entering the Internet ISATAP > > > site from the enterprise interior. Else the ISATAP > > > interface would span multiple sites. > > > > > > Besides, "ingress" filtering is not about packets coming > > > from the Internet into the end site, but rather it is > > > about packets leaving the end site and going out into > > > the Internet. RFC2827 (BCP38) documents ingress filtering. > > > > > > OK. I see what you are saying here. > > > > > > > > > =3D=3D> OK. > > > > > > > In addition, > > > > as mentioned, protocol-41 filtering is not helpful when > > > > attack #3 is launched on two routers that reside in the > > > > same site. Note that=A0it=A0may be=A0possible for=A0the attack > > > > packet=A0to be sourced from outside the site unless proper > > > > filtering of incoming IPv6 packets is deployed. If the > > > > attacker resides in the site, usually ingress filtering > > > > will not be helpful since it is deployed in general on > > > > the site's border. > > > > > > Here, we have the ISATAP router in both cases sourcing a > > > packet from a foreign prefix. > > > > > > Well, I do not see how this is correct. In attacks #1 and #3 the = ISATAP router > > sources (actually > > > forwards) an IPv6=A0packet with=A0a source address having=A0the = corresponding=A0prefix > > of the ISATAP tunnel. > > > In attacks #2 and #3 the ISATAP router sources and IPv4 packet = with its own > > IPv4 address as the > > > source address. > > > > > > > > > =3D=3D> There were a number of errors in what I said in my last > > > =3D=3D> message, so let me see if I can get it right here: > > > =3D=3D> > > > =3D=3D> In attacks #1 and #2 there are two cases to consider. Case > > > =3D=3D> 1 in which a border router separates the 6to4 relay from = the > > > =3D=3D> ISATAP router, and case 2 in which no border router = separates > > > =3D=3D> the 6to4 relay from the ISATAP router. > > > =3D=3D> > > > =3D=3D> In attack #1, we have an IPv6 packet with a local source > > > =3D=3D> address entering the site from the outside. IPv6 ingress > > > =3D=3D> filtering at the site border router should prevent the > > > =3D=3D> packet from entering the site in the first place. If the > > > =3D=3D> 6to4 relay router is outside the site then ip-proto-41 > > > =3D=3D> filtering at the border router will block the attack in > > > =3D=3D> the first place anyway. If the relay router is *inside* > > > =3D=3D> the site, then the IPv6 ingress filtering is the lone > > > =3D=3D> mitigation. The end result is that the 6to4 relay should > > > =3D=3D> really be positioned outside of the site's border routers; > > > =3D=3D> otherwise, it could be spoofed into thinking that the > > > =3D=3D> ISATAP router is a 6to4 router and not an ISATAP router. > > > =3D=3D> > > > =3D=3D> In attack #2, we have an IPv6 packet with a foreign source > > > =3D=3D> address being forwarded by the ISATAP router to a 6to4 > > > =3D=3D> relay, but I mis-spoke when I said that this would be a > > > =3D=3D> case of the ISATAP router forwarding a packet with a = foreign > > > =3D=3D> source address out of the ISATAP link. For all the ISATAP > > > =3D=3D> router knows, the 6to4 relay is just an ordinary host on > > > =3D=3D> the ISATAP link, so the ISATAP router actually believes it > > > =3D=3D> is forwarding the packet *into* the ISATAP link (not out = of > > > =3D=3D> it). But as in attack #1, the attack is blocked by = ip-proto-41 > > > =3D=3D> filtering at the border router between the ISATAP router = and > > > =3D=3D> the 6to4 relay. If there is no border router between the = ISATAP > > > =3D=3D> router and the 6to4 relay, then we have an identical = instance > > > =3D=3D> to attack #3 which I will discuss below. But, the best > > > =3D=3D> operational practice would again be to have the 6to4 relay > > > =3D=3D> oriented outside of a border router that filters = ip-proto-41. > > > =3D=3D> > > > =3D=3D> Short summary is that in attack #1, the 6to4 relay thinks = it > > > =3D=3D> is talking to a 6to4 router and not an ISATAP router. In > > > =3D=3D> attack #2, the ISATAP router thinks it is talking to a > > > =3D=3D> simple host on the link and not a 6to4 relay. In both = cases, > > > =3D=3D> the attacks are mitigated when there is an ip-proto-41 > > > =3D=3D> filtering border router between the ISATAP router and the > > > =3D=3D> 6to4 relay. Oftentimes, the "border router" will be a two- > > > =3D=3D> interface router that implements 6to4 on a site-external > > > =3D=3D> IPv4 interface and implements ISATAP on a site-internal > > > =3D=3D> IPv4 interface and performs ip-proto-41 filtering on = packets > > > =3D=3D> from outside the site with an IPv4 destination = corresponding > > > =3D=3D> to the ISATAP interface. I will discuss attack #3 below: > > > > > > This attack is mitigated by > > > IPv6 ingress filtering which is an IPv6 security consideration > > > and not an ISATAP nor IPv4 security consideration. BCP > > > recommendations for network ingress filtering are documented > > > in RFC2827 and it is expected that IPv6 routers that configure > > > ISATAP interfaces will implement IPv6 ingress filtering > > > according to the BCP. > > > > > > So If my last comment is correct than I do not see how ingress = filtering would > > help here. The only > > > case where=A0ingress filtering can help is in case of attack #3 = when the routers > > reside at the same > > > site. In that case if the attack packet (packet 0) is sent from = outside the > > site then ingress > > > filtering on the border of the site will drop the packet. > > > > > > > > > =3D=3D> Correct about the IPv6 ingress filtering at the border, > > > =3D=3D> but as with attack #2 my error in the previous message > > > =3D=3D> was in thinking the ISATAP router A was forwarding the > > > =3D=3D> packet *out* of the ISATAP link when in fact from the > > > =3D=3D> ISATAP router's perspective it is forwarding the packet > > > =3D=3D> to a simple host *inside* of the link. > > > =3D=3D> > > > =3D=3D> The problem here is that the ISATAP router is blindly > > > =3D=3D> forwarding a packet to a node that it assumes is a simple > > > =3D=3D> host on the ISATAP link without first verifying that the > > > =3D=3D> node has demonstrated a willingness to participate as a > > > =3D=3D> host on the link. As you have pointed out, this can lead > > > =3D=3D> to strange scenarios when the anonymous node is a tunnel > > > =3D=3D> router of some sort that does not participate in the > > > =3D=3D> ISATAP link. > > > =3D=3D> > > > =3D=3D> It would not generally be possible for the ISATAP router > > > =3D=3D> to check whether the IPv6 destination address is an ISATAP > > > =3D=3D> address that embeds one of its own IPv4 addresses, because > > > =3D=3D> when IPv4 private addresses are used the same IPv4 address > > > =3D=3D> can (and often does) occur in multiple sites. So for = example, > > > =3D=3D> if the ISATAP router configures an IPv4 address 10.0.0.1 > > > =3D=3D> and is asked to forward an IPv6 packet with ISATAP > > > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where the > > > =3D=3D> IPv6 prefix is foreign, the router can't very well drop = the > > > =3D=3D> packet as this would block legitimate communications. It > > > =3D=3D> is also not generally possible to check whether a foreign > > > =3D=3D> link is an ISATAP link by looking for the magic token > > > =3D=3D> "0:5EFE" as that token only has significance for ISATAP > > > =3D=3D> links and not other link types. > > > =3D=3D> > > > =3D=3D> Instead, the mitigation I think makes the most sense is > > > =3D=3D> for the ISATAP router to first verify that the node which > > > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a > > > =3D=3D> willingness to participate in the link. That can be done > > > =3D=3D> by having the ISATAP router first check the neighbor cache > > > =3D=3D> when it has a packet to send to verify that there is a > > > =3D=3D> cached entry corresponding to the destination. For nodes > > > =3D=3D> that are willing ISATAP hosts on the link, there would > > > =3D=3D> have been a neighbor cache entry created when the node > > > =3D=3D> sends a Router Solicitation to the ISATAP router for the > > > =3D=3D> purpose of discovering default router lifetimes and on- > > > =3D=3D> link prefixes. So, the simple mitigations is for the = ISATAP > > > =3D=3D> router to forward the packet only if there is a = pre-existing > > > =3D=3D> neighbor cache entry and drop the packet otherwise. This > > > =3D=3D> implies that the router should keep neighbor cache entires > > > =3D=3D> for the duration of the minimum lifetime of the prefixes > > > =3D=3D> it advertises in its Router Advertisements. > > > > > > > In general, I would like to point out that indeed as in > > > > most other attacks these attacks may also be mitigated by > > > > proper firewall rules. However, I do not believe that this > > > > should be our only answer against these attacks. I believe > > > > that since these attacks are made possible due to the > > > > inherent characteristics of the tunnels they=A0should be > > > > stopped intrinsically as much as possible by the tunnel > > > > participants and not relay on outside filtering rules. > > > > > > In RFC5214, Section 10 we have: "restricting access to the > > > link can be achieved by restricting access to the site". The > > > mitigations do exactly that, and in such a way that ISATAP > > > nodes can operate with only the necessary and sufficient > > > checks. So on this point, I do not share your opinion. > > > > > > What about two ISATAP tunnels that reside on the same site like in = attack #3. > > Do you=A0also think that > > > proto-41 filtering should barrier between the two tunnels within = the site? > > > > > > > > > =3D=3D> I think this may be overcome by the discussion above. > > > =3D=3D> Short story is that operational practices must be > > > =3D=3D> employed whereby an ISATAP router is not mistaken for > > > =3D=3D> a 6to4 router. This is through proper arrangement of > > > =3D=3D> 6to4 router/relay interfaces outside of the site border > > > =3D=3D> rather than inside, and ISATAP router interfaces inside > > > =3D=3D> of the site border rather than outside. Also proper > > > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at > > > =3D=3D> site borders. > > > =3D=3D> > > > =3D=3D> Also, when there are multiple ISATAP links within the > > > =3D=3D> same local IPv4 routing region, an ISATAP router should > > > =3D=3D> first verify a node's willingness to act as a host on > > > =3D=3D> the ISATAP link before blindly sending a packet to it. > > > =3D=3D> > > > =3D=3D> Fred > > > =3D=3D> fred.l.templin@boeing.com > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Monday, August 17, 2009 8:35:08 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > > > > Gabi, > > > > > > Thanks for publishing this work. In the document, attacks A, B and = C > > > correspond to a configuration that violates section 6.2 of = RFC5214: > > > > > > > 6.2.=A0 ISATAP Interface Address Configuration > > > > > > > > =A0=A0Each ISATAP interface configures a set of locators = consisting of IPv4 > > > >=A0=A0 address-to-interface mappings from a single site; i.e., an = ISATAP > > > >=A0=A0 interface's locator set MUST NOT span multiple sites. > > > > > > In particular, in scenarios A, B and C the IPv4 locator used for = ISATAP > > > is seen both within the enterprise as site #1 and within the = global Internet > > > itself as site #2. If the ISATAP interface is to be used as an = enterprise- > > > interior interface, it should therefore not accept IP-proto-41 = packets > > > coming from an IPv4 source outside of the enterprise nor source > > > IP-proto-41 packets that are destined to an IPv4 node outside of = the > > > enterprise. This condition should be satisfied by having the site = border > > > routers implement IPv4 ingress filtering and ip-protocol-41 = filtering as > > > required in Section 10 of RFC5214. > > > > > > It is mentioned that attack C could also occur when the routers = reside > > > in the same site, where their addresses may be private. This would > > > correspond to a case in which an attacker within the site attacks = the > > > site itself, which can easily be traced - especially when source = address > > > spoofing from a node within the site is prevented through proper = ingress > > > filtering. > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > ________________________________________ > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > > Sent: Monday, August 17, 2009 8:21 AM > > > To: v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Subject: Routing loop attacks using IPv6 tunnels > > > > > > Hi all, > > > I would like to draw the attention of the list = to=A0some=A0research=A0results which > > my colleague and I at > > > the National EW Research=A0& Simulation=A0Center have recently = published. The > > research presents a=A0class > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo. = The=A0paper can be > > found at: > > > http://www.usenix.org/events/woot09/tech/full_papers/nakibly.pdf > > > > > > Here is the abstract: > > > IPv6 is the future network layer protocol for the Internet. Since = it is not > > compatible with its > > > predecessor, some interoperability mechanisms were designed. An = important > > category of these > > > mechanisms is automatic tunnels, which enable IPv6 communication = over an IPv4 > > network without prior > > > configuration. This category includes ISATAP, 6to4 and Teredo. We = present a > > novel class of attacks > > > that exploit vulnerabilities in these tunnels. These attacks take = advantage of > > inconsistencies > > > between a tunnel's overlay IPv6 routing state and the native IPv6 = routing > > state. The attacks form > > > routing loops which can be abused as a vehicle for traffic = amplification to > > facilitate DoS attacks. > > > We exhibit five attacks of this class. One of the presented = attacks can DoS a > > Teredo server using a > > > single packet. The exploited vulnerabilities are embedded in the = design of the > > tunnels; hence any > > > implementation of these tunnels may be vulnerable. In particular, = the attacks > > were tested > > > against the ISATAP, 6to4 and Teredo implementations of Windows = Vista and > > Windows Server 2008 R2. > > > > > > I think the results of the research warrant some corrective = action. If > > this=A0indeed shall be the > > > general sentiment of the list, I will be happy write an = appropriate I-D. The > > mitigation measures we > > > suggested in the paper are the best we could think of to = completely eliminate > > the problem. However > > > they are far from perfect since=A0they would require=A0tunnel = implementations to > > be updated in case new > > > types of automatic tunnels are introduced. > > > > > > Your comments are welcome. > > > > > > Gabi > > > > > > > > > >=20 >=20 >=20 From Fred.L.Templin@boeing.com Fri Aug 28 13:43:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3C93A6BF1; Fri, 28 Aug 2009 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS0A5VEhNPbq; Fri, 28 Aug 2009 13:43:40 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 0DC0228C2EF; Fri, 28 Aug 2009 13:43:30 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7SKPRiU028364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:25:27 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7SKPQuS008869; Fri, 28 Aug 2009 13:25:27 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7SKPLGl008655; Fri, 28 Aug 2009 13:25:26 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 13:25:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 13:25:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <212591.98462.qm@web45502.mail.sp1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeA References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> <212591.98462.qm@web45502.mail.sp1.yahoo.com> From: "Templin, Fred L" To: "Gabi Nakibly" , "v6ops" X-OriginalArrivalTime: 28 Aug 2009 20:25:26.0120 (UTC) FILETIME=[AD5D0E80:01CA281D] Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:43:41 -0000 Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:07 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels >=20 > Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet > the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same > encapsulation type. OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. Fred fred.l.templin@boeing.com > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, August 28, 2009 7:23:03 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > Correct me if I am wrong, but if there were a new version > > of ISATAP that did not use ip-proto-41 encapsulation but > > instead used a different kind of encapsulation, then it > > need not concern itself with routing loop interactions > > with 6to4 relays since 6to4 relays only know about > > ip-proto-41. Does that match your understanding? > > > > Thanks - Fred > > fred.l.templin@boeing.com >=20 >=20 >=20 >=20 From phoffman@imc.org Fri Aug 28 13:58:07 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9FE28C13D for ; Fri, 28 Aug 2009 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDGaKGpuADai for ; Fri, 28 Aug 2009 13:58:07 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 60AFF28C24E for ; Fri, 28 Aug 2009 13:57:35 -0700 (PDT) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7SKvX6x090272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 13:57:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A98271A.2020601@isode.com> References: <4A98271A.2020601@isode.com> Date: Fri, 28 Aug 2009 13:57:32 -0700 To: Alexey Melnikov From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Pete Resnick , Harald Alvestrand , Chris Newman , Xiaodong Lee , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-eai-imap-utf8-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:58:08 -0000 At 7:51 PM +0100 8/28/09, Alexey Melnikov wrote: >While I agree that these should have been fixed, I personally don't think it is a big deal. Nor do I, that's why I didn't send this to the IESG or the IETF general list. However, Tim and Pasi have asked SecDir reviewers to comment on all aspects of a draft we are reviewing, not just the security aspects. I did not, for example, comment on the grammar issues that I strongly suspect will be fixed by the RFC Editor. However, if I were an IESG member reading the document for the first time, I would immediately ask why the abstract says "do not deploy implementations of this draft" for something that is meant to be an Experimental RFC. From alexey.melnikov@isode.com Fri Aug 28 13:59:14 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45F028C1C5 for ; Fri, 28 Aug 2009 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCatGA-rrq8R for ; Fri, 28 Aug 2009 13:59:14 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EE29428C148 for ; Fri, 28 Aug 2009 13:59:13 -0700 (PDT) Received: from [92.40.87.106] (92.40.87.106.sub.mbb.three.co.uk [92.40.87.106]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 28 Aug 2009 21:59:19 +0100 Message-ID: <4A984512.7010103@isode.com> Date: Fri, 28 Aug 2009 21:58:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: <4A98271A.2020601@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Harald Alvestrand , Chris Newman , Xiaodong Lee , secdir@ietf.org Subject: Re: [secdir] SecDir review of draft-ietf-eai-imap-utf8-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 20:59:14 -0000 Paul Hoffman wrote: >At 7:51 PM +0100 8/28/09, Alexey Melnikov wrote: > > >>While I agree that these should have been fixed, I personally don't think it is a big deal. >> >> >Nor do I, that's why I didn't send this to the IESG or the IETF general list. However, Tim and Pasi have asked SecDir reviewers to comment on all aspects of a draft we are reviewing, not just the security aspects. I did not, for example, comment on the grammar issues that I strongly suspect will be fixed by the RFC Editor. However, if I were an IESG member reading the document for the first time, I would immediately ask why the abstract says "do not deploy implementations of this draft" for something that is meant to be an Experimental RFC. > > Fair enough. From jvasseur@cisco.com Mon Aug 31 00:49:59 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD65E3A6995; Mon, 31 Aug 2009 00:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFiAx0u+6BLZ; Mon, 31 Aug 2009 00:49:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0E4683A6989; Mon, 31 Aug 2009 00:49:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,304,1249257600"; d="scan'208";a="48238984" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2009 07:50:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7V7o5Gl021298; Mon, 31 Aug 2009 09:50:05 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7V7o5T1011813; Mon, 31 Aug 2009 07:50:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 09:50:05 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 09:50:04 +0200 Message-Id: From: JP Vasseur To: "Scott G. Kelly" In-Reply-To: <4A974FA1.6010400@hyperthought.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 31 Aug 2009 09:50:03 +0200 References: <4A974FA1.6010400@hyperthought.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 Aug 2009 07:50:04.0728 (UTC) FILETIME=[A6F2B380:01CA2A0F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16858.005 X-TM-AS-Result: No--11.843600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1243; t=1251705005; x=1252569005; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20review=20of=20draft-ietf-mpls-gmpls-lsp -reroute-04=20 |Sender:=20; bh=4m3jwBZIy5YMbZEwiNmLtSwfWqEGYRSS+fiXyzDLLo8=; b=q7+BJJYXLMhtfUu9WyEwLNqjwSdY1fboVxDqEZu+3jOAM0IS7oKtvvyjYY lp54lZzAMKsujsCCYxUWbMCnHTnQLGGgPtvy2FN2EuJtXbfD0I8yV0rPSRST uSdCOWTsUg; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Dimitri.Papadimitriou@alcatel-lucent.be, secdir@ietf.org, jpv@cisco.com, iesg@ietf.org, mpls-chairs@tools.ietf.org, lberger@labn.net Subject: Re: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 07:49:59 -0000 Thanks Scott. JP. On Aug 28, 2009, at 5:31 AM, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > The abstract does a good job of summarizing: This document describes > how Resource ReserVation Protocol (RSVP) PathErr Messages may be > used to trigger rerouting of Multi-Protocol Label Switching (MPLS) > and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) > Label Switched Paths (LSPs) without first removing LSP state or > resources. > > The security considerations section says the document introduces no > new security considerations as it describes usage of existing > formats and mechanisms, and I agree. It also points the reader to > the security considerations sections of RFC4920 and RFC4736, and > these do seem to do a reasonable job of summarizing. > > I see no issues of concern for the security area ADs with this > document. > > --Scott From Pasi.Eronen@nokia.com Mon Aug 31 03:44:18 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697143A6DE7; Mon, 31 Aug 2009 03:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRbG89SvLWJU; Mon, 31 Aug 2009 03:44:17 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1067B3A6D9E; Mon, 31 Aug 2009 03:44:16 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7VAhpwt021747; Mon, 31 Aug 2009 13:44:13 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 13:44:23 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 13:44:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 13:44:12 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 31 Aug 2009 12:44:12 +0200 From: To: , Date: Mon, 31 Aug 2009 12:44:10 +0200 Thread-Topic: Pasi's AD Notes for July-August 2009 Thread-Index: AcoqJ/k2vYMRlclsT1Sn73PVeMSLng== Message-ID: <808FD6E27AD4884E94820BC333B2DB773C014E5818@NOK-EUMSG-01.mgdnok.nokia.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 X-OriginalArrivalTime: 31 Aug 2009 10:44:12.0889 (UTC) FILETIME=[FA898C90:01CA2A27] Subject: [secdir] Pasi's AD Notes for July-August 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 10:44:18 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Routing ADs appointed Rene Struik as security advisor for ROLL WG. - Preparing a liaison statement reply to ITU-T regarding identity management (draft posted to SAAG recently). - Compiled statistics for security area mailing lists (posted to=20 SecDir list). - Worked with Tim on advice on handling variable-length keys in TCP-AO. - Some tools/datatracker work. - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for IANA to update the registry [since 2009-08-31] - Some discussions re: draft-latze-emu-eap-tpm. WORKING GROUPS DKIM - draft-ietf-dkim-overview: published as RFC 5585. - draft-ietf-dkim-rfc4871-errata: published as RFC 5672. - draft-ietf-dkim-ssp: published as RFC 5617. - Waiting for Stephen and Barry for new charter text (noting that=20 current work items are completed and adding 4871bis) - I still need to review what to do about errata 1385, 1532, and 1596 EMU IPSECME - draft-ietf-ipsecme-ikev2-resumption: waiting for secretariat to send IETF last call announcement [since 2009-08-31]. - A virtual interim meeting is planned for 2009-09-22. - Still working on fixing the IANA registrations of RFC 4543;=20 currently waiting for IANA [since 2009-07-31] - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim=20 is handling this one): waiting for Cullen to review the new version and clear his DISCUSS [since 2009-08-04] - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat):=20 waiting for Tim to start IETF last call or provide=20 additional comments [since 2009-08-20] ISMS - draft-ietf-isms-secshell: published as RFC 5592. - draft-ietf-isms-tmsm: published as RFC 5590. - draft-ietf-isms-transport-security-model: published as RFC 5591. - draft-ietf-isms-radius-usage: published as RFC 5608. - Rechartering approved by IESG. - Appointed Russ Mundy as new co-chair. KEYPROV - Some emails I haven't read yet... PKIX - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for smime-3851bis draft (not a normative reference, but authors preferred it this way), which is waiting for several other drafts (including pkix-3281update and pkix-sha2-dsa-ecdsa). SASL - draft-ietf-sasl-scram: in Publication Requested, waiting for me to read it [since 2009-08-27] - (not WG item) draft-altman-tls-channel-bindings: currently in informal "pseudo-WGLC" on SASL/TLS WG lists -- I've promised to sponsor this as individual submission. - Mailing list moved to ietf.org - thanks, Paul! SYSLOG - draft-ietf-syslog-sign: waiting for authors to submit a revised ID before starting IETF last call [since 2009-08-31] - Recharter text sent to IESG/IAB review, expected to be approved in 2009-09-10 IESG telechat. TLS - draft-ietf-tls-extractor: waiting for Eric to reply to the IETF last call comments that were about the document contents, and revise draft if needed [since 2009-08-13] - draft-ietf-tls-rfc4366-bis: in IETF last call (ends 2009-09-07) - Worked with secretariat to get Certicom's PDF file stored=20 on www.ietf.org. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - Looking into errata #117 (for RFC 4346) OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-cain-post-inch-phishingextns: waiting for authors to submit a revised ID [since 2009-08-27] - draft-freed-sieve-in-xml: waiting for authors to propose changes or submit a revised ID [since 2009-08-13] - draft-housley-tls-authz-extns: waiting for authors to submit a revised ID [since 2009-08-13] - draft-ietf-l3vpn-v6-ext-communities: text agreed, waiting for Ross to enter an RFC editor note [since 2009-08-26] - draft-ietf-ltans-dssc: waiting for authors to submit a=20 revised ID [since 2009-08-10] - draft-ietf-mext-binding-revocation: waiting for authors to submit a revised ID or RFC editor note [since 2009-08-27] - draft-ietf-netconf-partial-lock: waiting for authors to=20 propose text or submit a revised ID [since 2009-08-13] - draft-ietf-ntp-autokey: waiting for Ralph to get more information from WG [since 2009-08-20] - draft-ietf-opsawg-syslog-alarm: text agreed, waiting for authors=20 to submit a revised ID or RFC editor note [since 2009-08-27] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-07-26] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From gnakibly@yahoo.com Mon Aug 31 12:40:33 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F5F3A6ED4 for ; Mon, 31 Aug 2009 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af1kT6-beNx9 for ; Mon, 31 Aug 2009 12:40:31 -0700 (PDT) Received: from web45509.mail.sp1.yahoo.com (web45509.mail.sp1.yahoo.com [68.180.197.125]) by core3.amsl.com (Postfix) with SMTP id 3C12428C45A for ; Mon, 31 Aug 2009 12:40:31 -0700 (PDT) Received: (qmail 98032 invoked by uid 60001); 31 Aug 2009 19:40:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251747641; bh=zhNPsfKDxwgYpOdxPcJ/kFAj/cU9X04ofIKwq2shxAg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bAe4oZIClVliTdACPXT+K2MxhTSoGi6My0PdW/a7MIy/GMfmnBtRcsGHoxFiwrNknAn0uHYu3l5gkVuWOwscvcRs5l+Yq7pEXCOXhV2FYc0ARI4eGomUCzLuCV7lwZFx6jUcg0iyeuQCiL5yXKglKobhh6Np6OKUf24s8qsTLog= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hGctNg/yOxQvJFiHrck/ytD8oFj14u4sAUyW5kgdDdukR+57fRg1Z3qAsoZNf+/B/ba9o4npoBmxyPgI9ywIFLqjZ4vkd78RQcvt3SeAvmtICurGx+EeXmy2VU+6MsOhwvuj1RNgJm/mjswI9OXLQwQixiGpV9uaqk4WFGoKVso=; Message-ID: <373420.97768.qm@web45509.mail.sp1.yahoo.com> X-YMail-OSG: Ps8fNCwVM1kh5gxir1qDsI6hm.rpcqKXMZQGBHuSxCUlb5Y6WnErmKUYDwPJJ4MmdWcTiY.SS5jphrkGpAmrEeChKZvWnGF7k8GNJHEN.gRn7DpUe.AWB2Vbim.C8DcWR9YIwSOKPxsRAms5iMaLSx9L6feyymr2BWCRYjE2arHDzmVVoePpQpLqTkPG1kyIkjh6elUX6xt_A8rvUphmXt2c6ENXgv_cyHoUjV73Zi3GtrQk7IOFQP54RduKE0tsa_mfPl3k Received: from [89.138.8.21] by web45509.mail.sp1.yahoo.com via HTTP; Mon, 31 Aug 2009 12:40:41 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <31484.26522.qm@web45503.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> Date: Mon, 31 Aug 2009 12:40:41 -0700 (PDT) From: Gabi Nakibly To: "Templin, Fred L" , v6ops In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555B38@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, secdir@ietf.org Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 19:40:33 -0000 Fred,=0A=0AI agree that the source address check discussed below should be = made. I would also add a forth check=A0to mitigate attack #3 as a second la= yer of defense in case the opposite ISATAP router does not make the=A0prope= r check on the destination address.=0A=0Aisatap_xmt() {=0A=A0=A0=A0=A0 ...= =0A=A0=A0=A0=A0 if (src =3D=3D "::0200:5efe:= ")=0A=A0=A0=A0=A0=A0=A0 drop_pkt(); /* attack #3 mitigation */=0A=A0=A0=A0= =A0 ...=0A=A0}=0A=0AGabi=0A=0A----- Original Message ----=0A> From: "Templi= n, Fred L" =0A> To: Gabi Nakibly ; v6ops =0A> Cc: ipv6@ietf.org; secdir@ietf.org=0A= > Sent: Friday, August 28, 2009 11:23:40 PM=0A> Subject: RE: Routing loop a= ttacks using IPv6 tunnels=0A> =0A> Gabi,=0A> =0A> Thanks for your continued= correspondence, and see below:=0A> =0A> > -----Original Message-----=0A> >= From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > Sent: Friday, August = 28, 2009 12:02 PM=0A> > To: Templin, Fred L; v6ops=0A> > Cc: ipv6@ietf.org;= secdir@ietf.org=0A> > Subject: Re: Routing loop attacks using IPv6 tunnels= =0A> > =0A> > Fred,=0A> > A quick summary of our discussion up until now: t= he best mitigation of=A0most of =0A> these=A0attacks is=0A> > indeed the pr= oto-41 and ingress filtering on the border of the ISATAP site. If =0A> it i= s indeed=0A> > implemented. I=A0assume that not all sites deploy such filte= ring for lack of =0A> awareness or since the=0A> > proto-41 filtering may b= reak other tunnels the site may employ. However, I do =0A> not have hard ev= idence=0A> > on this. I would be happy if others on the list will refute or= justify this =0A> assumption.=0A> > =0A> > If this assumption is (even par= tially) correct than I think that the ISATAP =0A> router should defend=0A> = > itself.=0A> =0A> If there is operational assurance of filtering, then I t= hink there=0A> is no problem. For the other cases, I am beginning to come a= round=0A> to your opinion.=0A> =0A> > Moreover, as I mention below the proo= -41 filtering is not effective in case of =0A> attack=0A> > #3=A0and=A0the = attacker is internal to the site.=0A> =0A> I'll speak more on this below.= =0A> =0A> > So IMHO the best way is the mitigations I suggested and=0A> > t= hat you illustrated below in pseudo-code.=0A> =0A> OK.=0A> =0A> > See=A0fur= ther comments inline.=0A> > =0A> > Gabi=0A> > =0A> > ----- Original Message= ----=0A> > > From: "Templin, Fred L" =0A> > > To: Gabi Nakibly ; v6ops =0A= > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > Sent: Monday, August 24, 2= 009 10:04:34 PM=0A> > > Subject: RE: Routing loop attacks using IPv6 tunnel= s=0A> > >=0A> > > Gabi,=0A> > >=0A> > > > -----Original Message-----=0A> > = > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]=0A> > > > Sent: Monday, = August 24, 2009 4:44 AM=0A> > > > To: Templin, Fred L; v6ops=0A> > > > Cc: = ipv6@ietf.org; secdir@ietf.org=0A> > > > Subject: Re: Routing loop attacks = using IPv6 tunnels=0A> > > >=0A> > > > Fred,=0A> > > > I=A0initially very m= uch=A0liked your suggestion regarding the check=A0of the=0A> > > neighbor c= ache before=0A> > > > forwarding a packet into the tunnel.=A0It truly addre= sses the root cause of =0A> the=0A> > > problem ans is simple=0A> > > > eno= ugh to implement. However, I realized that an attacker can send a=0A> > > s= poofed=A0RS to the ISATAP router=0A> > > > as if it came from the 6to4 rela= y. The router would then send=A0a RA=A0to =0A> it=A0and=0A> > > consequentl= y change its=0A> > > > neighbor cache. So it seems=A0that this defense does= not add much.=A0Wouldn't =0A> you=0A> > > agree?=0A> > >=0A> > > I agree t= hat my proposed mitigation is only useful when there=0A> > > is assurance o= f a coherent neighbor cache in the ISATAP router.=0A> > > That would be tru= e in the case in which the ISATAP router is=0A> > > located within a site p= rotected by border routers that perform=0A> > > ip-proto-41 and ingress fil= tering, and in which there is no=0A> > > untraceable IPv4 source address sp= oofing. So AFAICT, my proposed=0A> > > mitigation is still necessary for pr= eventing attack #3 when=0A> > > ISATAP routers A and B are on separate ISAT= AP links within=0A> > > the same site-internal IPv4 routing region.=0A> > >= =0A> > =0A> > This is only true when the attacker is outside the site and p= roto-41 filtering =0A> is employed. If the=0A> > attacker is internal to th= e site then the proto-41 filtering will not help and =0A> the neighbor cach= e can=0A> > be poisoned.=0A> =0A> Since the ISATAP checks require that the = IPv6 source embed the=0A> IPv4 source and/or the IPv4 source is a PRL route= r, you must be=0A> speaking here about IPv4 source address spoofing from wi= thin the=0A> site. For sites that allow intra-site source address spoofing,= =0A> I think much more serious problems could manifest themselves=0A> that = would be completely unrelated to ISATAP. I believe you=0A> will also find o= ther automatic tunneling protocols besides=0A> ISATAP that operate under an= assumption of no intra-site IPv4=0A> source address spoofing. =0A> =0A> > = > > I completely agree with your observation on the non-feasibility of=0A> = > > verifying=A0that the=0A> > > > destination=A0ISATAP address does not in= clude=A0a local=A0IPv4 address=A0since the=0A> > > ISATAP address may inclu= de=0A> > > > a private IPv4 address. On the other hand, a check on public I= Pv4 =0A> addresses is=0A> > > acceptable.=A0If the=0A> > > > check would be= done only on ISATAP addresses that include public IPv4=0A> > > addresses t= hen this will=0A> > > > eliminate the attacks in which the two victims resi= de=A0at different sites. =0A> Note=0A> > > that if attack #3=A0is=0A> > > >= launched on two ISATAP routers=A0having private addresses at two different= =0A> sites=0A> > > then the attack will=0A> > > > not work anyway since on= e router can not send a direct=A0IPv4 packet to the=0A> > > other. In addit= ion,=0A> > > > to=A0mitigate attacks in which the other victim is a 6to4 re= lay (such as =0A> attack=0A> > > #1) then a check would=0A> > > > have to b= e done on a 6to4 address, i.e. the destination address must not =0A> be=0A>= > > "2002:> > the ISATAP router>::*". In this case the IPv4 address must b= e =0A> public,=0A> > > according to=0A> > > >=A0 the 6to4 spec.=0A> > > >= =0A> > > > As you also noted there is another problem with this check since= the =0A> string=0A> > > "200::5EFE" is not unique=0A> > > > to ISATAP link= s. On the other hand, it seems that the probability to =0A> encounter=0A> >= > a non-malicious packet=0A> > > > with a destination address having an II= D that equals "200:5EFE:> IPv4 =0A> address>" is=0A> > > > pretty slim.=0A>= > > >=0A> > > > This check is definitely not a=A0perfect solution, and I s= ure hope that =0A> someone=0A> > > will come up with a=0A> > > > better one= for mitigating the routing loops. However, I would be happy if=0A> > > the= re is some kind of other=0A> > > > mitigation=A0measures besides packet fil= tering=A0(proto-41 and ingress) =0A> by=A0other=0A> > > nodes (which=A0does= not=0A> > > > necessarily exist).=0A> > >=0A> > > You seem to be envisioni= ng a scenario of ISATAP router operation=0A> > > with public IPv4 addresses= and outside of any site border routers=0A> > > that perform ingress filter= ing and ip-proto-41 filtering. That has=0A> > > traditionally been seen as = the domain of 6to4, but I am happy to=0A> > > discuss the possibility of wh= at I called the "inside-out ISATAP=0A> > > model" in a list message long ag= o (which AFAICT is the scenario=0A> > > you are alluding to).=0A> > >=0A> >= =0A> > Well,=A0I am referring to any=A0ISATAP deployment=A0with public IPv= 4 addresses and =0A> no proto-41 filtering. I=0A> > imagine that in practic= e there are such deployments which are not the =0A> "inside-out ISATAP mode= l"=A0.=0A> > However, I must admit that I do not rely here on hard evidence= .=0A> > =0A> > > So, if the public IPv4 Internet were considered as one gig= antic=0A> > > "site" and we wanted to do ISATAP on that site, it would be n= ice=0A> > > to divide the site into multiple logical partitions, with each= =0A> > > partition identified by a PRL name and a unique set of IPv6=0A> > = > prefixes. But then, we have the scenario you are describing in=0A> > > wh= ich we can't trust the integrity of the ISATAP router's=0A> > > neighbor ca= che due to the possibility for untraceable IPv4=0A> > > source address spoo= fing such that the neighbor cache check=0A> > > mitigation can be subverted= .=0A> > >=0A> > > This means that if we want to support the inside-out ISAT= AP=0A> > > model then the routing loops could be mitigated either by=0A> > = > 1) implementing the destination address checks you are=0A> > > suggesting= , or 2) by not allowing ISATAP router interfaces=0A> > > that are not behin= d filtering border routers to advertise=0A> > > non-link-local on-link IPv6= prefixes and/or forward packets=0A> > > from non-link-local prefixes in th= e first place.=0A> > >=0A> > > If we took the easy way out and did 2), then= the entire=0A> > > IPv4 Internet would look like one gigantic ISATAP link = that=0A> > > only did IPv6 link-local. So, nodes could ping6 each others'= =0A> > > ISATAP link-local addresses but that's about it.=0A> > >=0A> > > I= f we took the more ambitious route and allowed ISATAP to=0A> > > flourish f= ully within the global IPv4 Internet, then we=0A> > > would essentially be = deprecating 6to4 - so it isn't=0A> > > surprising that your address checks = mostly involve 6to4=0A> > > suppression. Assuming this, if I read your atta= ck scenarios=0A> > > 1 through 3 correctly then scenarios 1 and 3 are mitig= ated=0A> > > by a receive-side check and scenario 2 is mitigated by a=0A> >= > send-side check. In particular, the pseudo-code would be:=0A> > >=0A> > = > =A0 isatap_rcv() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 if (dst =3D=3D "20= 02:::*")=0A> > > =A0 =A0 =A0 drop_pkt(); /* attack #1 mitigation */=0A> > >= =0A> > > =A0 =A0 if (dst =3D=3D "*::0200:5efe:")=0A> > > =A0=A0=A0 drop_pkt= (); /* attack #3 mitigation */=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > >=0A= > > =0A> > Correct (with the correction you sent after this email).=0A> =0A= > OK.=0A> =0A> > > =A0 isatap_xmt() {=0A> > > =A0 =A0 ...=0A> > > =A0 =A0 i= f (dst =3D=3D "*::0200:5efe:192.88.99.1")=0A> > > =A0 =A0 =A0 drop_pkt(); /= * attack #2 mitigation */=0A> > > =A0 =A0 ...=0A> > > =A0 }=0A> > =0A> > Th= is will not necessarily work, since the 6to4 relay may have a=A0unicast =0A= > address the ISATAP router may=0A> > not be aware of. The best way to miti= gate attack #2 is=A0by the 6to4 relay with =0A> a check similar to that=0A>= > of attack #2 above. IMO, the second best way, as Remi suggested on anoth= er =0A> thread, is for the ISATAP=0A> > router to drop the packet if (src= =A0 =3D=3D 2002:::*"). However, this =0A> check is useful only=0A> > when t= he 6to4 relay validates that the IPv6 source address corresponds to the =0A= > IPv4 one (this is=0A> > in=A0accordance=A0with the 6to4 spec, however it = does not always get implemented). =0A> If this is not true=0A> > then the a= ttacker does not have to send the attack packet with such an =0A> address.= =0A> =0A> Keeping with the philosophy of the ISATAP router defending itself= ,=0A> I believe it would be best to take Remi's suggestion and lay any=0A> = complications at the doorstep of the 6to4 relay if it fails to=0A> adhere t= o the spec.=0A> =0A> Thanks - Fred=0A> fred.l.templin@boeing.com=0A> =0A> >= > Does the above look right to you? And is this everything,=0A> > > or are= there other scenarios we need to consider?=0A> > >=0A> > =0A> > =0A> > > T= hanks - Fred=0A> > > fred.l.templin@boeing.com=0A> > >=0A> > > >=0A> > > > = Gabi=0A> > > >=0A> > > > ----- Original Message ----=0A> > > > From: "Templ= in, Fred L"=0A> > > > To: Gabi Nakibly ; v6ops=0A> > > > Cc: ipv6@ietf.org;= secdir@ietf.org=0A> > > > Sent: Wednesday, August 19, 2009 6:16:18 PM=0A> = > > > Subject: RE: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > = > > Hi Gabi,=0A> > > >=0A> > > > I'm sorry to have to keep turning this int= o plaintext,=0A> > > > but annotation is difficult otherwise. See below for= =0A> > > > my responses (=3D=3D>):=0A> > > >=0A> > > > ____________________= ____________________=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.co= m]=0A> > > > Sent: Wednesday, August 19, 2009 1:49 AM=0A> > > > To: Templin= , Fred L; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Subj= ect: Re: Routing loop attacks using IPv6 tunnels=0A> > > >=0A> > > > Fred,= =0A> > > > See my comments inline ().=0A> > > >=0A> > > > _________________= _______________________=0A> > > > From: "Templin, Fred L"=0A> > > > To: Gab= i Nakibly ; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Se= nt: Tuesday, August 18, 2009 6:48:45 PM=0A> > > > Subject: RE: Routing loop= attacks using IPv6 tunnels=0A> > > >=0A> > > > Gabi,=0A> > > >=0A> > > > _= _______________________________________=0A> > > > From: Gabi Nakibly [mailt= o:gnakibly@yahoo.com]=0A> > > > Sent: Tuesday, August 18, 2009 3:29 AM=0A> = > > > To: Templin, Fred L; v6ops=0A> > > > > Cc: ipv6@ietf.org; secdir@ietf= .org=0A> > > > > Subject: Re: Routing loop attacks using IPv6 tunnels=0A> >= > > >=0A> > > > > Indeed the ISATAP interface of the ISATAP router is mean= t=0A> > > > > to be an enterprise-interior (note that=A0it is still=A0assum= ed=0A> > > > > that the associated IPv4 address is=A0non-private). As=A0we= =0A> > > > > explicitly note in the paper, the first three attacks=A0will= =0A> > > > > be mitigated=A0if proper protocol-41 filtering is deployed on= =0A> > > > > the site's border. However, note that RFC5214 does not mandate= =0A> > > > > or require this filtering.=0A> > > >=0A> > > > The RFC5214 Sec= urity Considerations makes clear the=0A> > > > consequences of not implemen= ting IPv4 ingress filtering=0A> > > > and ip-protocol-41 filtering (i.e., a= possible spooing=0A> > > > attack in which spurious ip-protocol-41 packets= are=0A> > > > injected into an ISATAP link from outside). RFC5214=0A> > > = > Section 6.2 additionally requires that an ISATAP interface's=0A> > > > lo= cator set MUST NOT span multiple sites. This means that the=0A> > > > ISATA= P interface must not decapsulate nor source ip-proto-41=0A> > > > packets w= ithin multiple sites, where the enterprise interior=0A> > > > is site #1 an= d the global Internet is site #2. ip-protocol-41=0A> > > > filtering is the= way in which the ISATAP interface is=0A> > > > restricted to a single site= .=0A> > > >=0A> > > > Now let me see that I understand Section 6.2 correctl= y. In=0A> > > > attack #2, for example, I assume the ISATAP router has two= =0A> > > > physical interfaces. A site-internal IPv4 interface with an=0A> = > > > address IPisatap and a site-external IPv6 interface. I also=0A> > > >= assume that there=A0is another border router which connects the=0A> > > > = site to the IPv4 Internet.=A0The ISATAP router has an ISATAP=0A> > > > inte= rface with a single locator: (IPisatap, site-internal=0A> > > > interface).= =A0When the ISATAP router gets an IPv6 via its=0A> > > > external interface= it will encapsulate the packet accordingly=0A> > > > and forward it throug= h the internal IPv4 interface. If the=0A> > > > encapsulated packet is=A0de= stined to a node outside the site=0A> > > > then the only thing that stops = it is=A0a proto-41 filtering=0A> > > > at the=A0other border router of the = site. Did I get this right?=0A> > > >=0A> > > >=0A> > > > =3D=3D> In this c= ase, yes - the ip-proto-41 filtering is at a=0A> > > > =3D=3D> border route= r. I know of at least one major enterprise=0A> > > > =3D=3D> network that d= oes this.=0A> > > >=0A> > > > > It is only mentioned as a possible mitigati= on against=0A> > > > > incoming spurious protocol-41 packets. In addition,= =0A> > > > > Section 10 of RFC5214 only mentions=A0ingress not=A0egress=0A>= > > > > filtering.=A0Hence it=A0will not stop attack #2.=0A> > > >=0A> > >= > We are now talking about ip-proto-41 filtering; not ingress=0A> > > > fi= ltering. ip-proto-41 filtering is in both directions. It=0A> > > > prevents= ip-proto-41 packets from entering the enterprise=0A> > > > interior ISATAP= site from the Internet and prevents=0A> > > > ip-proto-41 packets from ent= ering the Internet ISATAP=0A> > > > site from the enterprise interior. Else= the ISATAP=0A> > > > interface would span multiple sites.=0A> > > >=0A> > = > > Besides, "ingress" filtering is not about packets coming=0A> > > > from= the Internet into the end site, but rather it is=0A> > > > about packets l= eaving the end site and going out into=0A> > > > the Internet. RFC2827 (BCP= 38) documents ingress filtering.=0A> > > >=0A> > > > OK. I see what you are= saying here.=0A> > > >=0A> > > >=0A> > > > =3D=3D> OK.=0A> > > >=0A> > > >= > In addition,=0A> > > > > as mentioned, protocol-41 filtering is not help= ful when=0A> > > > > attack #3 is launched on two routers that reside in th= e=0A> > > > > same site. Note that=A0it=A0may be=A0possible for=A0the attac= k=0A> > > > > packet=A0to be sourced from outside the site unless proper=0A= > > > > > filtering of incoming IPv6 packets is deployed. If the=0A> > > > = > attacker resides in the site, usually ingress filtering=0A> > > > > will = not be helpful since it is deployed in general on=0A> > > > > the site's bo= rder.=0A> > > >=0A> > > > Here, we have the ISATAP router in both cases sou= rcing a=0A> > > > packet from a foreign prefix.=0A> > > >=0A> > > > Well, I= do not see how this is correct. In attacks #1 and #3 the ISATAP =0A> route= r=0A> > > sources (actually=0A> > > > forwards) an IPv6=A0packet with=A0a s= ource address having=A0the =0A> corresponding=A0prefix=0A> > > of the ISATA= P tunnel.=0A> > > > In attacks #2 and #3 the ISATAP router sources and IPv4= packet with its =0A> own=0A> > > IPv4 address as the=0A> > > > source addr= ess.=0A> > > >=0A> > > >=0A> > > > =3D=3D> There were a number of errors in= what I said in my last=0A> > > > =3D=3D> message, so let me see if I can g= et it right here:=0A> > > > =3D=3D>=0A> > > > =3D=3D> In attacks #1 and #2 = there are two cases to consider. Case=0A> > > > =3D=3D> 1 in which a border= router separates the 6to4 relay from the=0A> > > > =3D=3D> ISATAP router, = and case 2 in which no border router separates=0A> > > > =3D=3D> the 6to4 r= elay from the ISATAP router.=0A> > > > =3D=3D>=0A> > > > =3D=3D> In attack = #1, we have an IPv6 packet with a local source=0A> > > > =3D=3D> address en= tering the site from the outside. IPv6 ingress=0A> > > > =3D=3D> filtering = at the site border router should prevent the=0A> > > > =3D=3D> packet from = entering the site in the first place. If the=0A> > > > =3D=3D> 6to4 relay r= outer is outside the site then ip-proto-41=0A> > > > =3D=3D> filtering at t= he border router will block the attack in=0A> > > > =3D=3D> the first place= anyway. If the relay router is *inside*=0A> > > > =3D=3D> the site, then t= he IPv6 ingress filtering is the lone=0A> > > > =3D=3D> mitigation. The end= result is that the 6to4 relay should=0A> > > > =3D=3D> really be positione= d outside of the site's border routers;=0A> > > > =3D=3D> otherwise, it cou= ld be spoofed into thinking that the=0A> > > > =3D=3D> ISATAP router is a 6= to4 router and not an ISATAP router.=0A> > > > =3D=3D>=0A> > > > =3D=3D> In= attack #2, we have an IPv6 packet with a foreign source=0A> > > > =3D=3D> = address being forwarded by the ISATAP router to a 6to4=0A> > > > =3D=3D> re= lay, but I mis-spoke when I said that this would be a=0A> > > > =3D=3D> cas= e of the ISATAP router forwarding a packet with a foreign=0A> > > > =3D=3D>= source address out of the ISATAP link. For all the ISATAP=0A> > > > =3D=3D= > router knows, the 6to4 relay is just an ordinary host on=0A> > > > =3D=3D= > the ISATAP link, so the ISATAP router actually believes it=0A> > > > =3D= =3D> is forwarding the packet *into* the ISATAP link (not out of=0A> > > > = =3D=3D> it). But as in attack #1, the attack is blocked by ip-proto-41=0A> = > > > =3D=3D> filtering at the border router between the ISATAP router and= =0A> > > > =3D=3D> the 6to4 relay. If there is no border router between the= ISATAP=0A> > > > =3D=3D> router and the 6to4 relay, then we have an identi= cal instance=0A> > > > =3D=3D> to attack #3 which I will discuss below. But= , the best=0A> > > > =3D=3D> operational practice would again be to have th= e 6to4 relay=0A> > > > =3D=3D> oriented outside of a border router that fil= ters ip-proto-41.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Short summary is that= in attack #1, the 6to4 relay thinks it=0A> > > > =3D=3D> is talking to a 6= to4 router and not an ISATAP router. In=0A> > > > =3D=3D> attack #2, the IS= ATAP router thinks it is talking to a=0A> > > > =3D=3D> simple host on the = link and not a 6to4 relay. In both cases,=0A> > > > =3D=3D> the attacks are= mitigated when there is an ip-proto-41=0A> > > > =3D=3D> filtering border = router between the ISATAP router and the=0A> > > > =3D=3D> 6to4 relay. Ofte= ntimes, the "border router" will be a two-=0A> > > > =3D=3D> interface rout= er that implements 6to4 on a site-external=0A> > > > =3D=3D> IPv4 interface= and implements ISATAP on a site-internal=0A> > > > =3D=3D> IPv4 interface = and performs ip-proto-41 filtering on packets=0A> > > > =3D=3D> from outsid= e the site with an IPv4 destination corresponding=0A> > > > =3D=3D> to the = ISATAP interface. I will discuss attack #3 below:=0A> > > >=0A> > > > This = attack is mitigated by=0A> > > > IPv6 ingress filtering which is an IPv6 se= curity consideration=0A> > > > and not an ISATAP nor IPv4 security consider= ation. BCP=0A> > > > recommendations for network ingress filtering are docu= mented=0A> > > > in RFC2827 and it is expected that IPv6 routers that confi= gure=0A> > > > ISATAP interfaces will implement IPv6 ingress filtering=0A> = > > > according to the BCP.=0A> > > >=0A> > > > So If my last comment is co= rrect than I do not see how ingress filtering =0A> would=0A> > > help here.= The only=0A> > > > case where=A0ingress filtering can help is in case of a= ttack #3 when the =0A> routers=0A> > > reside at the same=0A> > > > site. I= n that case if the attack packet (packet 0) is sent from outside =0A> the= =0A> > > site then ingress=0A> > > > filtering on the border of the site wi= ll drop the packet.=0A> > > >=0A> > > >=0A> > > > =3D=3D> Correct about the= IPv6 ingress filtering at the border,=0A> > > > =3D=3D> but as with attack= #2 my error in the previous message=0A> > > > =3D=3D> was in thinking the = ISATAP router A was forwarding the=0A> > > > =3D=3D> packet *out* of the IS= ATAP link when in fact from the=0A> > > > =3D=3D> ISATAP router's perspecti= ve it is forwarding the packet=0A> > > > =3D=3D> to a simple host *inside* = of the link.=0A> > > > =3D=3D>=0A> > > > =3D=3D> The problem here is that t= he ISATAP router is blindly=0A> > > > =3D=3D> forwarding a packet to a node= that it assumes is a simple=0A> > > > =3D=3D> host on the ISATAP link with= out first verifying that the=0A> > > > =3D=3D> node has demonstrated a will= ingness to participate as a=0A> > > > =3D=3D> host on the link. As you have= pointed out, this can lead=0A> > > > =3D=3D> to strange scenarios when the= anonymous node is a tunnel=0A> > > > =3D=3D> router of some sort that does= not participate in the=0A> > > > =3D=3D> ISATAP link.=0A> > > > =3D=3D>=0A= > > > > =3D=3D> It would not generally be possible for the ISATAP router=0A= > > > > =3D=3D> to check whether the IPv6 destination address is an ISATAP= =0A> > > > =3D=3D> address that embeds one of its own IPv4 addresses, becau= se=0A> > > > =3D=3D> when IPv4 private addresses are used the same IPv4 add= ress=0A> > > > =3D=3D> can (and often does) occur in multiple sites. So for= example,=0A> > > > =3D=3D> if the ISATAP router configures an IPv4 address= 10.0.0.1=0A> > > > =3D=3D> and is asked to forward an IPv6 packet with ISA= TAP=0A> > > > =3D=3D> destination address 2001:DB8::0:5EFE:10.0.0.1 where t= he=0A> > > > =3D=3D> IPv6 prefix is foreign, the router can't very well dro= p the=0A> > > > =3D=3D> packet as this would block legitimate communication= s. It=0A> > > > =3D=3D> is also not generally possible to check whether a f= oreign=0A> > > > =3D=3D> link is an ISATAP link by looking for the magic to= ken=0A> > > > =3D=3D> "0:5EFE" as that token only has significance for ISAT= AP=0A> > > > =3D=3D> links and not other link types.=0A> > > > =3D=3D>=0A> = > > > =3D=3D> Instead, the mitigation I think makes the most sense is=0A> >= > > =3D=3D> for the ISATAP router to first verify that the node which=0A> = > > > =3D=3D> it assumes to be a simple ISATAP host has demonstrated a=0A> = > > > =3D=3D> willingness to participate in the link. That can be done=0A> = > > > =3D=3D> by having the ISATAP router first check the neighbor cache=0A= > > > > =3D=3D> when it has a packet to send to verify that there is a=0A> = > > > =3D=3D> cached entry corresponding to the destination. For nodes=0A> = > > > =3D=3D> that are willing ISATAP hosts on the link, there would=0A> > = > > =3D=3D> have been a neighbor cache entry created when the node=0A> > > = > =3D=3D> sends a Router Solicitation to the ISATAP router for the=0A> > > = > =3D=3D> purpose of discovering default router lifetimes and on-=0A> > > >= =3D=3D> link prefixes. So, the simple mitigations is for the ISATAP=0A> > = > > =3D=3D> router to forward the packet only if there is a pre-existing=0A= > > > > =3D=3D> neighbor cache entry and drop the packet otherwise. This=0A= > > > > =3D=3D> implies that the router should keep neighbor cache entires= =0A> > > > =3D=3D> for the duration of the minimum lifetime of the prefixes= =0A> > > > =3D=3D> it advertises in its Router Advertisements.=0A> > > >=0A= > > > > > In general, I would like to point out that indeed as in=0A> > > >= > most other attacks these attacks may also be mitigated by=0A> > > > > pr= oper firewall rules. However, I do not believe that this=0A> > > > > should= be our only answer against these attacks. I believe=0A> > > > > that since= these attacks are made possible due to the=0A> > > > > inherent characteri= stics of the tunnels they=A0should be=0A> > > > > stopped intrinsically as = much as possible by the tunnel=0A> > > > > participants and not relay on ou= tside filtering rules.=0A> > > >=0A> > > > In RFC5214, Section 10 we have: = "restricting access to the=0A> > > > link can be achieved by restricting ac= cess to the site". The=0A> > > > mitigations do exactly that, and in such a= way that ISATAP=0A> > > > nodes can operate with only the necessary and su= fficient=0A> > > > checks. So on this point, I do not share your opinion.= =0A> > > >=0A> > > > What about two ISATAP tunnels that reside on the same = site like in attack =0A> #3.=0A> > > Do you=A0also think that=0A> > > > pro= to-41 filtering should barrier between the two tunnels within the site?=0A>= > > >=0A> > > >=0A> > > > =3D=3D> I think this may be overcome by the disc= ussion above.=0A> > > > =3D=3D> Short story is that operational practices m= ust be=0A> > > > =3D=3D> employed whereby an ISATAP router is not mistaken = for=0A> > > > =3D=3D> a 6to4 router. This is through proper arrangement of= =0A> > > > =3D=3D> 6to4 router/relay interfaces outside of the site border= =0A> > > > =3D=3D> rather than inside, and ISATAP router interfaces inside= =0A> > > > =3D=3D> of the site border rather than outside. Also proper=0A> = > > > =3D=3D> ip-proto-41 filtering and IPv6 ingress filtering at=0A> > > >= =3D=3D> site borders.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Also, when there= are multiple ISATAP links within the=0A> > > > =3D=3D> same local IPv4 rou= ting region, an ISATAP router should=0A> > > > =3D=3D> first verify a node'= s willingness to act as a host on=0A> > > > =3D=3D> the ISATAP link before = blindly sending a packet to it.=0A> > > > =3D=3D>=0A> > > > =3D=3D> Fred=0A= > > > > =3D=3D> fred.l.templin@boeing.com=0A> > > >=0A> > > > Fred=0A> > > = > fred.l.templin@boeing.com=0A> > > >=0A> > > > ___________________________= _____________=0A> > > > From: "Templin, Fred L"=0A> > > > To: Gabi Nakibly = ; v6ops=0A> > > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Sent: Monday= , August 17, 2009 8:35:08 PM=0A> > > > Subject: RE: Routing loop attacks us= ing IPv6 tunnels=0A> > > >=0A> > > >=0A> > > > Gabi,=0A> > > >=0A> > > > Th= anks for publishing this work. In the document, attacks A, B and C=0A> > > = > correspond to a configuration that violates section 6.2 of RFC5214:=0A> >= > >=0A> > > > > 6.2.=A0 ISATAP Interface Address Configuration=0A> > > > >= =0A> > > > > =A0=A0Each ISATAP interface configures a set of locators consi= sting of IPv4=0A> > > > >=A0=A0 address-to-interface mappings from a single= site; i.e., an ISATAP=0A> > > > >=A0=A0 interface's locator set MUST NOT s= pan multiple sites.=0A> > > >=0A> > > > In particular, in scenarios A, B an= d C the IPv4 locator used for ISATAP=0A> > > > is seen both within the ente= rprise as site #1 and within the global =0A> Internet=0A> > > > itself as s= ite #2. If the ISATAP interface is to be used as an enterprise-=0A> > > > i= nterior interface, it should therefore not accept IP-proto-41 packets=0A> >= > > coming from an IPv4 source outside of the enterprise nor source=0A> > = > > IP-proto-41 packets that are destined to an IPv4 node outside of the=0A= > > > > enterprise. This condition should be satisfied by having the site b= order=0A> > > > routers implement IPv4 ingress filtering and ip-protocol-41= filtering as=0A> > > > required in Section 10 of RFC5214.=0A> > > >=0A> > = > > It is mentioned that attack C could also occur when the routers reside= =0A> > > > in the same site, where their addresses may be private. This wou= ld=0A> > > > correspond to a case in which an attacker within the site atta= cks the=0A> > > > site itself, which can easily be traced - especially when= source address=0A> > > > spoofing from a node within the site is prevented= through proper ingress=0A> > > > filtering.=0A> > > >=0A> > > > Fred=0A> >= > > fred.l.templin@boeing.com=0A> > > >=0A> > > > ________________________= ________________=0A> > > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com]= =0A> > > > Sent: Monday, August 17, 2009 8:21 AM=0A> > > > To: v6ops=0A> > = > > Cc: ipv6@ietf.org; secdir@ietf.org=0A> > > > Subject: Routing loop atta= cks using IPv6 tunnels=0A> > > >=0A> > > > Hi all,=0A> > > > I would like t= o draw the attention of the list to=A0some=A0research=A0results =0A> which= =0A> > > my colleague and I at=0A> > > > the National EW Research=A0& Simul= ation=A0Center have recently published. The=0A> > > research presents a=A0c= lass=0A> > > > of routing loop attacks that abuses 6to4, ISATAP and Teredo.= The=A0paper can =0A> be=0A> > > found at:=0A> > > > http://www.usenix.org/= events/woot09/tech/full_papers/nakibly.pdf=0A> > > >=0A> > > > Here is the = abstract:=0A> > > > IPv6 is the future network layer protocol for the Inter= net. Since it is =0A> not=0A> > > compatible with its=0A> > > > predecessor= , some interoperability mechanisms were designed. An important=0A> > > cate= gory of these=0A> > > > mechanisms is automatic tunnels, which enable IPv6 = communication over an =0A> IPv4=0A> > > network without prior=0A> > > > con= figuration. This category includes ISATAP, 6to4 and Teredo. We present =0A>= a=0A> > > novel class of attacks=0A> > > > that exploit vulnerabilities in= these tunnels. These attacks take =0A> advantage of=0A> > > inconsistencie= s=0A> > > > between a tunnel's overlay IPv6 routing state and the native IP= v6 routing=0A> > > state. The attacks form=0A> > > > routing loops which ca= n be abused as a vehicle for traffic amplification =0A> to=0A> > > facilita= te DoS attacks.=0A> > > > We exhibit five attacks of this class. One of the= presented attacks can =0A> DoS a=0A> > > Teredo server using a=0A> > > > s= ingle packet. The exploited vulnerabilities are embedded in the design of = =0A> the=0A> > > tunnels; hence any=0A> > > > implementation of these tunne= ls may be vulnerable. In particular, the =0A> attacks=0A> > > were tested= =0A> > > > against the ISATAP, 6to4 and Teredo implementations of Windows V= ista and=0A> > > Windows Server 2008 R2.=0A> > > >=0A> > > > I think the re= sults of the research warrant some corrective action. If=0A> > > this=A0ind= eed shall be the=0A> > > > general sentiment of the list, I will be happy w= rite an appropriate I-D. =0A> The=0A> > > mitigation measures we=0A> > > > = suggested in the paper are the best we could think of to completely =0A> el= iminate=0A> > > the problem. However=0A> > > > they are far from perfect si= nce=A0they would require=A0tunnel implementations =0A> to=0A> > > be update= d in case new=0A> > > > types of automatic tunnels are introduced.=0A> > > = >=0A> > > > Your comments are welcome.=0A> > > >=0A> > > > Gabi=0A> > > >= =0A> > > >=0A> > > >=0A> > =0A> > =0A> > =0A=0A=0A=0A