From yaronf@checkpoint.com Wed Apr 1 13:37:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3603A6DF0 for ; Wed, 1 Apr 2009 13:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 Y4lrWGhPYYVB for ; Wed, 1 Apr 2009 13:36:58 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9AE9E3A6D83 for ; Wed, 1 Apr 2009 13:36:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5950330C005; Wed, 1 Apr 2009 23:37:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9C36B2CC002 for ; Wed, 1 Apr 2009 23:37:52 +0300 (IDT) X-CheckPoint: {49D3CE49-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 n31KbpXw019581 for ; Wed, 1 Apr 2009 23:37:52 +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; Wed, 1 Apr 2009 23:37:51 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:50 +0300 Thread-Topic: The next batch of issues Thread-Index: AcmzA7Q809F7WQpLR6Gm7sqB70CZWQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE727@il-ex01.ad.checkpoint.com> 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_00C9_01C9B31C.DA0337F0" MIME-Version: 1.0 Subject: [IPsec] The next batch of issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:37:00 -0000 ------=_NextPart_000_00C9_01C9B31C.DA0337F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CA_01C9B31C.DA0337F0" ------=_NextPart_001_00CA_01C9B31C.DA0337F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, Fresh after shaking off the jet lag from San Francisco, here's a new batch of IKEv2-bis open issues, all of which we introduced at the face to face meeting. Please review them and respond within a week, until April 10. I have included for each issue the original issue text, as well as the SF discussion - if any. Thanks, Yaron ------=_NextPart_001_00CA_01C9B31C.DA0337F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

Fresh after shaking off the jet lag from San = Francisco, here’s a new batch of IKEv2-bis open issues, all of which we introduced at the = face to face meeting.

 

Please review them and respond within a week, until = April 10.

 

I have included for each issue the original issue = text, as well as the SF discussion – if any.

 

Thanks,

         =    Yaron

------=_NextPart_001_00CA_01C9B31C.DA0337F0-- ------=_NextPart_000_00C9_01C9B31C.DA0337F0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTE5NTQ0NVowIwYJKoZIhvcNAQkEMRYEFF9tljT2mouE br7WeRAW0sZ23OjwMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Lg162YrQnasK6DPTbj9gimqlH3e2/Y/oC0wfiSq/+wcVpypqsYoQN+SQjG72cgrM2m2uh8hyXC+k 3Fr0Eg0fHDPcAo/2HQx6beij6EnfDrhmlMCvC6KFoSurpt0k1JxChScvBT++wsNnqh1qVOJN3O+T Tavf5PHebMazqK2Xe1P4IMvgcsJRWhjK9HsCk5esq0FznaFZmtJ80u2lsy+ysiECjMIgfrD81Fv5 rm03isnyIjdhFwlJnK2cEYJCVdfJX8zkr4iO3KEowbwF1SnTxG7R9/WHZR0SoxYf+leKtuJKPxDC BqzEYUPOqR6jVhB4MRIeaSJismf40Te8LTiGHAAAAAAAAA== ------=_NextPart_000_00C9_01C9B31C.DA0337F0-- From yaronf@checkpoint.com Wed Apr 1 13:37:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F63A6D83 for ; Wed, 1 Apr 2009 13:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 h6pg8zQtYlxm for ; Wed, 1 Apr 2009 13:37:00 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CEFE23A6DE6 for ; Wed, 1 Apr 2009 13:36:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EE8C930C005; Wed, 1 Apr 2009 23:37:59 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 848D030C003 for ; Wed, 1 Apr 2009 23:37:55 +0300 (IDT) X-CheckPoint: {49D3CE4C-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 n31KbsXw019595 for ; Wed, 1 Apr 2009 23:37:55 +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; Wed, 1 Apr 2009 23:37:54 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:53 +0300 Thread-Topic: Issue #2: Where does N(SET_WINDOW_SIZE) go? Thread-Index: AcmzBmGajRhVbiUFQ5eiVy0gZtTBbA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> 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_00E1_01C9B31F.86ECE540" MIME-Version: 1.0 Subject: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:37:01 -0000 ------=_NextPart_000_00E1_01C9B31F.86ECE540 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E2_01C9B31F.86ECE540" ------=_NextPart_001_00E2_01C9B31F.86ECE540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. SF discussion: Paul said, "wherever you wish." ------=_NextPart_001_00E2_01C9B31F.86ECE540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in = any message, but it is not yet shown below.

 

SF discussion: Paul said, “wherever you = wish.”

 

 

------=_NextPart_001_00E2_01C9B31F.86ECE540-- ------=_NextPart_000_00E1_01C9B31F.86ECE540 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMTM1NFowIwYJKoZIhvcNAQkEMRYEFDwfFbg5QkEh J7k36Nhhzy7XGjsuMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA t+NaW45qAzy1sEaKsFv+OwUb6I6sTEB+veHY8rU1J3uxUAW6FCN0TpGG+95fpMdJZ8r4vdh1bcYk ymqIQOz1GiNPG7DnTGvD8+X3Zp+eNLQmHddb/euLnn5C8O6ermQGDR3H8W91IUp5kUQrwY4gVs+u 9qlPxk0DGNR8tCtaaAZDefD3giJDD43XSSQRbA3M1kAsxGxMhrpkTVSiDzZgqScjiXI4TFoWDjAX 3/a/J8Vka4NyRPvgH8eHIx07OiHEgCrgyKGYaOKiIVsdU7NnPdfR9Syv+YjdY0OAwZVdoI7yMXnO ieOP+F2YD6vJ3HI5ZbllpfT8LULO9qF0yxaoggAAAAAAAA== ------=_NextPart_000_00E1_01C9B31F.86ECE540-- From yaronf@checkpoint.com Wed Apr 1 14:09:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544BE3A686E for ; Wed, 1 Apr 2009 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 0D7oi5TXA6Fr for ; Wed, 1 Apr 2009 14:09:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E0B843A684A for ; Wed, 1 Apr 2009 14:09:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CCBD330C002; Wed, 1 Apr 2009 23:38:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A1B6530C007 for ; Wed, 1 Apr 2009 23:37:58 +0300 (IDT) X-CheckPoint: {49D3CE4F-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 n31KbvXw019611 for ; Wed, 1 Apr 2009 23:37:58 +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; Wed, 1 Apr 2009 23:37:57 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:56 +0300 Thread-Topic: Issue #63: Position of arbitrary notify payloads Thread-Index: AcmzB+BNcspmq77JTNKGVS22D2gggA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72E@il-ex01.ad.checkpoint.com> 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_0101_01C9B321.05A1C3F0" MIME-Version: 1.0 Subject: [IPsec] Issue #63: Position of arbitrary notify payloads X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:09:42 -0000 ------=_NextPart_000_0101_01C9B321.05A1C3F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0102_01C9B321.05A1C3F0" ------=_NextPart_001_0102_01C9B321.05A1C3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: Appendix C: please also mention extension notifications [N+], other than in C.6. Paul: Maybe copy it everywhere like we have [V+] Not discussed in SF. ------=_NextPart_001_0102_01C9B321.05A1C3F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

 

Appendix C: please also mention extension = notifications [N+], other than in C.6.

 

Paul:

 

Maybe copy it everywhere like we have = [V+]

 

Not discussed in SF.

------=_NextPart_001_0102_01C9B321.05A1C3F0-- ------=_NextPart_000_0101_01C9B321.05A1C3F0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMjQzNlowIwYJKoZIhvcNAQkEMRYEFOCz28zEhftZ zg7FGOKQJ5D82s2IMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ehkTusQwetOQZ+JwSotCKdIdnd7IownF9HgvqbDoyCnWUKkyo3aCvcyYvtPyaLsY013LdLZbguwt OlruoYn2zDLQedMxSrzb3xVCEPYlMpsi7Vk1Ypvpr3kxqqYdcqRSLfV5juAC3xGEy6iJ30X0meb4 ObsNktCZySCiMaIVPUpKPRogqnM4KoQCGqmJgV6sg940SUazb4UVljLEpMqiHA+L5Ln6VcK5tUgj i7OGAJ5WKFBgZbRUwIicbF2GK0PhyVXE4viM8JBNDw5GxVyYx+dulIRusi93E3MjLgM6vSt51t5g 2/Vvyrs4wWHqXVqHu5LKh9v3zcef2dIsQKf+SQAAAAAAAA== ------=_NextPart_000_0101_01C9B321.05A1C3F0-- From yaronf@checkpoint.com Wed Apr 1 14:43:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE5C3A6DB3 for ; Wed, 1 Apr 2009 14:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 v9iCJsN9vb+9 for ; Wed, 1 Apr 2009 14:43:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 35EE928C16C for ; Wed, 1 Apr 2009 14:43:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2DF7930C006; Wed, 1 Apr 2009 23:38:01 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 057362CC002 for ; Wed, 1 Apr 2009 23:37:57 +0300 (IDT) X-CheckPoint: {49D3CE4E-2-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 n31KbtXx019600 for ; Wed, 1 Apr 2009 23:37:56 +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; Wed, 1 Apr 2009 23:37:55 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:55 +0300 Thread-Topic: Issue #53: Handling of INITIAL_CONTACT Thread-Index: AcmzBy+t7CiGMUnQRo6FRjcRBDmTJA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72C@il-ex01.ad.checkpoint.com> 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_00F1_01C9B320.5501B370" MIME-Version: 1.0 Subject: [IPsec] Issue #53: Handling of INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 21:43:09 -0000 ------=_NextPart_000_00F1_01C9B320.5501B370 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F2_01C9B320.5501B370" ------=_NextPart_001_00F2_01C9B320.5501B370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 2.4: Clarif-7.9 is unclear: [this MUST be sent in the first IKE_AUTH request.] 'however, receiving parties need to deal with it in other requests' - what requests? How? Why should it ever happen? SF discussion: David Black: if you put initial_contact in anything other than an IKE_AUTH something is wrong, do you have the critical bit on it? Tero: comes from IKEv1 Greg Lebowitz: clarify: only pay attention to it if it arrives in IKE_AUTH ------=_NextPart_001_00F2_01C9B320.5501B370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

 

2.4: Clarif-7.9 is unclear: [this MUST be sent in the = first IKE_AUTH request…] 'however, receiving parties need to deal with it in = other requests' - what requests? How? Why should it ever = happen?

 

SF discussion:

 

David Black: if you put initial_contact in anything = other than an IKE_AUTH

         = something is wrong, do you have the critical bit on it?

         = Tero: comes from IKEv1

         = Greg Lebowitz: clarify: only pay attention to it if it arrives in IKE_AUTH

 

------=_NextPart_001_00F2_01C9B320.5501B370-- ------=_NextPart_000_00F1_01C9B320.5501B370 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMTk0MFowIwYJKoZIhvcNAQkEMRYEFMU3/rbc90rN f2z8M2HIX4aRo1LvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA X5FxCgwlJ2p0YniQrMo3m1QdnDrEQDO5WYEHX+KEhjEI+NE3eXEg8r/a5MOJJDHUxKjguO8fCWC2 FzwHzwpLkMJICEPQGTzuhFPZgTQxnCsOUWvf0PWa+1Zi4Cn5Xl4OunPzYplYbUCF5zywNKj9Fuzl wgTLZkgC7sgNA662VDYgaUVUSr3o2NDIPF2FRNONkePswzNcayQ/cM7INSTsSEuEV7p+zVdM5FEK G3qMTDkSQhV5vLrISaCwn3qRCcNOMJCk/zunKbdT6Ec7EW4EZi+L53sX2HDf0WXaU/+zdafUrTBO Iq3+6KtOgVrYBWwC05CiM7nt6jt8rX+VkLwF9AAAAAAAAA== ------=_NextPart_000_00F1_01C9B320.5501B370-- From yaronf@checkpoint.com Wed Apr 1 15:49:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F50D3A6A9A for ; Wed, 1 Apr 2009 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.088, 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 GosVvrey+QrP for ; Wed, 1 Apr 2009 15:49:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8DC993A6A59 for ; Wed, 1 Apr 2009 15:49:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id ADDED30C003; Wed, 1 Apr 2009 23:38:00 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B380F30C006 for ; Wed, 1 Apr 2009 23:37:56 +0300 (IDT) X-CheckPoint: {49D3CE4E-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 n31KbtXw019600 for ; Wed, 1 Apr 2009 23:37:56 +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; Wed, 1 Apr 2009 23:37:55 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:54 +0300 Thread-Topic: Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying Thread-Index: AcmzBrWLnN1nB/1MTCelPsyuQrO1EQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> 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_00E9_01C9B31F.DADFADE0" MIME-Version: 1.0 Subject: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:49:42 -0000 ------=_NextPart_000_00E9_01C9B31F.DADFADE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00EA_01C9B31F.DADFADE0" ------=_NextPart_001_00EA_01C9B31F.DADFADE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: I think we should mention that the traffic selectors for the rekying should have those selectors from the packet (see section 2.9): To allow responder to do intelligent narrowing of the traffic selector the responder should know which packet triggered the rekeying, so it will not narrow the traffic selectors to set which is not usable for the packet triggering the rekeying. This means that even the traffic selectors for the rekeying needs to have those selectors from the packet (see section 2.9). Note, that if the responders policy has changed, it is possible that originally traffic that fit to one SA cannot fit to one SA anymore, which means the responder will narrow the traffic selectors so that not all original traffic fits to SA anymore. In that case the initiator getting packet that only fits the old SA (which is waiting to be deleted) but not new, should create new SA for this traffic too (but it is not rekeying anymore, so no REKEY_SA notify is included in the exchange). Same thing happens when the original SA expires, and one ends gets packet which not fit the current traffic selectors, but instead triggers new SA creation. No SF discussion. ------=_NextPart_001_00EA_01C9B31F.DADFADE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero:

 

I think we should mention that the traffic selectors = for the rekying should have those selectors from the packet (see section = 2.9):

 

    To allow = responder to do intelligent narrowing of the traffic selector the responder should know = which packet triggered the rekeying, so it will not narrow the traffic = selectors to set which is not usable for the packet triggering the rekeying. This = means that even the traffic selectors for the rekeying needs to have those = selectors from the packet (see section 2.9). Note, that if the responders policy has = changed, it is possible that originally traffic that fit to one SA cannot fit to one = SA anymore, which means the responder will narrow the traffic selectors so = that not all original traffic fits to SA anymore. In that case the initiator = getting packet that only fits the old SA (which is waiting to be deleted) but = not new, should create new SA for this traffic too (but it is not rekeying anymore, so = no REKEY_SA notify is included in the exchange). Same thing happens when the = original SA expires, and one ends gets packet which not fit the current traffic = selectors, but instead triggers new SA creation.

 

No SF discussion.

------=_NextPart_001_00EA_01C9B31F.DADFADE0-- ------=_NextPart_000_00E9_01C9B31F.DADFADE0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMTYxNVowIwYJKoZIhvcNAQkEMRYEFJxJRtF6dpT4 D7y57+sI8zXqljfCMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA YSe/amgLETnSPq5yX59lj8hpUaW2nAndWTV/BQYM2IY8iJVYOo299hgtcsYRjsQIzIF+/jdTJzP8 VzrdNhqlG6KO+lq/Ef+WjIENVTtFXgYCoDzFE7FIZCEPk+wt+Pzi3R16FdrAOFLwr7KDNLf3F0E4 i3TCciLbVQ28THuKlIDzRMXV+mRDobumQcQjvxR1WKTX1c+avkNbBamYMoLn7L0gjYGw+SGddo8H EqZ2bISAYn3ot6KDWxSkeA23WvokPI1Gzl5OxGqJcPs9udJ/lug+Q5JYx8SFZsthFegLupels3Sp J2h5ZrGoNxc3gZrZ8mTwKMzQm8vmMWjZQ0GQ6AAAAAAAAA== ------=_NextPart_000_00E9_01C9B31F.DADFADE0-- From yaronf@checkpoint.com Wed Apr 1 16:56:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77823A6BC1 for ; Wed, 1 Apr 2009 16:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 DVVQo+S-GNZg for ; Wed, 1 Apr 2009 16:56:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1D8BE3A69A9 for ; Wed, 1 Apr 2009 16:56:20 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BFB722CC003; Wed, 1 Apr 2009 23:38:01 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5950D30C002 for ; Wed, 1 Apr 2009 23:37:57 +0300 (IDT) X-CheckPoint: {49D3CE4E-4-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 n31KbtY0019600 for ; Wed, 1 Apr 2009 23:37:57 +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; Wed, 1 Apr 2009 23:37:55 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:37:55 +0300 Thread-Topic: Issue #61: Security considerations - admission control Thread-Index: AcmzB5ObLJHx69b+TNCfBIRYV4NkvQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72D@il-ex01.ad.checkpoint.com> 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_00F9_01C9B320.B8ED88F0" MIME-Version: 1.0 Subject: [IPsec] Issue #61: Security considerations - admission control X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:56:21 -0000 ------=_NextPart_000_00F9_01C9B320.B8ED88F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00FA_01C9B320.B8ED88F0" ------=_NextPart_001_00FA_01C9B320.B8ED88F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: Additional proposed text for the Security Considerations: Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those used for other forms of trust, e.g. to identify trusted Web servers. Moreover, although IKE provides a wide leeway in defining the security policy for trusted peers' identity, credentials and the correlation between them, having such security policy defined explicitly is essential to a secure implementation. Not discussed in SF. ------=_NextPart_001_00FA_01C9B320.B8ED88F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

 

 

 

Additional proposed text for the Security = Considerations:

 

Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those = used for other forms of trust, e.g. to identify trusted Web servers. Moreover, = although IKE provides a wide leeway in defining the security policy for trusted = peers' identity, credentials and the correlation between them, having such security = policy defined explicitly is essential to a secure = implementation.

 

Not discussed in SF.

------=_NextPart_001_00FA_01C9B320.B8ED88F0-- ------=_NextPart_000_00F9_01C9B320.B8ED88F0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMjIyN1owIwYJKoZIhvcNAQkEMRYEFPPjA8WpXnW6 vBqKLIY7/MZa4OmfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA fLLKikhgtr9IO+78hq9oSgGcBKTVlqAdK1CKYzFjeeMY0HATi7oMiXa8l28r89aTXHkOj1ZXWXMW z0wsBWSBMghSfvqmkNZIcbSZWWnEThpCj6mLMH0rbLPw7O5JkHSdvFSKwBx2ZPMtr6+y3hOhNWg/ wTtKHA3FI80IOsxStGPdpnKlwznjPUcgt27T8QPY6HLE3umpjBy7uB2wM0U0dwbZiP6AHvp7CuaM 2QPpWPR/ja+q21Whx5fmNSzEGRmbA6j9rO7K40oLkvAVuzslFFDXxP67VZCdPtqo6s+ho+dh1s8J IAqHzms68CiyWwCJv4vQGlP4cKLDGmYzlJcqYwAAAAAAAA== ------=_NextPart_000_00F9_01C9B320.B8ED88F0-- From yaronf@checkpoint.com Wed Apr 1 18:03:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D8A3A68BA for ; Wed, 1 Apr 2009 18:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 GDjvgODqdF7B for ; Wed, 1 Apr 2009 18:03:02 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 124273A6BAA for ; Wed, 1 Apr 2009 18:03:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1078E30C005; Wed, 1 Apr 2009 23:38:03 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0FA7B30C008 for ; Wed, 1 Apr 2009 23:37:59 +0300 (IDT) X-CheckPoint: {49D3CE50-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 n31KbvXx019611 for ; Wed, 1 Apr 2009 23:37:58 +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; Wed, 1 Apr 2009 23:37:57 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 1 Apr 2009 23:36:51 +0300 Thread-Topic: Issue #80: UDP encapsulation needs to be negotiated Thread-Index: AcmzCZZVqI0cFkbXRESnX+3P+rNtLg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72F@il-ex01.ad.checkpoint.com> 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_0110_01C9B322.BBA9B0D0" MIME-Version: 1.0 Subject: [IPsec] Issue #80: UDP encapsulation needs to be negotiated X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:03:03 -0000 ------=_NextPart_000_0110_01C9B322.BBA9B0D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0111_01C9B322.BBA9B0D0" ------=_NextPart_001_0111_01C9B322.BBA9B0D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Herbert: Recently the statement "Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected." was added to the draft. This has the potential to create black holes if deployed in the field, unless all implementations always use UDP encapsulation regardless of NAT. The problem is that if a peer behind a firewall (with no NAT) that only allows inbound packets which are in response to outbound packets performs UDP encapsulation without NAT, and the remote peer responds without UDP encapsulation, then all data packets from the remote peer will be dropped. Looking at this from the point of view of the remote peer, the only practical solution would be to always employ UDP encapsulation, regardless of NAT detection. Now through discussion on the mailing list it appears that this statement was motivated by a need in MOBIKE to deploy UDP encapsulation when NAT is not detected. So assuming that we want to cater for this in IPsec, we should extend IKE to explicitly negotiate UDP encapsulation, rather than having it rely on the result of NAT detection. Not discussed in SF. Yaron: this looks like an important issue! ------=_NextPart_001_0111_01C9B322.BBA9B0D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Herbert:

 

Recently the statement

 

"Implementations MUST = process received UDP-encapsulated ESP packets even when no NAT was = detected."

 

was added to the draft. This has the potential to = create black holes if deployed in the field, unless all implementations always use = UDP encapsulation regardless of NAT. The problem is that if a peer behind a firewall (with no NAT) that only allows inbound packets which are in = response to outbound packets performs UDP encapsulation without NAT, and the = remote peer responds without UDP encapsulation, then all data packets from the = remote peer will be dropped.

 

Looking at this from the point of view of the remote = peer, the only practical solution would be to always employ UDP encapsulation, = regardless of NAT detection.

 

Now through discussion on the mailing list it appears = that this statement was motivated by a need in MOBIKE to deploy UDP = encapsulation when NAT is not detected. So assuming that we want to cater for this in = IPsec, we should extend IKE to explicitly negotiate UDP encapsulation, rather than = having it rely on the result of NAT detection.

 

Not discussed in SF.

 

Yaron: this looks like an important = issue!

------=_NextPart_001_0111_01C9B322.BBA9B0D0-- ------=_NextPart_000_0110_01C9B322.BBA9B0D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMTIwMzY1MVowIwYJKoZIhvcNAQkEMRYEFBONM8NIwaVu PTtb3+19DMZER5mzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA fWLMDoj3t1FWVKKDfKlFJA6xDq0BxNNCbT5MaEYaVWoxrOTUALnWdb0uyaRbzk0pVPdGg03pngZK BkTv/9NOVpWacj37Vtit4apq7mSdXlIX0k09ygdPFiohwyAY5wiZDj9GgRMQHIoTS7GhXkHlpzVb N02g4gYVfoykMKL6EMTzLMbJ6IaCAuRNfy/hWVKH642vyQhJ3a08K3nJF0yIULiP0KIvkfSfEt/O BUUsfBYnql8PCngH9zppzlGTS982UM7XNKGK3pOmYtun4NzPoes++Ezi+tLIeGcDCzXBR5wfHeCv oR2eokop1DN3Wwkpi626Bg9nZuuXCw5O99HTcQAAAAAAAA== ------=_NextPart_000_0110_01C9B322.BBA9B0D0-- From smoonen@us.ibm.com Thu Apr 2 05:47:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABBF3A694F for ; Thu, 2 Apr 2009 05:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Moi3NNh8JIgl for ; Thu, 2 Apr 2009 05:47:05 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 51F1D3A6943 for ; Thu, 2 Apr 2009 05:47:05 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n32CjE9q005856 for ; Thu, 2 Apr 2009 06:45:14 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n32Cm6Ta230964 for ; Thu, 2 Apr 2009 06:48:06 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n32Cm5Ln017595 for ; Thu, 2 Apr 2009 06:48:06 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n32Cm5Px017592; Thu, 2 Apr 2009 06:48:05 -0600 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: CEA9360E:216083E3-8525758C:0045BC44; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Thu, 2 Apr 2009 08:48:05 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/02/2009 06:48:05, Serialize complete at 04/02/2009 06:48:05 Content-Type: multipart/alternative; boundary="=_alternative 00461A1C8525758C_=" Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:47:06 -0000 This is a multipart message in MIME format. --=_alternative 00461A1C8525758C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBGcm9tIEFwcGVuZGl4IEM6IFRoZSBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHNheSB3aGljaCBt ZXNzYWdlcyBjYW4gDQpjb250YWluIE4oU0VUX1dJTkRPV19TSVpFKS4gSXQgY2FuIHBvc3NpYmx5 IGJlIGluY2x1ZGVkIGluIGFueSBtZXNzYWdlLCANCmJ1dCBpdCBpcyBub3QgeWV0IHNob3duIGJl bG93Lg0KPiANCj4gU0YgZGlzY3Vzc2lvbjogUGF1bCBzYWlkLCDigJx3aGVyZXZlciB5b3Ugd2lz aC7igJ0NCg0KU2hvdWxkIHdlIHByb2hpYml0IG9yIGF0IGxlYXN0IGRpc2NvdXJhZ2UgaXQgaW4g dGhlIElLRV9TQV9JTklUIGV4Y2hhbmdlIA0Kc28gdGhhdCBpdCBpcyBub3Qgc3VzY2VwdGlibGUg dG8gdGhpcmQtcGFydHkgdGlua2VyaW5nPw0KDQoNClNjb3R0IE1vb25lbiAoc21vb25lbkB1cy5p Ym0uY29tKQ0Kei9PUyBDb21tdW5pY2F0aW9ucyBTZXJ2ZXIgVENQL0lQIERldmVsb3BtZW50DQpo dHRwOi8vc2NvdHQuYW5kc3R1ZmYub3JnLw0KaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vc21v b25lbg0KDQoNCg0KRnJvbToNCllhcm9uIFNoZWZmZXIgPHlhcm9uZkBjaGVja3BvaW50LmNvbT4N ClRvOg0KSVBzZWNtZSBXRyA8aXBzZWNAaWV0Zi5vcmc+DQpEYXRlOg0KMDQvMDEvMjAwOSAwNDoz OSBQTQ0KU3ViamVjdDoNCltJUHNlY10gSXNzdWUgIzI6IFdoZXJlIGRvZXMgTihTRVRfV0lORE9X X1NJWkUpIGdvPw0KDQoNCg0KRnJvbSBBcHBlbmRpeCBDOiBUaGUgc3BlY2lmaWNhdGlvbiBkb2Vz IG5vdCBzYXkgd2hpY2ggbWVzc2FnZXMgY2FuIGNvbnRhaW4gDQpOKFNFVF9XSU5ET1dfU0laRSku IEl0IGNhbiBwb3NzaWJseSBiZSBpbmNsdWRlZCBpbiBhbnkgbWVzc2FnZSwgYnV0IGl0IGlzIA0K bm90IHlldCBzaG93biBiZWxvdy4NCiANClNGIGRpc2N1c3Npb246IFBhdWwgc2FpZCwg4oCcd2hl cmV2ZXIgeW91IHdpc2gu4oCdDQogDQogW2F0dGFjaG1lbnQgInNtaW1lLnA3cyIgZGVsZXRlZCBi eSBTY290dCBDIE1vb25lbi9SYWxlaWdoL0lCTV0gDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQoNCg0K --=_alternative 00461A1C8525758C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mZ3Q7IEZyb20gQXBwZW5kaXggQzogVGhl IHNwZWNpZmljYXRpb24gZG9lcw0Kbm90IHNheSB3aGljaCBtZXNzYWdlcyBjYW4gY29udGFpbiBO KFNFVF9XSU5ET1dfU0laRSkuIEl0IGNhbiBwb3NzaWJseQ0KYmUgaW5jbHVkZWQgaW4gYW55IG1l c3NhZ2UsIGJ1dCBpdCBpcyBub3QgeWV0IHNob3duIGJlbG93LjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+Jmd0OyBTRiBkaXNjdXNzaW9uOiBQYXVsIHNhaWQsIOKAnHdoZXJldmVyDQp5 b3Ugd2lzaC7igJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5T aG91bGQgd2UgcHJvaGliaXQgb3IgYXQgbGVhc3QgZGlzY291cmFnZQ0KaXQgaW4gdGhlIElLRV9T QV9JTklUIGV4Y2hhbmdlIHNvIHRoYXQgaXQgaXMgbm90IHN1c2NlcHRpYmxlIHRvIHRoaXJkLXBh cnR5DQp0aW5rZXJpbmc/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpTY290dCBNb29uZW4gKHNtb29uZW5AdXMuaWJtLmNvbSk8YnI+DQp6L09T IENvbW11bmljYXRpb25zIFNlcnZlciBUQ1AvSVAgRGV2ZWxvcG1lbnQ8YnI+DQo8L2ZvbnQ+PGEg aHJlZj1odHRwOi8vc2NvdHQuYW5kc3R1ZmYub3JnLz48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+aHR0cDovL3Njb3R0LmFuZHN0dWZmLm9yZy88L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LmxpbmtlZGlu LmNvbS9pbi9zbW9vbmVuPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3 LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuPC9mb250PjwvYT4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPllhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZkBjaGVja3BvaW50LmNv bSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Ubzo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPklQc2VjbWUgV0cgJmx0O2lwc2VjQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMt c2VyaWYiPkRhdGU6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4w NC8wMS8yMDA5IDA0OjM5IFBNPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDo8L2ZvbnQ+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltJUHNlY10gSXNzdWUgIzI6IFdoZXJlIGRv ZXMgTihTRVRfV0lORE9XX1NJWkUpDQpnbz88L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxociBub3No YWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RnJvbSBBcHBl bmRpeCBDOiBUaGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdA0Kc2F5IHdoaWNoIG1lc3NhZ2VzIGNh biBjb250YWluIE4oU0VUX1dJTkRPV19TSVpFKS4gSXQgY2FuIHBvc3NpYmx5IGJlIGluY2x1ZGVk DQppbiBhbnkgbWVzc2FnZSwgYnV0IGl0IGlzIG5vdCB5ZXQgc2hvd24gYmVsb3cuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+U0YgZGlzY3Vzc2lvbjogUGF1bCBzYWlkLCDigJx3aGVyZXZlciB5 b3UNCndpc2gu4oCdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7W2F0dGFjaG1lbnQg JnF1b3Q7c21pbWUucDdzJnF1b3Q7IGRlbGV0ZWQNCmJ5IFNjb3R0IEMgTW9vbmVuL1JhbGVpZ2gv SUJNXSA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCklQc2VjQGll dGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwc2VjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHNlYzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0K --=_alternative 00461A1C8525758C_=-- From ynir@checkpoint.com Thu Apr 2 05:51:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2875A3A6A39 for ; Thu, 2 Apr 2009 05:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, 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 bZb3h4v5Mxc1 for ; Thu, 2 Apr 2009 05:51:36 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9B0163A6947 for ; Thu, 2 Apr 2009 05:51:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 44D9F2CC003; Thu, 2 Apr 2009 15:52:36 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 924F22CC001; Thu, 2 Apr 2009 15:51:22 +0300 (IDT) X-CheckPoint: {49D4B267-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 n32CpLXw007192; Thu, 2 Apr 2009 15:51:22 +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; Thu, 2 Apr 2009 15:51:21 +0300 From: Yoav Nir To: Scott C Moonen Date: Thu, 2 Apr 2009 15:52:24 +0300 Thread-Topic: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Thread-Index: AcmzkUr3tZHjcesFTrKuq6RPcFrQbgAAI1rw Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13A23@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361332A13A23ilex01adcheck_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:51:40 -0000 --_000_9FB7C7CE79B84449B52622B506C780361332A13A23ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Definitely ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Thursday, April 02, 2009 3:48 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? > From Appendix C: The specification does not say which messages can contai= n N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is= not yet shown below. > > SF discussion: Paul said, "wherever you wish." Should we prohibit or at least discourage it in the IKE_SA_INIT exchange so= that it is not susceptible to third-party tinkering? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 04/01/2009 04:39 PM Subject: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? ________________________________ >From Appendix C: The specification does not say which messages can contain = N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is n= ot yet shown below. SF discussion: Paul said, "wherever you wish." [attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] ___________= ____________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361332A13A23ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Definitely

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C=20 Moonen
Sent: Thursday, April 02, 2009 3:48 PM
To: Yar= on=20 Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Issue #2:= =20 Where does N(SET_WINDOW_SIZE) go?


> From Appendix C: The spec= ification=20 does not say which messages can contain N(SET_WINDOW_SIZE). It can possib= ly be=20 included in any message, but it is not yet shown below.
>  
= > SF=20 discussion: Paul said, “wherever you wish.”

Should we prohibit or at least discourage it in the IKE_SA_I= NIT=20 exchange so that it is not susceptible to third-party tinkering?=20


Scott Moonen=20 (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP=20 Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen= =20


From:=20 Yaron Sheffer=20 <yaronf@checkpoint.com>=20
To:=20 IPsecme WG=20 <ipsec@ietf.org>=20
Date:=20 04/01/2009 04:39 PM=20
Subject:= =20 [IPsec] Issue #2: Where does=20 N(SET_WINDOW_SIZE) go?




From Appendix C: The specificatio= n does=20 not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be= =20 included in any message, but it is not yet shown below.
 
SF di= scussion:=20 Paul said, “wherever you wish.”
 
 [attachm= ent=20 "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] _______________________________________________
IPsec mailing= =20 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec<= FONT=20 size=3D2>



= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361332A13A23ilex01adcheck_-- From ynir@checkpoint.com Thu Apr 2 06:25:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205DA3A6A19 for ; Thu, 2 Apr 2009 06:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, 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 YE97-N8JpGkA for ; Thu, 2 Apr 2009 06:25:44 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 619A53A689E for ; Thu, 2 Apr 2009 06:25:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A65FE30C001; Thu, 2 Apr 2009 16:26:43 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F2CD12CC001 for ; Thu, 2 Apr 2009 16:26:41 +0300 (IDT) X-CheckPoint: {49D4BAAE-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 n32DQfXw022307 for ; Thu, 2 Apr 2009 16:26:41 +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; Thu, 2 Apr 2009 16:26:40 +0300 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 2 Apr 2009 16:27:44 +0300 Thread-Topic: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying Thread-Index: AcmzBrWLnN1nB/1MTCelPsyuQrO1EQAiy/Ng Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361332A13A3Cilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:25:45 -0000 --_000_9FB7C7CE79B84449B52622B506C780361332A13A3Cilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tero. How about replacing this: The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors for the proposed Child SA in the TSi and TSr payloads. With this: The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors for the proposed Child SA in the TSi and TSr payloads. The TSi and TSr payloads SHOULD include the very specifig traffic selectors including the addresses in the packet triggering the request, as described in section 2.9. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, April 01, 2009 11:38 PM To: IPsecme WG Subject: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet = that trigerred the rekeying Tero: I think we should mention that the traffic selectors for the rekying should= have those selectors from the packet (see section 2.9): To allow responder to do intelligent narrowing of the traffic selector = the responder should know which packet triggered the rekeying, so it will n= ot narrow the traffic selectors to set which is not usable for the packet t= riggering the rekeying. This means that even the traffic selectors for the = rekeying needs to have those selectors from the packet (see section 2.9). N= ote, that if the responders policy has changed, it is possible that origina= lly traffic that fit to one SA cannot fit to one SA anymore, which means th= e responder will narrow the traffic selectors so that not all original traf= fic fits to SA anymore. In that case the initiator getting packet that only= fits the old SA (which is waiting to be deleted) but not new, should creat= e new SA for this traffic too (but it is not rekeying anymore, so no REKEY_= SA notify is included in the exchange). Same thing happens when the origina= l SA expires, and one ends gets packet which not fit the current traffic se= lectors, but instead triggers new SA creation. No SF discussion. =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361332A13A3Cilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Tero.
 
How about replacing this:
   T= he=20 initiator sends SA offer(s) in the SA payload, a nonce in the Ni
 &= nbsp;=20 payload, optionally a Diffie-Hellman value in the KEi payload,=20 and
   the proposed traffic selectors for the proposed Child S= A in=20 the TSi
   and TSr payloads.
 
With this:
   T= he=20 initiator sends SA offer(s) in the SA payload, a nonce in the Ni
 &= nbsp;=20 payload, optionally a Diffie-Hellman value in the KEi payload,=20 and
   the proposed traffic selectors for the proposed Child S= A in=20 the TSi
   and TSr payloads. The TSi and= TSr=20 payloads SHOULD include the
   very specifig traffic selectors including the= =20 addresses in the packet
   triggering the request, as described in sectio= n=20 2.9.

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron=20 Sheffer
Sent: Wednesday, April 01, 2009 11:38 PM
To:= =20 IPsecme WG
Subject: [IPsec] Issue #12: Traffic selectors when=20 rekeying vs. the packet that trigerred the rekeying

Tero:

 

I think we should mention t= hat the=20 traffic selectors for the rekying should have those selectors from the pa= cket=20 (see section 2.9):

 

    To allow= =20 responder to do intelligent narrowing of the traffic selector the respond= er=20 should know which packet triggered the rekeying, so it will not narrow th= e=20 traffic selectors to set which is not usable for the packet triggering th= e=20 rekeying. This means that even the traffic selectors for the rekeying nee= ds to=20 have those selectors from the packet (see section 2.9). Note, that if the= =20 responders policy has changed, it is possible that originally traffic tha= t fit=20 to one SA cannot fit to one SA anymore, which means the responder will na= rrow=20 the traffic selectors so that not all original traffic fits to SA anymore= . In=20 that case the initiator getting packet that only fits the old SA (which i= s=20 waiting to be deleted) but not new, should create new SA for this traffic= too=20 (but it is not rekeying anymore, so no REKEY_SA notify is included in the= =20 exchange). Same thing happens when the original SA expires, and one ends = gets=20 packet which not fit the current traffic selectors, but instead triggers = new=20 SA creation.

 

No SF=20 discussion.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361332A13A3Cilex01adcheck_-- From ynir@checkpoint.com Thu Apr 2 06:41:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D003A68C4 for ; Thu, 2 Apr 2009 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 ySJZzddxLoCc for ; Thu, 2 Apr 2009 06:41:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9A7113A6B19 for ; Thu, 2 Apr 2009 06:41:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8889530C002; Thu, 2 Apr 2009 16:42:40 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 03D5D2CC001; Thu, 2 Apr 2009 16:41:23 +0300 (IDT) X-CheckPoint: {49D4BE1F-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 n32DfMXw028404; Thu, 2 Apr 2009 16:41:22 +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; Thu, 2 Apr 2009 16:41:21 +0300 From: Yoav Nir To: Scott C Moonen Date: Thu, 2 Apr 2009 16:42:25 +0300 Thread-Topic: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Thread-Index: AcmzkUr3tZHjcesFTrKuq6RPcFrQbgAAI1rwAAGHlEA= Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13A43@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A23@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13A23@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361332A13A43ilex01adcheck_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:41:45 -0000 --_000_9FB7C7CE79B84449B52622B506C780361332A13A43ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, just "yes", not "definitely". All payloads in the IKE_SA_INIT are protected by the AUTH payload in the IK= E_AUTH exchange, so if crypto works, a third party will not be able to tink= er with it. On the other hand, at the end of the IKE_SA_INIT exchange, there is no IKE = SA, so setting up some properties of that as-yet-non-existant IKE SA seems = premature to me. I think it should be in all but the IKE_SA_INIT exchange (= and also not in unprotected informational) ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Thursday, April 02, 2009 3:52 PM To: Scott C Moonen Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Definitely ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Thursday, April 02, 2009 3:48 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? > From Appendix C: The specification does not say which messages can contai= n N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is= not yet shown below. > > SF discussion: Paul said, "wherever you wish." Should we prohibit or at least discourage it in the IKE_SA_INIT exchange so= that it is not susceptible to third-party tinkering? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 04/01/2009 04:39 PM Subject: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? ________________________________ >From Appendix C: The specification does not say which messages can contain = N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is n= ot yet shown below. SF discussion: Paul said, "wherever you wish." [attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] ___________= ____________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361332A13A43ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Actually, just "yes", not "definitely".
 
All payloads in the IKE_SA_INIT are protected by the = AUTH=20 payload in the IKE_AUTH exchange, so if crypto works, a third party will no= t be=20 able to tinker with it.
 
On the other hand, at the end of the IKE_SA_INIT exch= ange,=20 there is no IKE SA, so setting up some properties of that as-yet-non-exista= nt=20 IKE SA seems premature to me. I think it should be in all but the IKE_SA_IN= IT=20 exchange (and also not in unprotected informational)
From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent:<= /B>=20 Thursday, April 02, 2009 3:52 PM
To: Scott C Moonen
Cc:=20 IPsecme WG
Subject: Re: [IPsec] Issue #2: Where does=20 N(SET_WINDOW_SIZE) go?

Definitely

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C=20 Moonen
Sent: Thursday, April 02, 2009 3:48 PM
To: Y= aron=20 Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Issue #= 2:=20 Where does N(SET_WINDOW_SIZE) go?


> From Appendix C: The=20 specification does not say which messages can contain N(SET_WINDOW_SIZE= ). It=20 can possibly be included in any message, but it is not yet shown=20 below.
>  
> SF discussion: Paul said, “wherever yo= u wish.”=20

Should we prohibit or at least disc= ourage it=20 in the IKE_SA_INIT exchange so that it is not susceptible to third-part= y=20 tinkering?


Scott Mo= onen=20 (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP=20 Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:=20 Yaron Sheffer=20 <yaronf@checkpoint.com>=20
To:=20 IPsecme WG=20 <ipsec@ietf.org>=20
Date:=20 04/01/2009 04:39 PM=20
Subject:=20 [IPsec] Issue #2: Where does=20 N(SET_WINDOW_SIZE) go?




From Appendix C: The specificat= ion does=20 not say which messages can contain N(SET_WINDOW_SIZE). It can possibly = be=20 included in any message, but it is not yet shown below.
 
SF = discussion:=20 Paul said, “wherever you wish.”
 
 [attac= hment=20 "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] _______________________________________________
IPsec maili= ng=20 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




Email secured by = Check=20 Point


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361332A13A43ilex01adcheck_-- From yaronf@checkpoint.com Thu Apr 2 14:17:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84ECA3A68B2 for ; Thu, 2 Apr 2009 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 8lMLo0hVhq8m for ; Thu, 2 Apr 2009 14:17:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D35643A67A7 for ; Thu, 2 Apr 2009 14:17:25 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 33F3430C002; Fri, 3 Apr 2009 00:18:26 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 198AA30C001; Fri, 3 Apr 2009 00:18:24 +0300 (IDT) X-CheckPoint: {49D52936-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 n32LIMXw016032; Fri, 3 Apr 2009 00:18:22 +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; Fri, 3 Apr 2009 00:18:22 +0300 From: Yaron Sheffer To: Yoav Nir , Scott C Moonen Date: Fri, 3 Apr 2009 00:18:21 +0300 Thread-Topic: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Thread-Index: AcmzkUr3tZHjcesFTrKuq6RPcFrQbgAAI1rwAAGHlEAAEA19AA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE8C1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A23@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A43@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13A43@il-ex01.ad.checkpoint.com> 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_0142_01C9B3F1.B1D81B30" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:17:32 -0000 ------=_NextPart_000_0142_01C9B3F1.B1D81B30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0143_01C9B3F1.B1D81B30" ------=_NextPart_001_0143_01C9B3F1.B1D81B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav, I don't see your point, since you're obviously setting up *some* properties of the tentative IKE SA during IKE_SA_INIT. And it seems to be a very convenient place to send N(SET_WINDOW_SIZE). So why not? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, April 02, 2009 16:42 To: Scott C Moonen Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Actually, just "yes", not "definitely". All payloads in the IKE_SA_INIT are protected by the AUTH payload in the IKE_AUTH exchange, so if crypto works, a third party will not be able to tinker with it. On the other hand, at the end of the IKE_SA_INIT exchange, there is no IKE SA, so setting up some properties of that as-yet-non-existant IKE SA seems premature to me. I think it should be in all but the IKE_SA_INIT exchange (and also not in unprotected informational) _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, April 02, 2009 3:52 PM To: Scott C Moonen Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? Definitely _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, April 02, 2009 3:48 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? > From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. > > SF discussion: Paul said, "wherever you wish." Should we prohibit or at least discourage it in the IKE_SA_INIT exchange so that it is not susceptible to third-party tinkering? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 04/01/2009 04:39 PM Subject: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? _____ >From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. SF discussion: Paul said, "wherever you wish." [attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point Email secured by Check Point Scanned by Check Point Total Security Gateway. ------=_NextPart_001_0143_01C9B3F1.B1D81B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Yoav,

 

I don’t see your point, since = you’re obviously setting up *some* properties of the tentative IKE SA during IKE_SA_INIT. And it seems to = be a very convenient place to send N(SET_WINDOW_SIZE). So why = not?

 

Thanks,

=

      =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Thursday, April 02, = 2009 16:42
To: Scott C Moonen
Cc: IPsecme WG
Subject: Re: [IPsec] = Issue #2: Where does N(SET_WINDOW_SIZE) go?

 

Actually, just "yes", not "definitely".

 

All payloads in the IKE_SA_INIT are protected by the AUTH payload in the IKE_AUTH exchange, so if crypto = works, a third party will not be able to tinker with = it.

 

On the other hand, at the end of = the IKE_SA_INIT exchange, there is no IKE SA, so setting up some properties = of that as-yet-non-existant IKE SA seems premature to me. I think it should be = in all but the IKE_SA_INIT exchange (and also not in unprotected = informational)

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Thursday, April 02, = 2009 3:52 PM
To: Scott C Moonen
Cc: IPsecme WG
Subject: Re: [IPsec] = Issue #2: Where does N(SET_WINDOW_SIZE) go?

Definitely<= /p>

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen
Sent: Thursday, April 02, = 2009 3:48 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] = Issue #2: Where does N(SET_WINDOW_SIZE) go?


> From Appendix C: The specification does not say which = messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, = but it is not yet shown below.
>  
> SF discussion: Paul said, “wherever you wish.” =

Should we prohibit or at least discourage it in the IKE_SA_INIT exchange so = that it is not susceptible to third-party tinkering?


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.o= rg/
http://www.linkedin.com= /in/smoonen

From:

Yaron = Sheffer <yaronf@checkpoint.com>

To:=

IPsecme WG <ipsec@ietf.org>

Date:

04/01/2009 04:39 PM =

Subject:

[IPsec] Issue #2: Where does = N(SET_WINDOW_SIZE) go?

 




From Appendix C: The specification does not say which messages = can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, = but it is not yet shown below.
 
SF discussion: Paul said, “wherever you wish.” =
 
 [attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] = ______________________________________________= _
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



Email secured by Check Point



Email secured by Check Point



Scanned by Check Point Total Security Gateway. =

------=_NextPart_001_0143_01C9B3F1.B1D81B30-- ------=_NextPart_000_0142_01C9B3F1.B1D81B30 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwMjIxMTgyMFowIwYJKoZIhvcNAQkEMRYEFBn/7C7ABQme OF2ePgixN6CpWQ6pMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA XYmOjGsG2PVdZZC4RMJ7Sw78Wat0TOTyhqNL2+JLiBg2ORMqlcp3cWdlmtCPRZIrNUkG5qFFM4SF lOe/f+mg0kd0ThJk0kLkc852d0nxAunbv/vXLaTc+PFxhgyU5IeTveMk9DOQvpfxYQsydaXEKAbS UhvCR1rs7XhrzHoa2IAGzrvgh0cnuFVtepAsqyuwPZulOsMRu835vxfOcyfeNknGoih5NIJZ2DRc S7+kh4CKJF/1HnSFReWqh6BlOecionbs6whxviJWwPVa25CJrddzaEll0N7o6c8SsAI95kUtRfcG hO4AiNdRbrvWZVAKxZM3y/Es2sL3QvDk2UeVawAAAAAAAA== ------=_NextPart_000_0142_01C9B3F1.B1D81B30-- From kivinen@iki.fi Fri Apr 3 05:51:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB0A3A6B92 for ; Fri, 3 Apr 2009 05:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 PJCsuirD7a7h for ; Fri, 3 Apr 2009 05:51:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 471BB3A6AC4 for ; Fri, 3 Apr 2009 05:51:46 -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 n33CqfVo022222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 15:52:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n33Cqff3020582; Fri, 3 Apr 2009 15:52:41 +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: <18902.1689.199526.811831@fireball.kivinen.iki.fi> Date: Fri, 3 Apr 2009 15:52:41 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 5 min Cc: IPsecme WG Subject: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:51:48 -0000 Yaron Sheffer writes: > >From Appendix C: The specification does not say which messages can contain > N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is > not yet shown below. > > SF discussion: Paul said, "wherever you wish." I agree on that. Logical places are: 1) In separate the INFORMATIONAL exchange immediately after IKE_AUTH or IKE SA rekey CREATE_CHILD_SA to set the initial window. 2) In the IKE_AUTH or in the IKE SA rekey CREATE_CHILD_SA to set initial window. I do not think there is any need to prefer either one of those two locations. Usually the window size is something that is set once after the IKE SA is created (and after it is rekeyed), and it will never be changed after that. -- kivinen@iki.fi From kivinen@iki.fi Fri Apr 3 05:54:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED033A6BC6 for ; Fri, 3 Apr 2009 05:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 U-1qIxNvl6+a for ; Fri, 3 Apr 2009 05:54:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B0CFA3A6AC4 for ; Fri, 3 Apr 2009 05:54:14 -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 n33CtD0j005752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 15:55:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n33CtDZR029003; Fri, 3 Apr 2009 15:55:13 +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: <18902.1841.592643.614727@fireball.kivinen.iki.fi> Date: Fri, 3 Apr 2009 15:55:13 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72E@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72E@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: IPsecme WG Subject: [IPsec] Issue #63: Position of arbitrary notify payloads X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:54:15 -0000 Yaron Sheffer writes: > Yaron: > > Appendix C: please also mention extension notifications [N+], other than in > C.6. > > Paul: > > Maybe copy it everywhere like we have [V+] That is ok for me. Btw, is there any reason why [V+] is not listed in the IKE_AUTH excghange with EAP in the intermediate EAP messages and final AUTH request from the initiator? -- kivinen@iki.fi From kivinen@iki.fi Fri Apr 3 06:05:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377213A6CE9 for ; Fri, 3 Apr 2009 06:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrhZgOBLEnol for ; Fri, 3 Apr 2009 06:05:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id DC02D3A6D56 for ; Fri, 3 Apr 2009 06:05:34 -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 n33D6X9s008171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 16:06:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n33D6XP2023801; Fri, 3 Apr 2009 16:06:33 +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: <18902.2521.469247.128444@fireball.kivinen.iki.fi> Date: Fri, 3 Apr 2009 16:06:33 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72C@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: IPsecme WG Subject: [IPsec] Issue #53: Handling of INITIAL_CONTACT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:05:36 -0000 Yaron Sheffer writes: > Yaron: > > 2.4: Clarif-7.9 is unclear: [this MUST be sent in the first IKE_AUTH > request.] 'however, receiving parties need to deal with it in other > requests' - what requests? How? Why should it ever happen? > > SF discussion: > > David Black: if you put initial_contact in anything other than an IKE_AUTH > > something is wrong, do you have the critical bit on it? > > Tero: comes from IKEv1 > > Greg Lebowitz: clarify: only pay attention to it if it arrives in > IKE_AUTH To clarify how it comes from IKEv1: In the IKEv1 the extra notification payloads sent along the main mode or aggresive mode exchanges were not authenticated, meaning that attackers could add / remove those. Because of this it was considered unsafe to send INITIAL_CONTACT notifications during the initial phase 1, and it was usually sent only after the initial exchange as a separate informational exchange. As in IKEv2 the IKE_AUTH messages are authenticated, I do not really see any reason why we should allow INITIAL_CONTACT anywhere else than in the IKE_AUTH request, but as the generic rule says you can put status notifications anywhere, and those should not cause errors, meaning that if INITIAL_CONTACT is sent anywhere else it can be ignored. I remember there was also discussion earlier whether the responder can send INITIAL_CONTACT notification to tell that it does not have any SAs. The current ikev2bis text says it MUST be first IKE_AUTH request, meaning it cannot be sent by the responder (which is sending IKE_AUTH response, not request). I think the current MUST is ok, and we should just change the "receiving parties need to deal with it in other requests." to "receiving parties MAY ignore it in other messages." I do not want implementations to fail the whole IKE SA because of someone reused old IKEv1 code and sent INITIAL_CONTACT as separate INFORMATIONAL exchange. Ignoring it is safe option, as it does provide interoperability. Processing it in other exchanges should also be allowed, but not required (i.e. I do not want to make some implementation non-conformant, just because they want to be backwards compatible with their old versions which sent INITIAL_CONTACT in "wrong" place). The whole INITIAL_CONTACT processing is only optimization and not very important for the IKEv2, as the IKEv2 is reliable protocol, meaning that other end most likely have already detetected that the old IKE SA was lost before the initiator reconnects after crash. -- kivinen@iki.fi From kivinen@iki.fi Fri Apr 3 06:13:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE75D3A6CCA for ; Fri, 3 Apr 2009 06:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeXzHcIsxr0B for ; Fri, 3 Apr 2009 06:13:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A4C843A69E6 for ; Fri, 3 Apr 2009 06:13:42 -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 n33DEf4k018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 16:14:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n33DEeOw023929; Fri, 3 Apr 2009 16:14:40 +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=unknown Content-Transfer-Encoding: 7bit Message-ID: <18902.3008.958757.496694@fireball.kivinen.iki.fi> Date: Fri, 3 Apr 2009 16:14:40 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 4 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:13:43 -0000 Scott C Moonen writes: > > From Appendix C: The specification does not say which messages can > contain N(SET_WINDOW_SIZE). It can possibly be included in any message, > but it is not yet shown below. > > > > SF discussion: Paul said, $,1r|(Bwherever you wish.$,1r} (B> > Should we prohibit or at least discourage it in the IKE_SA_INIT exchange > so that it is not susceptible to third-party tinkering? The full contents of the IKE_SA_INIT message is also authenticated after the IKE_AUTH finishes, so there is no security reason to discourage it in the IKE_SA_INIT. Of course there are other reasons not to send it in the IKE_SA_INIT. IKE_SA_INIT should be kept as small as possible. Also the window size only takes effect after the IKE_AUTH finishes. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Apr 6 23:25:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF753A67F0 for ; Mon, 6 Apr 2009 23:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_05=-1.11, 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 US-0DlpHF8tI for ; Mon, 6 Apr 2009 23:25:46 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5A4CA3A6359 for ; Mon, 6 Apr 2009 23:25:45 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9C69C30C001; Tue, 7 Apr 2009 09:26:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4C5082CC001 for ; Tue, 7 Apr 2009 09:26:50 +0300 (IDT) X-CheckPoint: {49DAEF71-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 n376QnqO022778 for ; Tue, 7 Apr 2009 09:26:49 +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; Tue, 7 Apr 2009 09:26:49 +0300 From: Yaron Sheffer To: IPsecme WG Date: Tue, 7 Apr 2009 09:26:45 +0300 Thread-Topic: Mark your calendars: ipsecme virtual interim on May 5 Thread-Index: Acm3SdKJeKKa18z1Tey5r51n8Hlp+w== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEC2D@il-ex01.ad.checkpoint.com> 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_0055_01C9B762.F827DD90" MIME-Version: 1.0 Subject: [IPsec] Mark your calendars: ipsecme virtual interim on May 5 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:25:47 -0000 ------=_NextPart_000_0055_01C9B762.F827DD90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0056_01C9B762.F827DD90" ------=_NextPart_001_0056_01C9B762.F827DD90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Just a heads up for now: we will have a conference call on Tuesday May 5, 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Let us know if you have any major issues with the time and/or the format. Thanks, Yaron ------=_NextPart_001_0056_01C9B762.F827DD90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Just a heads up for now: we will have a conference = call on Tuesday May 5, 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. We are planning on the = same format as the previous time: a VoIP conference bridge and posted slides. = Let us know if you have any major issues with the time and/or the = format.

 

Thanks,

         =    Yaron

------=_NextPart_001_0056_01C9B762.F827DD90-- ------=_NextPart_000_0055_01C9B762.F827DD90 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwNzA2MjY0NVowIwYJKoZIhvcNAQkEMRYEFE7REtkPmKxs +0qhViM7Cv45V6j3MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA qk4sgwxuBzfOisjpQc8WVpbDjyDTiu0F9GBv5k8znnPOfJ7AFy6HyP1GN85FpYpDzg1FaJN1RLLb MblowQ6UEWDtKqCGD2LRQoebXOYw3gKd1OVIda6vVpCnEo6CBcalixqwUd0eRPoa5JiNhgZvNYk+ LxfGI48flxXnuMfwywT+A6hBfY44V0FmRfNqqRt6NzewrsnyrmGx+a5+2ztcBwEjtuCnjJ9lo3kv x3m+uzXDoI1kAplWvYPcfaiyTT8q87VnVPbVNPxz9B8+k9/Hvrj3caoyI/pPZdpvIglCr8EztIyA n/x3F9pnFwmnqvKQiXWAr4QjzFt5/JvkUkXpxAAAAAAAAA== ------=_NextPart_000_0055_01C9B762.F827DD90-- From yaronf@checkpoint.com Mon Apr 6 23:31:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644E13A67F5 for ; Mon, 6 Apr 2009 23:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 KuDiiE9rSp1H for ; Mon, 6 Apr 2009 23:31:24 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 953883A6359 for ; Mon, 6 Apr 2009 23:31:23 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 770EB30C001; Tue, 7 Apr 2009 09:32:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 35DAC2CC001 for ; Tue, 7 Apr 2009 09:32:29 +0300 (IDT) X-CheckPoint: {49DAF0C3-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 n376WSqO024874 for ; Tue, 7 Apr 2009 09:32:28 +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; Tue, 7 Apr 2009 09:32:28 +0300 From: Yaron Sheffer To: IPsecme WG Date: Tue, 7 Apr 2009 09:32:24 +0300 Thread-Topic: Roadmap doc comment: IPsec performance testing Thread-Index: Acm3SpzAgpdnsro5QxCIv9Q1xam58w== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEC37@il-ex01.ad.checkpoint.com> 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_005D_01C9B763.C21940D0" MIME-Version: 1.0 Subject: [IPsec] Roadmap doc comment: IPsec performance testing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:31:25 -0000 ------=_NextPart_000_005D_01C9B763.C21940D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005E_01C9B763.C21940D0" ------=_NextPart_001_005E_01C9B763.C21940D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sheila, Suresh, This issue may have been raised before, but I think the two bmwg documents on IPsec performance testing do belong in the Roadmap doc: http://tools.ietf.org/id/draft-ietf-bmwg-ipsec-meth-04.txt http://tools.ietf.org/id/draft-ietf-bmwg-ipsec-term-11.txt They have just been resubmitted to BMWG, and seem finally on their way to be published. Thanks, Yaron ------=_NextPart_001_005E_01C9B763.C21940D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sheila, Suresh,

 

This issue may have been raised before, but I think = the two bmwg documents on IPsec performance testing do belong in the Roadmap = doc:

http:= //tools.ietf.org/id/draft-ietf-bmwg-ipsec-meth-04.txt

http:= //tools.ietf.org/id/draft-ietf-bmwg-ipsec-term-11.txt

 

They have just been resubmitted to BMWG, and seem = finally on their way to be published.

 

Thanks,

         =    Yaron

------=_NextPart_001_005E_01C9B763.C21940D0-- ------=_NextPart_000_005D_01C9B763.C21940D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwNzA2MzIyNFowIwYJKoZIhvcNAQkEMRYEFLr/AsNSqIjK x4HSB7A3ACp5ImpoMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA DV6/9j1vlVAzEsNjylP3FhUbsiXTjM8Tb47lYYh1tDmDvtzIwfbpzjWvb0i/xtTQwGYw/SjvA5dj by2YbCAgg10KSvlnB2Z8ngjg/ZILNVSSf6jY7ehyoonOHIYcDVgpPWb11SYiY6Ya7hZcHfv5KBtx RzUZT6gR49NthSs+EZ9U9/SdIY1SX1v0Cz1aJNqNrIeCNMcdUYfBKqxcu30q8ZNcRTwKF+AL8swx rIgTOn0rtOmjgPRKTTC28031d/g2dzY4V4SrxHqQsHsmZun3IqyltsD5A/28TwsHl9sBlPqCwKMZ COEtgmoBERk8THNhZlx2s1vjNL9mG+mEZo5JcgAAAAAAAA== ------=_NextPart_000_005D_01C9B763.C21940D0-- From mcins1@gmail.com Tue Apr 7 02:50:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916EE3A67AF for ; Tue, 7 Apr 2009 02:50:51 -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 JmSLzwTqJRrJ for ; Tue, 7 Apr 2009 02:50:50 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 53F993A67FD for ; Tue, 7 Apr 2009 02:50:49 -0700 (PDT) Received: by bwz17 with SMTP id 17so2225464bwz.37 for ; Tue, 07 Apr 2009 02:51:55 -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; bh=YMEujK069xGLHIV8r2N48d0tj+yJNRcr4Pt86a4Y2DI=; b=b8LbzMmPJ0UaQY6VPfp6A0rmYFnOmNARWq+evNl54/WbeiAkA7Xn3POKNikdAyB9JN 9IKCYf3hR77vEAL4PKCPFAlWM+8vdCtwtlugpithHCe3M8ApTlLzOKJFYnwqD6stDZCG +HTiqGAt1dLddLnZ6g7maFNcSfAUedtJuucuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LrKsP5AVLST3jV4aDYigkFk6SA+CpsXmhaU7B9H0YitSWHFpn0LaDzRifc3l9g4ehQ +O24M9lfkJdBAyIoTMXdTG2R2o9Ux74V7ucrj3yIpSlJlUb2fERGdwcVuYbELvpvDngM ArwuPIkV6OHtsHCcDHagyMW06oP2d5fusVztI= MIME-Version: 1.0 Received: by 10.204.116.212 with SMTP id n20mr2567999bkq.138.1239097915651; Tue, 07 Apr 2009 02:51:55 -0700 (PDT) Date: Tue, 7 Apr 2009 11:51:55 +0200 Message-ID: <99043b4a0904070251m74e14990g20657c6c6321f3d1@mail.gmail.com> From: Matthew Cini Sarreo To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e6d999da1ab9c40466f3f796 Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 09:50:51 -0000 --0016e6d999da1ab9c40466f3f796 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, While reading through ikev2 bis 02 (this is most certainly not something new that surfaced in this document), section 1.4, par 3 states: "Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it). *That response MAY be a message with no payloads*. The request message in an INFORMATIONAL exchange MAY also contain no payloads. This is the expected way an endpoint can ask the other endpoint to verify that it is alive." I would like to ask the reason behind this. As "live peer detection" is done by sending an empty INFORMATIONAL exchange (Encrypted Payload with no payloads), wouldn't it better to have a response be constructed in such a way so that the requesting peer can explicitly "know" that this INFORMATIONAL exchange is a confirmation of the request sent? This way, the requester would have to parse the response, and not decrypt the message, discover that there is no payload in the Encrypted Payload, check if the message is marked as a response and assume it is a confirmation of a request. Would a message ID be used to check the corresponding request? And if then the message ID on the responder (to the INFORMATIONAL exchange) somehow got messed up and does not match what the requester is expecting? Regards, Matt --0016e6d999da1ab9c40466f3f796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

While reading through ikev2 bis 02 (this is most certainly no= t something new that surfaced in this document), section 1.4, par 3 states:=

"Messages in an INFORMATIONAL exchange contain zero or more N= otification, Delete, and Configuration payloads.=A0 The Recipient of=A0an I= NFORMATIONAL exchange request MUST send some response (else the Sender will= assume the message was lost in the network and will retransmit it).=A0 = That response MAY be a message with no payloads. The request message in= an INFORMATIONAL exchange MAY also contain no payloads.=A0 This is the exp= ected way an endpoint can ask the other endpoint to verify that it is alive= ."

I would like to ask the reason behind this. As "live peer detectio= n" is done by sending an empty INFORMATIONAL exchange (Encrypted Paylo= ad with no payloads), wouldn't it better to have a response be construc= ted in such a way so that the requesting peer can explicitly "know&quo= t; that this INFORMATIONAL exchange is a confirmation of the request sent? = This way, the requester would have to parse the response, and not decrypt t= he message, discover that there is no payload in the Encrypted Payload, che= ck if the message is marked as a response and assume it is a confirmation o= f a request. Would a message ID be used to check the corresponding request?= And if then the message ID on the responder (to the INFORMATIONAL exchange= ) somehow got messed up and does not match what the requester is expecting?=

Regards,
Matt
--0016e6d999da1ab9c40466f3f796-- From ynir@checkpoint.com Tue Apr 7 03:00:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B48C3A6DB6 for ; Tue, 7 Apr 2009 03:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 A3ZwV4dXUxSj for ; Tue, 7 Apr 2009 03:00:33 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4D9D43A699C for ; Tue, 7 Apr 2009 03:00:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BB43E30C002; Tue, 7 Apr 2009 13:01:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7D4222CC001; Tue, 7 Apr 2009 13:01:37 +0300 (IDT) X-CheckPoint: {49DB21C5-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 n37A1aqO024515; Tue, 7 Apr 2009 13:01:37 +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; Tue, 7 Apr 2009 13:01:36 +0300 From: Yoav Nir To: Matthew Cini Sarreo , "ipsec@ietf.org" Date: Tue, 7 Apr 2009 13:02:54 +0300 Thread-Topic: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation Thread-Index: Acm3ZoaoLEDrZTLgQYef8jPMnhDwoQAARjoQ Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13D2E@il-ex01.ad.checkpoint.com> References: <99043b4a0904070251m74e14990g20657c6c6321f3d1@mail.gmail.com> In-Reply-To: <99043b4a0904070251m74e14990g20657c6c6321f3d1@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361332A13D2Eilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:00:34 -0000 --_000_9FB7C7CE79B84449B52622B506C780361332A13D2Eilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Matt Requests and responses have matching MsgID numbers. The requestor can insta= ntly identify the response by its matching Msg ID number. INFORMATIONAL exc= hanges have message authentication codes applied to messages, so the ID num= bers can't (or shouldn't) get "messed up" on the responsder. If it doesn't= match, it's an invalid message. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of M= atthew Cini Sarreo Sent: Tuesday, April 07, 2009 12:52 PM To: ipsec@ietf.org Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivat= ion Hello, While reading through ikev2 bis 02 (this is most certainly not something ne= w that surfaced in this document), section 1.4, par 3 states: "Messages in an INFORMATIONAL exchange contain zero or more Notification, D= elete, and Configuration payloads. The Recipient of an INFORMATIONAL excha= nge request MUST send some response (else the Sender will assume the messag= e was lost in the network and will retransmit it). That response MAY be a = message with no payloads. The request message in an INFORMATIONAL exchange = MAY also contain no payloads. This is the expected way an endpoint can ask= the other endpoint to verify that it is alive." I would like to ask the reason behind this. As "live peer detection" is don= e by sending an empty INFORMATIONAL exchange (Encrypted Payload with no pay= loads), wouldn't it better to have a response be constructed in such a way = so that the requesting peer can explicitly "know" that this INFORMATIONAL e= xchange is a confirmation of the request sent? This way, the requester woul= d have to parse the response, and not decrypt the message, discover that th= ere is no payload in the Encrypted Payload, check if the message is marked = as a response and assume it is a confirmation of a request. Would a message= ID be used to check the corresponding request? And if then the message ID = on the responder (to the INFORMATIONAL exchange) somehow got messed up and = does not match what the requester is expecting? Regards, Matt =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361332A13D2Eilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Matt
 
Requests an= d responses=20 have matching MsgID numbers. The requestor can instantly identify the respo= nse=20 by its matching Msg ID number. INFORMATIONAL exchanges have message=20 authentication codes applied to messages, so the ID numbers can't (or shoul= dn't)=20 get "messed up" on the responsder.  If it doesn't match, it's an inval= id=20 message.
From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Matthew Cini=20 Sarreo
Sent: Tuesday, April 07, 2009 12:52 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] IKEv2: Question on INFORMATIONA= L=20 exchange response motivation

Hello,

While reading through ikev2 bis 02 (this is most= =20 certainly not something new that surfaced in this document), section 1.4,= par=20 3 states:

"Messages in an INFORMATIONAL exchange contain zero or = more=20 Notification, Delete, and Configuration payloads.  The Recipient=20 of an INFORMATIONAL exchange request MUST send some response (else t= he=20 Sender will assume the message was lost in the network and will retransmi= t=20 it).  That response MAY be a message with no payloads. The re= quest=20 message in an INFORMATIONAL exchange MAY also contain no payloads.  = This=20 is the expected way an endpoint can ask the other endpoint to verify that= it=20 is alive."

I would like to ask the reason behind this. As "live pe= er=20 detection" is done by sending an empty INFORMATIONAL exchange (Encrypted= =20 Payload with no payloads), wouldn't it better to have a response be=20 constructed in such a way so that the requesting peer can explicitly "kno= w"=20 that this INFORMATIONAL exchange is a confirmation of the request sent? T= his=20 way, the requester would have to parse the response, and not decrypt the= =20 message, discover that there is no payload in the Encrypted Payload, chec= k if=20 the message is marked as a response and assume it is a confirmation of a= =20 request. Would a message ID be used to check the corresponding request? A= nd if=20 then the message ID on the responder (to the INFORMATIONAL exchange) some= how=20 got messed up and does not match what the requester is=20 expecting?

Regards,
Matt

= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361332A13D2Eilex01adcheck_-- From kivinen@iki.fi Tue Apr 7 03:26:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632C33A67EC for ; Tue, 7 Apr 2009 03:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je94ItQx0kUV for ; Tue, 7 Apr 2009 03:26:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 83B3B3A680C for ; Tue, 7 Apr 2009 03:26:22 -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 n37ARObc027444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 13:27:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n37AROZa024557; Tue, 7 Apr 2009 13:27:24 +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: <18907.10892.26451.683403@fireball.kivinen.iki.fi> Date: Tue, 7 Apr 2009 13:27:24 +0300 From: Tero Kivinen To: Matthew Cini Sarreo In-Reply-To: <99043b4a0904070251m74e14990g20657c6c6321f3d1@mail.gmail.com> References: <99043b4a0904070251m74e14990g20657c6c6321f3d1@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:26:27 -0000 Matthew Cini Sarreo writes: > I would like to ask the reason behind this. As "live peer detection" is done > by sending an empty INFORMATIONAL exchange (Encrypted Payload with no > payloads), wouldn't it better to have a response be constructed in such a > way so that the requesting peer can explicitly "know" that this > INFORMATIONAL exchange is a confirmation of the request sent? This is already done. Each request has unique message-id, and each response will have same message-id, so other end can always tie correct request and responses togehter. > This way, the requester would have to parse the response, and not > decrypt the message, discover that there is no payload in the > Encrypted Payload, check if the message is marked as a response and > assume it is a confirmation of a request. Would a message ID be used > to check the corresponding request? It is. In the IKEv2 the exchanges are always request-reply pairs, which are identified by the message-id (which is incremented by 1 for each exchange). There is separate request-reply pairs in both directions (separated by the Initiator flag). > And if then the message ID on the responder (to the INFORMATIONAL > exchange) somehow got messed up and does not match what the > requester is expecting? If the message id got messed up, the recipient of that message will throw that message away immediately as it does not fit the message id window, and it will then wait for the other end to retransmit the message with correct message id. If the other end has bug causing the message ids to be messed up in all responses, then the recipient will time out the exchange, and tear down the whole IKEv2 SA, as the other end did not reply to its messages. Note, that IKEv1 handled message id, and exchanges completely differently waythan what IKEv2 does, so do not assume anything is staying same from the IKEv1 to IKEv2. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 7 03:44:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0646028C0F7 for ; Tue, 7 Apr 2009 03:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJmKnIyazjLv for ; Tue, 7 Apr 2009 03:44:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B17553A6DBD for ; Tue, 7 Apr 2009 03:44:53 -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 n37Ajs43005322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 13:45:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n37AjsW7000338; Tue, 7 Apr 2009 13:45:54 +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: <18907.12002.242177.247282@fireball.kivinen.iki.fi> Date: Tue, 7 Apr 2009 13:45:54 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:44:55 -0000 Yoav Nir writes: > I agree with Tero. > > How about replacing this: > The initiator sends SA offer(s) in the SA payload, a nonce in the Ni > payload, optionally a Diffie-Hellman value in the KEi payload, and > the proposed traffic selectors for the proposed Child SA in the TSi > and TSr payloads. > > With this: > The initiator sends SA offer(s) in the SA payload, a nonce in the Ni > payload, optionally a Diffie-Hellman value in the KEi payload, and > the proposed traffic selectors for the proposed Child SA in the TSi > and TSr payloads. The TSi and TSr payloads SHOULD include the > very specifig traffic selectors including the addresses in the packet > triggering the request, as described in section 2.9. That is one change that is needed, but in addition I think we need to say that the TSi and TSr should be the original traffic selectors from the policy, not the already narrowed down ones that the current child SA is using. I.e. if initiator originally offered TSi as 10.0.0.0-10.0.255.255 and included specific packet of 10.0.0.5 TCP port 25 by sending following TSi entries: TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5) (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) and then the responder narrowed it down to per host basic, i.e. returned TSi as: TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) now when the initiator starts to rekey that SA after receiving TCP packet going to that SA (otherwise he would not be rekeying this SA), and lets say the packet is 10.0.0.5 TCP port 80, so he should send TSi when rekeying as follows: TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5) (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) Note, that the second entry is still the whole 10.0.0.0 - 10.0.255.255 range as specified by the policy, not the already narrowed down range of 10.0.0.5 - 10.0.0.5 which the current child SA is using. If the responders policy is still same it will still return same TSi: TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) If the responders policy has been changed so that port host SAs are no longer required it can instead rekey the old SA to have TSi which would cover the new range, i.e. widen up the traffic selectors from what they used to be. If this is not done, then this kind of widening is not possible, meaning that even if the policy is fixed the original more narrow policy is still used. I have seen implementations where the traffic selectors are sent out (and narrowed to) based on the traffic selectors used in the child SA now, not what is specified in the policy. The traffic selectors used in the child SA can always be only more narrow than what is in the policy (if child SA would have more wider traffic selectors than what is allowed by policy it would be violating the policy, and it would be deleted). I would like to have text saying that the original traffic selectors from the policy SHOULD be used. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 7 04:22:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80CB3A6D62 for ; Tue, 7 Apr 2009 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 OphWDulAOBrv for ; Tue, 7 Apr 2009 04:22:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 85D0D3A686E for ; Tue, 7 Apr 2009 04:22:12 -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 n37BNDfL017673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 14:23:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n37BNCmh015302; Tue, 7 Apr 2009 14:23:12 +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: <18907.14240.299436.765385@fireball.kivinen.iki.fi> Date: Tue, 7 Apr 2009 14:23:12 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72F@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72F@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 37 min Cc: IPsecme WG Subject: [IPsec] Issue #80: UDP encapsulation needs to be negotiated X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 11:22:13 -0000 Yaron Sheffer writes: > Herbert: > "Implementations MUST process received UDP-encapsulated ESP packets even > when no NAT was detected." > > was added to the draft. This has the potential to create black holes if > deployed in the field, unless all implementations always use UDP > encapsulation regardless of NAT. I do not think it creates any more black holes than what is generally generated by the broken firewalls in the middle. There is already now black hole generated by IKEv2 implementations doing NAT detection incorrectly, and enabling NAT-T even when no NAT is detected (I have seen such implementation). If you drop all UDP encapsulated ESP packets if no NAT was detected, then this will cause black hole, as you will not receive any of his IPsec packets as you drop them, and he might or might not receive your packets depending whether he requires them to be UDP encapsulated or not. In this implementation I have seen this was not really a problem, as both ends supported MOBIKE, which requires processing both UDP encapsulated and plain IPsec always, thus both ends were able to process packets, but UDP encapsulation was used in one direction but not in other. > The problem is that if a peer behind a firewall (with no NAT) that > only allows inbound packets which are in response to outbound > packets performs UDP encapsulation without NAT, and the remote peer > responds without UDP encapsulation, then all data packets from the > remote peer will be dropped. In normal case this means that the IKE SA will be formed, but no IPsec traffic will go through in either direction. I.e. neither end will enable UDP encapsulation as no NAT is detected, thus both ends will use plain ESP, and those will not go through, so this requirement does not change the situation. Note, that the statemenet added does not say anything that SENDING UDP-encapsulated ESP packets would be required or preferred or even allowed (it is not forbidden either). The text allows easier extensibility as now we know that all ends will be able to process both UDP encapsulated and normal packets always when receiving, so if we later make extensions which enable sending them, we know that it will work with old implementations too. > Looking at this from the point of view of the remote peer, the only > practical solution would be to always employ UDP encapsulation, regardless > of NAT detection. No. There is no way to get IPsec working through that kind of broken firewall. The firewall policy is clearly saying that IPsec is not allowed, thus any way of trying to bypass that policy would be bad... > Now through discussion on the mailing list it appears that this statement > was motivated by a need in MOBIKE to deploy UDP encapsulation when NAT is > not detected. So assuming that we want to cater for this in IPsec, we should > extend IKE to explicitly negotiate UDP encapsulation, rather than having it > rely on the result of NAT detection. Adding full UDP encapsulation negotiation would be too big protocol change to the IKEv2, I do not think we can put it to the current IKEv2bis. It could be added as extension in the future, but I am not sure if such is really needed. Anyways UDP encapsulation negotation with backward compatibility is much simplier if you know that IKEv2 implementations can processes either types of packets always. If you want to force UDP encapsulation, simply fake a NAT on the path (i.e make NAT DETECTION payloads not to match). The new text will allow some cases to work where for some reason two peers do get NAT detection differently. This might be because of bugs (in NAT detection), or because of attacker modifing packets in one direction etc. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 7 05:07:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EF73A6DAD for ; Tue, 7 Apr 2009 05:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 q9YmsAi0vhrf for ; Tue, 7 Apr 2009 05:07:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF993A6D9A for ; Tue, 7 Apr 2009 05:07:34 -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 n37C8cIg010233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Apr 2009 15:08:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n37C8baK013779; Tue, 7 Apr 2009 15:08:37 +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: <18907.16965.839169.415998@fireball.kivinen.iki.fi> Date: Tue, 7 Apr 2009 15:08:37 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 35 min Subject: [IPsec] Issue #28: UDP encapsulation and transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:07:36 -0000 > Ticket #28 (new defect) > > Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP > > Opened 7 months ago > Reported by: kivinen@iki.fi > Owned by: paul.hoffman@vpnc.org > Component: draft-ietf-ipsecme-ikev2bis > > > o Implementations MUST process received UDP-encapsulated ESP > > packets even when no NAT was detected. o The original source and > > destination IP address required for the transport mode TCP and > > UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the > > Traffic Selectors associated with the exchange. In the case of > > NAT traversal, the Traffic Selectors MUST contain exactly one IP > > address, which is then used as the original IP address. > > Getting original source and destination IP address from the traffic > selectors do not really work currently. Especially when combined with > the selectors from the packet and when responder is behind nat or > similar problems. > > Paul: Not done. Specify replacement text and discuss on the mailing list. I wrote a longer description of the whole transport mode NAT-T problem, and also added some text which could be used as parts of the solution to be added to the IKEv2bis. The problem is that currently there is no way of doing transport mode NAT-transport without violating at least one of the following MUSTs in the IKEv2bis document: ikev2bis-02: section 2.9: o If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. and the generic requirement from the same section which in short says responder MUST narrow the traffic selectors to be a subset of initiators traffic selectors (this is said in quite complicated way in IKEv2bis). ikev2bis-02: section 2.23: ... In the case of NAT traversal, the Traffic Selectors MUST contain exactly one IP address, which is then used as the original IP address. RFC4301: section 5.2: ... IPsec MUST perform the following steps: ... 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. The problem with transport mode NAT-traversal and narrowing and SAD entry checks is that two end nodes talking with transport mode cannot work if they have same traffic selectors in both ends. This is because the packet will look like having different IP-addresses depending which end is seeing it, thus there is no way that both parties could agree on any single addresses that would work for both ends. In my following longer text I explain the solution how the transport mode NAT traversal can be made to work. This will be protocol change, but on the other hand it cannot break any existing complient implementations as there was no way to do this before (even when the RFC claimed so): ---------------------------------------------------------------------- Transport mode NAT Traversal ============================ When transport mode is used with NAT Traversal that requires special handling of the traffic selectors used in the IKEv2. The complete scenario is like this: +------+ +------+ +------+ +------+ |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |node |<------>| A |<---------->| B |<------->| | +------+ +------+ +------+ +------+ In this scenario there is two address translating NATs NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming to IPN2 address are mapped to the gateways adddress IP2, i.e IPN2 destination address is mapped to IP2. This allows client to connect server by connecting to the IPN2. NAT B does not necessarely need to be static NAT, but client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, i.e. the IPN2 address. If NAT B is static NAT, then this can be configured to the client's configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of this document. As other scenarios are just simplications of this complex case (i.e. where you can just remove NAT A or NAT B), we do not need to consider them separately. In this scenario both client and server are configured to use transport mode for the traffic originating from the client node and destinationed to the server. When client starts creating IKEv2 SA and Child SA for sending traffic to the server, it has triggering packet with source IP address of IP1, and destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). As this is transport mode it uses exactly same addresses as the Traffic selectors and outer IP address of the IKE packets. For the transport mode it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple traffic selectors if it has for example multiple port ranges it wants to negotiate, but all TSi entries must use IP1-IP1 range as IP address, and all TSr entries must have IPN2-IPN2 range as IP addresses. The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request (see section 2.9). The NAT A will then replace the source address of the IKE packet from IP1 to IPN2 and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same traffic selectors which were sent by the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2. When server receives this packet it normally looks the PAD based on the ID and then searches the SPD based on the traffic selectors. As IP1 does not really tell anything to the server (it is the address client has behind the NAT) it is useless to do lookup based on that if transport mode is used. On the other hand server cannot know whether transport mode is allowed by his policy before he finds the matching SPD entry. In this case it should first check that as initiator requested transport-mode and do address substitution of the traffic selectors. It needs to first store the old traffic selector IP addresses to be used later for the incremental checksum fixup (IP address in the TSi is stored as real source address and IP address in the TSr is storead as real destination address for the RFC 3947 use). After that if the other end was detected to be behind NAT, it replaces the IP-address in TSi payloads with the IP address obtained from the source address of the IKE packet received (i.e. in this case replaces IP1 in TSi with IPN1). If this end was detected to be behind NAT, it replaces the IP-addresses in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (i.e. replaces IPN2 in TSr with IP2). After this address substitution both the traffic selectors and the IKE UDP source/destination addresses look same. After this it does SPD lookup based on those new traffic selectors. If entry is found and it allows transport mode, then it is used. If entry is found but it does not allow transport mode, then MUST undo the address substitution and redo the SPD lookup using the original traffic selectors. If the second lookup succeeds, it will create SA in tunnel mode using real traffic selectors sent by the other end. This address substitution in transport mode is needed so SPD is looked up by using the addresses that will be seen by the local host. This also will make sure the SAD entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. The most common case is that servers SPD contain wildcard entries matching any addresses, but this allows also making different SPD entries for example for different known NATs outer addresses. After the SPD lookup the server will do traffic selector narrowing based on the SPD entry it found. In this it will again use the already substituted traffic selectors, thus it will send back traffic selectors having IPN1 and IP2 as their IP addresses (it can still narrow down the protocol number or port ranges used by the traffic selectors). The SAD entry created for the Child SA will have the addresses as seen by the server, i.e. IPN1 and IP2. When the initiator (client) receives the other ends reply to Child SA it will do similar processing. I.e. if transport mode SA was created, it will store the original returned traffic selectors as real source and destination addresses for the RFC 3947 use. Then it will replace the IP addresses in the traffic selectors with the ones from the IP header of the IKE packet, i.e. it will replace IPN1 with IP1 and IP2 with IPN2. Then it will use those traffic selectors when verifying the SA against sent traffic selectors, and when installing the SAD entry. Specific rules for to be followed for transport mode: Initiator proposing transport mode: - The TSi entries MUST have exactly one IP address, and that MUST match the source address of the IKE SA . - The TSr entries MUST have exactly one IP address, and that MUST match the destination address of the IKE SA. - The first TSi and TSr traffic selectors should SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request (see section 2.9). - There MAY be multiple TSi and TSr entries. - If transport mode for the SA was selected (i.e. responder included USE_TRANSPORT_MODE notification in its reply): - Store original content of traffic selectors as real source and destination address for the RFC 3947 needs. - If other end is behind NAT substitute the IP address in the TSr entries with the remote address of the IKE SA. - If this end is behind NAT substitute the IP address in the TSi entries with the local address of the IKE SA. - Do address substitution before using those traffic selectors for anything else than storing original content of them. This includes verification that traffic selectors were narrowed correctly by other end, creation of the SAD entry etc. Responder when transport mode is proposed by initiator: - Store the original traffic selector IP addresses as real source and destination address for the RFC 3947 needs, and for in case we need to undo address substitution. - If other end is behind NAT substitute the IP address in the TSi entries with the remote address of the IKE SA. - If this end is behind NAT substitute the IP address in the TSr entries with the local address of the IKE SA. - Do PAD and SPD lookup using the ID and substituted traffic selectors. - If no SPD entry was found, or if found SPD entry didn't allow transport mode do following: - Undo the traffic selector substitutions. - Do PAD and SPD lookup again using the ID and original traffic selectors, but also searching for tunnel mode SPD entry (i.e. fall back to tunnel mode). - If transport mode SPD entry was found: - Do normal traffic selection narrowing based on the substituted traffic selectors and SPD entry. Use the resulting traffic selectors when creating SAD entries, and when sending traffic selectors back to the initiator. -- kivinen@iki.fi From yaronf@checkpoint.com Tue Apr 7 05:51:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6113A683F for ; Tue, 7 Apr 2009 05:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 i25wT6qCD-Q5 for ; Tue, 7 Apr 2009 05:51:33 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C61E93A68A8 for ; Tue, 7 Apr 2009 05:51:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 002EB30C002; Tue, 7 Apr 2009 15:52:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 953DA2CC001 for ; Tue, 7 Apr 2009 15:52:37 +0300 (IDT) X-CheckPoint: {49DB49D7-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 n37CqaqO009813 for ; Tue, 7 Apr 2009 15:52:37 +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; Tue, 7 Apr 2009 15:52:36 +0300 From: Yaron Sheffer To: IPsecme WG Date: Tue, 7 Apr 2009 15:52:35 +0300 Thread-Topic: Mark your calendars: ipsecme virtual interim on May 5 Thread-Index: Acm3SdKJeKKa18z1Tey5r51n8Hlp+wANXBZg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBED14@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEC2D@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEC2D@il-ex01.ad.checkpoint.com> 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_001C_01C9B798.DE999950" MIME-Version: 1.0 Subject: Re: [IPsec] Mark your calendars: ipsecme virtual interim on May 5 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:51:37 -0000 ------=_NextPart_000_001C_01C9B798.DE999950 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001D_01C9B798.DE999950" ------=_NextPart_001_001D_01C9B798.DE999950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To clarify: all times are daylight savings time. So it's really 15:00 GMT, but 11:00 EDT, 8:00 PDT etc. Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, April 07, 2009 9:27 To: IPsecme WG Subject: [IPsec] Mark your calendars: ipsecme virtual interim on May 5 Hi, Just a heads up for now: we will have a conference call on Tuesday May 5, 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Let us know if you have any major issues with the time and/or the format. Thanks, Yaron ------=_NextPart_001_001D_01C9B798.DE999950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To clarify: all times are daylight = savings time. So it’s really 15:00 GMT,  but 11:00 EDT, 8:00 PDT = etc.

 

      =       Yaron

 

From: = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf Of Yaron Sheffer
Sent: Tuesday, April 07, = 2009 9:27
To: IPsecme WG
Subject: [IPsec] Mark = your calendars: ipsecme virtual interim on May 5

 

Hi,

 

Just a heads up for now: we will have a conference = call on Tuesday May 5, 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. We are planning on the = same format as the previous time: a VoIP conference bridge and posted slides. = Let us know if you have any major issues with the time and/or the = format.

 

Thanks,

         =    Yaron

------=_NextPart_001_001D_01C9B798.DE999950-- ------=_NextPart_000_001C_01C9B798.DE999950 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwNzEyNTIzNVowIwYJKoZIhvcNAQkEMRYEFK5uznz4u31q oLesGpDNvqLUsWl4MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Yp5SU8AkDH8Z3u/sICaCO1rs4OnTUJasC92lmjf/3QIEPr2LihPWjKDrNwnnyetPdA2WoL8vFBXY yd977rir4Xvdo1wzaLxzLtZw8gLzzjXOcYS59asWsWz2i2pI1Jf/Gs32q0dJbZkHlI2M3d9qvS4r c0p0WdXptr9qPQjE8mOzqgrh7lWqWTO8Ql+vjloZHg4yzrHndVwG+liJJc1IINhI9sylRf8rPHnQ Ew/wSXU99EadesdyY3xXX+gjrptxyxuuJoXeg0f5Cd2Nw0fyBgTW4yZ1NcVAjdIF9NQL8jckPxmZ pYGS4LyhyE2nJB7rT26QtWFmoCOf9qyOkHXf/AAAAAAAAA== ------=_NextPart_000_001C_01C9B798.DE999950-- From ynir@checkpoint.com Tue Apr 7 06:16:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28813A6818 for ; Tue, 7 Apr 2009 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 sfg6fFrtyF7Q for ; Tue, 7 Apr 2009 06:16:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4FE543A6983 for ; Tue, 7 Apr 2009 06:16:00 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4D6E730C002; Tue, 7 Apr 2009 16:17:06 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E56012CC001; Tue, 7 Apr 2009 16:17:05 +0300 (IDT) X-CheckPoint: {49DB4F93-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 n37DH5qO017581; Tue, 7 Apr 2009 16:17:05 +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; Tue, 7 Apr 2009 16:17:04 +0300 From: Yoav Nir To: Tero Kivinen Date: Tue, 7 Apr 2009 16:18:23 +0300 Thread-Topic: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying Thread-Index: Acm3bgnIsWmMBBjBQO2Vg2oUrqrp/AAEi7jg Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13D94@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> <18907.12002.242177.247282@fireball.kivinen.iki.fi> In-Reply-To: <18907.12002.242177.247282@fireball.kivinen.iki.fi> 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: IPsecme WG Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:16:07 -0000 The traffic selectors in the REKEY exchange are not currently specified. If= were designing IKEv2 from scratch, I would be in favor of removing traffic= selectors altogether from REKEY exchanges - I don't think it should be cal= led a "rekey" if you get a totally different SA. This does raise the quest= ion (that has been asked before) of why do we really need REKEY_SA exchange= s as opposed to regular exchanges. As it is, I think the initiator of the rekey (not necessarily the same as t= he initiator of the old SA) should keep the selectors in the old SA, and th= e responder should either accept of reject, but I don't think we need to ca= pitalize the SHOULD. In some implementations, the REKEY is generated because of traffic passing = the IPsec stack when little time remains before the child SA expiration. It= may be much more convenient to rekey with the narrowed selectors rather th= an locating an SPD entry which is a superset of the SPD cache entry that ma= tches this SA. I think the rekey initiator SHOULD propose any superset of the current sele= ctors, which can be the current selectors, or anything that matches its pol= icy. I don't think we should recommend doing one or the other. We can and = should, however, require the responder to not expect the traffic selectors = in a rekey-SA to exactly match those of the current SA. Tero Kivinen wrote: > That is one change that is needed, but in addition I think we=20 > need to say that the TSi and TSr should be the original=20 > traffic selectors from the policy, not the already narrowed=20 > down ones that the current child SA is using. >=20 > I.e. if initiator originally offered TSi as=20 > 10.0.0.0-10.0.255.255 and included specific packet of=20 > 10.0.0.5 TCP port 25 by sending following TSi entries: >=20 > TSi =3D (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) >=20 > and then the responder narrowed it down to per host basic, i.e. > returned TSi as: >=20 > TSi =3D (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) >=20 > now when the initiator starts to rekey that SA after=20 > receiving TCP packet going to that SA (otherwise he would not=20 > be rekeying this SA), and lets say the packet is 10.0.0.5 TCP=20 > port 80, so he should send TSi when rekeying as follows: >=20 > TSi =3D (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) >=20 > Note, that the second entry is still the whole 10.0.0.0 -=20 > 10.0.255.255 range as specified by the policy, not the=20 > already narrowed down range of 10.0.0.5 - 10.0.0.5 which the=20 > current child SA is using. >=20 > If the responders policy is still same it will still return same TSi: >=20 > TSi =3D (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) >=20 >=20 > If the responders policy has been changed so that port host=20 > SAs are no longer required it can instead rekey the old SA to=20 > have TSi which would cover the new range, i.e. widen up the=20 > traffic selectors from what they used to be. >=20 > If this is not done, then this kind of widening is not=20 > possible, meaning that even if the policy is fixed the=20 > original more narrow policy is still used. >=20 > I have seen implementations where the traffic selectors are=20 > sent out (and narrowed to) based on the traffic selectors=20 > used in the child SA now, not what is specified in the=20 > policy. The traffic selectors used in the child SA can always=20 > be only more narrow than what is in the policy (if child SA=20 > would have more wider traffic selectors than what is allowed=20 > by policy it would be violating the policy, and it would be deleted). >=20 > I would like to have text saying that the original traffic=20 > selectors from the policy SHOULD be used.=20 > -- > kivinen@iki.fi Email secured by Check Point From smoonen@us.ibm.com Tue Apr 7 08:12:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6613A6860; Tue, 7 Apr 2009 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 imU9rkCFTWyp; Tue, 7 Apr 2009 08:12:39 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 33E643A6C05; Tue, 7 Apr 2009 08:12:39 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n37FDGOq020473; Tue, 7 Apr 2009 09:13:16 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n37FDYPs076698; Tue, 7 Apr 2009 09:13:41 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n37FDUXM006205; Tue, 7 Apr 2009 09:13:30 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n37FDUN8006202; Tue, 7 Apr 2009 09:13:30 -0600 In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13D94@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> <18907.12002.242177.247282@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361332A13D94@il-ex01.ad.checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: C431A7B8:59C8E936-85257591:0052BDAC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/07/2009 11:13:20 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/07/2009 11:13:20 AM, Serialize complete at 04/07/2009 11:13:20 AM, S/MIME Sign failed at 04/07/2009 11:13:20 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/07/2009 09:13:30, Serialize complete at 04/07/2009 09:13:30 Message-ID: Date: Tue, 7 Apr 2009 11:13:30 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00539E5E85257591_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:12:41 -0000 This is a multipart message in MIME format. --=_alternative 00539E5E85257591_= Content-Type: text/plain; charset="US-ASCII" I agree with Yoav, for two reasons. First, as Yoav suggests, the idea of doing a rekey seems to correspond in principle more closely with holding everything else about the SA constant. Second, by the time you want to rekey a child SA, the notion of referring to the original selectors seems strange and arbitrary. By that time, the original connection that triggered the SA might be gone, and a dozen other connections might be using the SA. In that case, to reuse the original packet selectors when refreshing the SA would obviously be incorrect. I think it is better to recommend that you exactly reuse the existing SA selectors on rekey. True, in case the responder policy has changed, the rekey may fail. (However, one wonders why the policy change didn't cause the existing SA to be deleted.) Nevertheless, if the rekey fails, once the original SA expires, new SA(s) can be negotiated on-demand as needed to serve existing connections. I think this is better than having the illusion of doing a rekey that accommodates policy changes but which might actually not benefit any existing connection at all. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development 1-919-254-1388 (T/L: 444-1388) http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yoav Nir To: Tero Kivinen Cc: IPsecme WG Date: 04/07/2009 09:18 AM Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying The traffic selectors in the REKEY exchange are not currently specified. If were designing IKEv2 from scratch, I would be in favor of removing traffic selectors altogether from REKEY exchanges - I don't think it should be called a "rekey" if you get a totally different SA. This does raise the question (that has been asked before) of why do we really need REKEY_SA exchanges as opposed to regular exchanges. As it is, I think the initiator of the rekey (not necessarily the same as the initiator of the old SA) should keep the selectors in the old SA, and the responder should either accept of reject, but I don't think we need to capitalize the SHOULD. In some implementations, the REKEY is generated because of traffic passing the IPsec stack when little time remains before the child SA expiration. It may be much more convenient to rekey with the narrowed selectors rather than locating an SPD entry which is a superset of the SPD cache entry that matches this SA. I think the rekey initiator SHOULD propose any superset of the current selectors, which can be the current selectors, or anything that matches its policy. I don't think we should recommend doing one or the other. We can and should, however, require the responder to not expect the traffic selectors in a rekey-SA to exactly match those of the current SA. Tero Kivinen wrote: > That is one change that is needed, but in addition I think we > need to say that the TSi and TSr should be the original > traffic selectors from the policy, not the already narrowed > down ones that the current child SA is using. > > I.e. if initiator originally offered TSi as > 10.0.0.0-10.0.255.255 and included specific packet of > 10.0.0.5 TCP port 25 by sending following TSi entries: > > TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) > > and then the responder narrowed it down to per host basic, i.e. > returned TSi as: > > TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) > > now when the initiator starts to rekey that SA after > receiving TCP packet going to that SA (otherwise he would not > be rekeying this SA), and lets say the packet is 10.0.0.5 TCP > port 80, so he should send TSi when rekeying as follows: > > TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5) > (0, 0 - 65535, 10.0.0.0 - 10.0.255.255) > > Note, that the second entry is still the whole 10.0.0.0 - > 10.0.255.255 range as specified by the policy, not the > already narrowed down range of 10.0.0.5 - 10.0.0.5 which the > current child SA is using. > > If the responders policy is still same it will still return same TSi: > > TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5) > > > If the responders policy has been changed so that port host > SAs are no longer required it can instead rekey the old SA to > have TSi which would cover the new range, i.e. widen up the > traffic selectors from what they used to be. > > If this is not done, then this kind of widening is not > possible, meaning that even if the policy is fixed the > original more narrow policy is still used. > > I have seen implementations where the traffic selectors are > sent out (and narrowed to) based on the traffic selectors > used in the child SA now, not what is specified in the > policy. The traffic selectors used in the child SA can always > be only more narrow than what is in the policy (if child SA > would have more wider traffic selectors than what is allowed > by policy it would be violating the policy, and it would be deleted). > > I would like to have text saying that the original traffic > selectors from the policy SHOULD be used. > -- > kivinen@iki.fi Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 00539E5E85257591_= Content-Type: text/html; charset="US-ASCII"
I agree with Yoav, for two reasons.  First, as Yoav suggests, the idea of doing a rekey seems to correspond in principle more closely with holding everything else about the SA constant.  Second, by the time you want to rekey a child SA, the notion of referring to the original selectors seems strange and arbitrary.  By that time, the original connection that triggered the SA might be gone, and a dozen other connections might be using the SA.  In that case, to reuse the original packet selectors when refreshing the SA would obviously be incorrect.

I think it is better to recommend that you exactly reuse the existing SA selectors on rekey.  True, in case the responder policy has changed, the rekey may fail.  (However, one wonders why the policy change didn't cause the existing SA to be deleted.)  Nevertheless, if the rekey fails, once the original SA expires, new SA(s) can be negotiated on-demand as needed to serve existing connections.  I think this is better than having the illusion of doing a rekey that accommodates policy changes but which might actually not benefit any existing connection at all.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Yoav Nir <ynir@checkpoint.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 04/07/2009 09:18 AM
Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying





The traffic selectors in the REKEY exchange are not currently specified. If were designing IKEv2 from scratch, I would be in favor of removing traffic selectors altogether from REKEY exchanges - I don't think it should be called a "rekey" if you get a totally different SA.  This does raise the question (that has been asked before) of why do we really need REKEY_SA exchanges as opposed to regular exchanges.

As it is, I think the initiator of the rekey (not necessarily the same as the initiator of the old SA) should keep the selectors in the old SA, and the responder should either accept of reject, but I don't think we need to capitalize the SHOULD.

In some implementations, the REKEY is generated because of traffic passing the IPsec stack when little time remains before the child SA expiration. It may be much more convenient to rekey with the narrowed selectors rather than locating an SPD entry which is a superset of the SPD cache entry that matches this SA.

I think the rekey initiator SHOULD propose any superset of the current selectors, which can be the current selectors, or anything that matches its policy. I don't think we should recommend doing one or the other.  We can and should, however, require the responder to not expect the traffic selectors in a rekey-SA to exactly match those of the current SA.

Tero Kivinen wrote:
> That is one change that is needed, but in addition I think we
> need to say that the TSi and TSr should be the original
> traffic selectors from the policy, not the already narrowed
> down ones that the current child SA is using.
>
> I.e. if initiator originally offered TSi as
> 10.0.0.0-10.0.255.255 and included specific packet of
> 10.0.0.5 TCP port 25 by sending following TSi entries:
>
> TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5)
>       (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)
>
> and then the responder narrowed it down to per host basic, i.e.
> returned TSi as:
>
> TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)
>
> now when the initiator starts to rekey that SA after
> receiving TCP packet going to that SA (otherwise he would not
> be rekeying this SA), and lets say the packet is 10.0.0.5 TCP
> port 80, so he should send TSi when rekeying as follows:
>
> TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5)
>       (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)
>
> Note, that the second entry is still the whole 10.0.0.0 -
> 10.0.255.255 range as specified by the policy, not the
> already narrowed down range of 10.0.0.5 - 10.0.0.5 which the
> current child SA is using.
>
> If the responders policy is still same it will still return same TSi:
>
> TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)
>
>
> If the responders policy has been changed so that port host
> SAs are no longer required it can instead rekey the old SA to
> have TSi which would cover the new range, i.e. widen up the
> traffic selectors from what they used to be.
>
> If this is not done, then this kind of widening is not
> possible, meaning that even if the policy is fixed the
> original more narrow policy is still used.
>
> I have seen implementations where the traffic selectors are
> sent out (and narrowed to) based on the traffic selectors
> used in the child SA now, not what is specified in the
> policy. The traffic selectors used in the child SA can always
> be only more narrow than what is in the policy (if child SA
> would have more wider traffic selectors than what is allowed
> by policy it would be violating the policy, and it would be deleted).
>
> I would like to have text saying that the original traffic
> selectors from the policy SHOULD be used.
> --
> kivinen@iki.fi

Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 00539E5E85257591_=-- From yaronf@checkpoint.com Tue Apr 7 12:33:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96C43A6D85 for ; Tue, 7 Apr 2009 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 1cKCYzeCpSkz for ; Tue, 7 Apr 2009 12:33:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1BA123A689A for ; Tue, 7 Apr 2009 12:33:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0FB1B30C002; Tue, 7 Apr 2009 22:34:52 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B87662CC001 for ; Tue, 7 Apr 2009 22:34:51 +0300 (IDT) X-CheckPoint: {49DBA818-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 n37JYoqO025818 for ; Tue, 7 Apr 2009 22:34:51 +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; Tue, 7 Apr 2009 22:34:50 +0300 From: Yaron Sheffer To: IPsecme WG Date: Tue, 7 Apr 2009 22:34:49 +0300 Thread-Topic: I-D Action:draft-eronen-ipsec-ikev2-eap-auth-06.txt Thread-Index: Acm3j6cfgJwWM6lYTPC0dVdHo20WMQAIedDQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBED9B@il-ex01.ad.checkpoint.com> 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_0079_01C9B7D1.0F4DBAD0" MIME-Version: 1.0 Subject: [IPsec] FW: I-D Action:draft-eronen-ipsec-ikev2-eap-auth-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:33:48 -0000 ------=_NextPart_000_0079_01C9B7D1.0F4DBAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, We have revived this draft that specifies how to do IKEv2 authentication using EAP only, and no certificates. This can be very useful for mutually authenticating EAP methods, like EAP-AKA (RFC 4187) or our proposed EAP-EKE (http://tools.ietf.org/html/draft-sheffer-emu-eap-eke). At the moment this is an individual draft. Your comments are welcome. Thanks, Yaron -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 07, 2009 10:00 To: i-d-announce@ietf.org Subject: I-D Action:draft-eronen-ipsec-ikev2-eap-auth-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-eronen-ipsec-ikev2-eap-auth-06.txt Pages : 12 Date : 2009-04-06 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0079_01C9B7D1.0F4DBAD0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQwNzE5MzQ0OFowIwYJKoZIhvcNAQkEMRYEFNE8O9Hf8IZx x4BW6kwGJSLcVdWvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA HiJZftgOBcoufZjjc/3X5UJ+5IGH/b6k7LvcAPM5vHQRy59h+Mn4B/69DidOuZtijg6WMMucP+/j TGozaVvHxlwJtlfJNkslReuYK7VU4e9SSBw78qI9mvxIWl77kfpzmAm4xuHEGNY601QvI4ARlo2T tiqAkzgGTxk4jrHmfagzRgKmg/fS8C5wtaZtO3FheXb4tytHYxaE02eIscuiZw8Il2hS2QjyFY75 jqY7genM3jhWpaA+AW4weExDYTVPRpaZjhubtSXOPbJbDNkg61ugEqUKWgvuIw63exN0bliLQ/mo gySol+3C/pZjLVdjMZT2fKifheyGxqfHKCh+FwAAAAAAAA== ------=_NextPart_000_0079_01C9B7D1.0F4DBAD0-- From mcins1@gmail.com Wed Apr 8 01:13:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7763A6867 for ; Wed, 8 Apr 2009 01:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 u4G3+-JJFZLI for ; Wed, 8 Apr 2009 01:13:38 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 110F13A67E6 for ; Wed, 8 Apr 2009 01:13:37 -0700 (PDT) Received: by bwz17 with SMTP id 17so2645225bwz.37 for ; Wed, 08 Apr 2009 01:14:44 -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; bh=gXHTZkbP32n6N11CdNwhkFs/zGIomCKFsbD88ZyItus=; b=qX+Rx6j7SbvGZlYERm4GWJFVABPmKHN9GRkB6yQwdJKaQYRII/GEtPQk53tx46Sf3d O9IjrO3xFKgPW/PZFP+XnKoMwRxFxsNlURYiivEmq2Pz2ad2IWccc/eQ8d9him1gFqrv H1rTTkKLvd3DbGxSAv0jeE/llPLpUriJuUurY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Y6BiLp72hR5y0MJ1konSq1oz05H5PwHfrVYWZ/Zo66cdYnF5xaVggrbnlxLoO3HKg0 Yq2GXNQt/ZZTkN1TKc8wPR6IJBBVO4s1vSzHKk/aNtdcg3NXsmbVs6z0SiTX8esMeA9a xquT8wh5JPXS0lJl6DfcvPKlkv2WEuYG1DIHQ= MIME-Version: 1.0 Received: by 10.204.55.140 with SMTP id u12mr878256bkg.98.1239178484273; Wed, 08 Apr 2009 01:14:44 -0700 (PDT) Date: Wed, 8 Apr 2009 10:14:44 +0200 Message-ID: <99043b4a0904080114l12f05fbatceb9713bb6d3801@mail.gmail.com> From: Matthew Cini Sarreo To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636c924d95e5269046706b9c0 Subject: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:13:39 -0000 --001636c924d95e5269046706b9c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi everyone, As to my understanding, in IKEv2 it is not possible to know "who" the peer is until IKE_AUTH, by using the ID payload for that peer. Let us say that an implementation chooses not to use any automatic configuration but decide (by manual configuration) to accept only a certain Cryptographic Suite. As an example, let us say that after a peer (initiator) sends a message to another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the responder would reply with INVALID_KE_PAYLOAD. The configuration as above would not send a new IKE_SA_INIT message with a corrected D-H group but halt the negotiation. In such a scenario, it might be required to have different D-H groups for different peers. Due to the ID payload being inexistant at this time, is there a way (that is allowed) to identify a peer during IKE_SA_INIT (for example, based on an IP address that has been stored in a configuration file that is known to always be for a certain peer), or are such identification methods (IP-based during IKE_SA_INIT just by checking the IP address source in the IP header of an IKE_SA_INIT message) prohibited? P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and Cookies), par. 2 which states: "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet." But the "identification" for fixed configuration purposes would be before this, as the packet would not be mapped to an SA, but a configuration for the SA resulting my that message would be loaded from configuration. Regards, Matt --001636c924d95e5269046706b9c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone,

As to my understanding, in IKEv2 it is not possible to = know "who" the peer is until IKE_AUTH, by using the ID payload fo= r that peer. Let us say that an implementation chooses not to use any autom= atic configuration but decide (by manual configuration) to accept only a ce= rtain Cryptographic Suite.

As an example, let us say that after a peer (initiator) sends a message= to another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the re= sponder would reply with INVALID_KE_PAYLOAD. The configuration as above wou= ld not send a new IKE_SA_INIT message with a corrected D-H group but halt t= he negotiation.

In such a scenario, it might be required to have different D-H groups f= or different peers. Due to the ID payload being inexistant at this time, is= there a way (that is allowed) to identify a peer during IKE_SA_INIT (for e= xample, based on an IP address that has been stored in a configuration file= that is known to always be for a certain peer), or are such identification= methods (IP-based during IKE_SA_INIT just by checking the IP address sourc= e in the IP header of an IKE_SA_INIT message) prohibited?

P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and C= ookies), par. 2 which states:
"Incoming IKE packets are mapped to a= n IKE SA only using the packet's SPI, not using (for example) the sourc= e IP address of the packet."
But the "identification" for fixed configuration purposes would b= e before this, as the packet would not be mapped to an SA, but a configurat= ion for the SA resulting my that message would be loaded from configuration= .

Regards,
Matt
--001636c924d95e5269046706b9c0-- From smoonen@us.ibm.com Wed Apr 8 04:27:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F71E3A6B24; Wed, 8 Apr 2009 04:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xlOrVWbpKnwx; Wed, 8 Apr 2009 04:27:38 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id EC6513A6B13; Wed, 8 Apr 2009 04:27:37 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n38BQPp5019572; Wed, 8 Apr 2009 05:26:25 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n38BSiZA055736; Wed, 8 Apr 2009 05:28:44 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n38BSi3c027728; Wed, 8 Apr 2009 05:28:44 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n38BSiP8027725; Wed, 8 Apr 2009 05:28:44 -0600 In-Reply-To: <99043b4a0904080114l12f05fbatceb9713bb6d3801@mail.gmail.com> References: <99043b4a0904080114l12f05fbatceb9713bb6d3801@mail.gmail.com> To: Matthew Cini Sarreo MIME-Version: 1.0 X-KeepSent: EAF8B0CF:4DEBC1A3-85257592:003D16A9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/08/2009 07:28:34 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/08/2009 07:28:34 AM, Serialize complete at 04/08/2009 07:28:34 AM, S/MIME Sign failed at 04/08/2009 07:28:34 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/08/2009 05:28:43, Serialize complete at 04/08/2009 05:28:43 Message-ID: Date: Wed, 8 Apr 2009 07:28:43 -0400 Content-Type: multipart/alternative; boundary="=_alternative 003F0A8785257592_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:27:39 -0000 This is a multipart message in MIME format. --=_alternative 003F0A8785257592_= Content-Type: text/plain; charset="US-ASCII" Hi Matt. Because identities are not known until the IKE_AUTH exchange, it is always necessary to do a preliminary PAD lookup (see RFC 4301 for the Peer Authorization Database) based on IP address (and possibly local identity, depending on whether you configure that outside the PAD or discover that from the PAD) and to either verify the PAD entry once the identities are known or else do a subsequent PAD lookup using the final identities. You might have even noticed in the IKE_AUTH exchange, that if the initiator sends the optional IDr payload, the responder is not obligated to use that IDr as its own identity. So even if the initiator has hinted it prefers a certain IDr, it should do a second PAD lookup once it receives the IKE_AUTH response to verify that the negotiated SA conforms to its policy based on the actual IDr. So a compliant implementation will do an initial lookup by IP address just as you describe, followed by a later lookup or verification using the identities. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Matthew Cini Sarreo To: ipsec@ietf.org Date: 04/08/2009 04:16 AM Subject: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer Hi everyone, As to my understanding, in IKEv2 it is not possible to know "who" the peer is until IKE_AUTH, by using the ID payload for that peer. Let us say that an implementation chooses not to use any automatic configuration but decide (by manual configuration) to accept only a certain Cryptographic Suite. As an example, let us say that after a peer (initiator) sends a message to another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the responder would reply with INVALID_KE_PAYLOAD. The configuration as above would not send a new IKE_SA_INIT message with a corrected D-H group but halt the negotiation. In such a scenario, it might be required to have different D-H groups for different peers. Due to the ID payload being inexistant at this time, is there a way (that is allowed) to identify a peer during IKE_SA_INIT (for example, based on an IP address that has been stored in a configuration file that is known to always be for a certain peer), or are such identification methods (IP-based during IKE_SA_INIT just by checking the IP address source in the IP header of an IKE_SA_INIT message) prohibited? P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and Cookies), par. 2 which states: "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet." But the "identification" for fixed configuration purposes would be before this, as the packet would not be mapped to an SA, but a configuration for the SA resulting my that message would be loaded from configuration. Regards, Matt_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 003F0A8785257592_= Content-Type: text/html; charset="US-ASCII"
Hi Matt.  Because identities are not known until the IKE_AUTH exchange, it is always necessary to do a preliminary PAD lookup (see RFC 4301 for the Peer Authorization Database) based on IP address (and possibly local identity, depending on whether you configure that outside the PAD or discover that from the PAD) and to either verify the PAD entry once the identities are known or else do a subsequent PAD lookup using the final identities.  You might have even noticed in the IKE_AUTH exchange, that if the initiator sends the optional IDr payload, the responder is not obligated to use that IDr as its own identity.  So even if the initiator has hinted it prefers a certain IDr, it should do a second PAD lookup once it receives the IKE_AUTH response to verify that the negotiated SA conforms to its policy based on the actual IDr.

So a compliant implementation will do an initial lookup by IP address just as you describe, followed by a later lookup or verification using the identities.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Matthew Cini Sarreo <mcins1@gmail.com>
To: ipsec@ietf.org
Date: 04/08/2009 04:16 AM
Subject: [IPsec] IKEv2: Possibility of "storing" configuration        (Cryptographic Suite) for a certain Peer




Hi everyone,

As to my understanding, in IKEv2 it is not possible to know "who" the peer is until IKE_AUTH, by using the ID payload for that peer. Let us say that an implementation chooses not to use any automatic configuration but decide (by manual configuration) to accept only a certain Cryptographic Suite.

As an example, let us say that after a peer (initiator) sends a message to another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the responder would reply with INVALID_KE_PAYLOAD. The configuration as above would not send a new IKE_SA_INIT message with a corrected D-H group but halt the negotiation.

In such a scenario, it might be required to have different D-H groups for different peers. Due to the ID payload being inexistant at this time, is there a way (that is allowed) to identify a peer during IKE_SA_INIT (for example, based on an IP address that has been stored in a configuration file that is known to always be for a certain peer), or are such identification methods (IP-based during IKE_SA_INIT just by checking the IP address source in the IP header of an IKE_SA_INIT message) prohibited?

P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and Cookies), par. 2 which states:
"Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet."
But the "identification" for fixed configuration purposes would be before this, as the packet would not be mapped to an SA, but a configuration for the SA resulting my that message would be loaded from configuration.

Regards,
Matt_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 003F0A8785257592_=-- From kivinen@iki.fi Wed Apr 8 04:49:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E70B3A6ADE for ; Wed, 8 Apr 2009 04:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 4MpjyoMFOakt for ; Wed, 8 Apr 2009 04:49:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D66B63A69FF for ; Wed, 8 Apr 2009 04:49:12 -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 n38Bo3SY026664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 14:50:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n38Bo2wX007883; Wed, 8 Apr 2009 14:50:02 +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: <18908.36714.727383.932975@fireball.kivinen.iki.fi> Date: Wed, 8 Apr 2009 14:50:02 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13D94@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72B@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A13A3C@il-ex01.ad.checkpoint.com> <18907.12002.242177.247282@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361332A13D94@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 33 min X-Total-Time: 34 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:49:14 -0000 Yoav Nir writes: > The traffic selectors in the REKEY exchange are not currently > specified. If were designing IKEv2 from scratch, I would be in favor > of removing traffic selectors altogether from REKEY exchanges - I > don't think it should be called a "rekey" if you get a totally > different SA. This does raise the question (that has been asked > before) of why do we really need REKEY_SA exchanges as opposed to > regular exchanges. I think the reason for REKEY_SA is to know which SA is being replaced with the one we are creating now. I.e. from where we can move statistics to, and from which SA we should move traffic to this new SA (even before the old SA expires, but after we know other end has also installed the SAs, i.e. after responder sees traffic in the new incoming SA). For example in our implementation rekeyed SA shares same internal SA slot in the engine, i.e. we have one SA slot having two associated crypto contextes and SPIs, and only one of them are in active use. I.e. old one is in use until traffic moves to new one and then later the old ones are removed (but might still be used to decrypt traffic as there might be out of order packets coming in) etc. I.e. it makes implementations easier and more efficient when you know which SA is going to be replaced with the rekey. In IKEv1 you usually tried to do same by inspecting the selectors and tried to guess which one was the old SA being replaced. This is not possible in IKEv2, as it is normal to have multiple overlapping Child SAs with same selectors for different QoS classes. > As it is, I think the initiator of the rekey (not necessarily the > same as the initiator of the old SA) should keep the selectors in > the old SA, and the responder should either accept of reject, but I > don't think we need to capitalize the SHOULD. Responder should do normal narrowing of the selectors, it should not ever reject the selectors. I mean if the selectors initiator offered is superset of the old selectors of the SA, they cannot be against the policy of the responder, thus the responder should either accept wider ones or narrow it down to subset of the offered selectors as normally. > In some implementations, the REKEY is generated because of traffic > passing the IPsec stack when little time remains before the child SA > expiration. It may be much more convenient to rekey with the > narrowed selectors rather than locating an SPD entry which is a > superset of the SPD cache entry that matches this SA. I agree that should be allowed, but in most cases the implementations do have pointers back to the original SPD entry anyways, and in that case they SHOULD use the original selectors from the SPD entry if they are readily available. > I think the rekey initiator SHOULD propose any superset of the > current selectors, which can be the current selectors, or anything > that matches its policy. Yes. > I don't think we should recommend doing one or the other. I would prefer to say "SHOULD" for the selectors from the original SPD entry, but I can accept also the wording saying that either one can be used. > We can and should, however, require the responder to not expect the > traffic selectors in a rekey-SA to exactly match those of the > current SA. Yes, this is something we should at least require (even as MUST). Now that I think more of this I think the initiators proposed selectors MUST always be same or superset of the old SAs selectors. They cannot be narrower than what was used before, as that would normally mean that the policy of the inititor was changed so that old SA is no longer valid with the new policy, which means it should be deleted and new SA created (and this is so rare case, that we do not need to optimize performance for this). Earlier I though we could use rekey in that case too, but I think it is better to say it MUST be same or superset of the currently used selectors. The responder should narrow the offered proposal down to either superset of the current used selectors, or same as currently used selectors. Again it really cannot narrow it down to anything smaller than currently used, as in that it case the current SA is against its policy, and should be deleted. If we go with those rules (i.e. SA can be rekeyed only to superset of the current SA, never to subset), then we actually do NOT need the specific selectors from the packet, as we always know that the subset where we need to narrow it down to, is the one containing the old SAs selectors. So perhaps we should change the resolution to issue #12 (and #11): ---------------------------------------------------------------------- - When initiator proposes traffic selectors when rekeying Child SA, the proposed traffic selectors SHOULD be either superset of the traffic selectors used in the Child SA (i.e. come from the currently active (decorrelated) policy), or same as the traffic selectors currently used. - When responder narrows traffic selectors down when rekeying Child SA, the narrowed traffic selectors SHOULD be either superset of the traffic selectors used in the Child SA, or same as the traffic selectors currently used. - As rekeyed SA can never have narrower scope than currently in use, there is no need for selectors from the packet (section 2.9), so those selectors SHOULD NOT be sent. If the rekeyed SA would ever have narrower scope than currently used SA, that would mean that the policy was changed so that the currently used SAs is against the policy, which means it should have been already deleted after the policy change took effect. ---------------------------------------------------------------------- (Yes, I know, I changed my mind during the process :-) -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 8 06:02:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF713A6813 for ; Wed, 8 Apr 2009 06:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 y8etLCE7L5RO for ; Wed, 8 Apr 2009 06:02:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3DBA23A6ACC for ; Wed, 8 Apr 2009 06:02:01 -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 n38D343D011950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 16:03:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n38D34ia020551; Wed, 8 Apr 2009 16:03:04 +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: <18908.41096.527972.757573@fireball.kivinen.iki.fi> Date: Wed, 8 Apr 2009 16:03:04 +0300 From: Tero Kivinen To: Matthew Cini Sarreo In-Reply-To: <99043b4a0904080114l12f05fbatceb9713bb6d3801@mail.gmail.com> References: <99043b4a0904080114l12f05fbatceb9713bb6d3801@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 17 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 13:02:03 -0000 Matthew Cini Sarreo writes: > In such a scenario, it might be required to have different D-H groups for > different peers. Due to the ID payload being inexistant at this time, is > there a way (that is allowed) to identify a peer during IKE_SA_INIT (for > example, based on an IP address that has been stored in a configuration file > that is known to always be for a certain peer), or are such identification > methods (IP-based during IKE_SA_INIT just by checking the IP address source > in the IP header of an IKE_SA_INIT message) prohibited? Does not really sound like reasonable real world use case, and I would firstly try to convince people that hosts should never ever allow anybody to use too weak cryptographic suites, and if you only allow strong enough ones, then it does not matter which one of those strong enough ones is used. But to your question. Yes, you can select the IKE SA cryptographic algorithms based on the IP address of the request. Actually you can use whatever means you can, including the phase of the moon, but usually only useful thing you have is the IP address of the other end. This of course has the problem that if the other does not have fixed IP-address, then you might have problems (or you end up problems if you have multiple hosts having dynamic IP-addresses and their required policies do not match). If there really is strong requirement that specific host MUST use some cryptographic suite that is not allowed for another host and both of them use dynamic IP-addresses, you can always do so that you do IKE_SA_INIT exchange and then when you see IKE_AUTH message, you know the identity, and then you can verify that your IKE_SA_INIT parameters were correct, and if so continue. If your IKE_SA_INIT parameters were wrong, then you simply store information to your local cache saying that host from this IP address, should use these IKE_SA_INIT parameters next time, and return some fatal error message to IKE_AUTH. When the initiator then retries and sends next IKE_SA_INIT, you can then check your cache, and see that for this IP-address you should use these parameters, and use those and then continue. Then in the IKE_AUTH you again verify that your parameters were correct and continue. > P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and > Cookies), par. 2 which states: > "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, > not using (for example) the source IP address of the packet." > But the "identification" for fixed configuration purposes would be before > this, as the packet would not be mapped to an SA, but a configuration for > the SA resulting my that message would be loaded from configuration. That text means that the source address of the UDP IKE packet does not matter when finding the IKE SA state. When doing lookup to PAD you can use the remote IP address of the peer (RFC 4301, PAD). If PAD contains restrictions that these PAD entries must have remote peer location of IP address XXX, then it is best to first concentrate your searching of the suitable PAD entry for new connection to those PAD entries having matching IP-address. If you only find one PAD entry then you can assume that this will be the one that will be used, and then later in the IKE_AUTH verify that your guess was correct by doing PAD/SPD lookup again using the full information available and check that you get same PAD/SPD entry back. For example in our implementation the configuration can specify that this IPsec connection must have local and/or remote IP as specified in the configuration, and then when new connection comes in we first search entry matching both to the remote and local IP, and if such is found, we guess that is the correct one. If that is not found, we search one having correct remote IP, and if that is not found then we search for having correct local IP, and otherwise use defaults. Later we then verify that the final selected IPsec connection is same than what we guessed earlier (or at least has same parameters for IKE SA). -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Apr 8 10:55:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9BA28C289 for ; Wed, 8 Apr 2009 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 hE+MyPYi4inT for ; Wed, 8 Apr 2009 10:55:04 -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 5BF8B28C284 for ; Wed, 8 Apr 2009 10:55:04 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38Hu73S023962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 10:56:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 8 Apr 2009 10:56:06 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 17:55:05 -0000 Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see . There is disagreement among the authors of the session resumption draft how to deal with this issue. One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a "security consideration" because the issues are more operational than security. A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server. If you have a preference between these two proposal, please state it now. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Wed Apr 8 16:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4E7C93A6BA7; Wed, 8 Apr 2009 16:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090408230001.4E7C93A6BA7@core3.amsl.com> Date: Wed, 8 Apr 2009 16:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-07.txt Pages : 12 Date : 2009-04-08 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-08155109.I-D@ietf.org> --NextPart-- From vijay@wichorus.com Wed Apr 8 16:10:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223DB3A6A8C for ; Wed, 8 Apr 2009 16:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 zE+xNYzKL+EO for ; Wed, 8 Apr 2009 16:10:06 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id CDA7F3A6876 for ; Wed, 8 Apr 2009 16:10:05 -0700 (PDT) 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, 8 Apr 2009 19:11:08 -0400 Message-ID: In-Reply-To: <20090408230001.4E7C93A6BA7@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-07.txt Thread-Index: Acm4njQSFq/w+zc7RkKD5iArlz5kewAAN+SA References: <20090408230001.4E7C93A6BA7@core3.amsl.com> From: "Vijay Devarapalli" To: Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 23:10:08 -0000 There were three changes in version 07. - Specified that if EAP or multiple auth is used, then the redirect can be sent in the last IKE_AUTH response message - Added text in the security considerations that says the redirect mechanism must not result in modifications of PAD entries - Fixed a bug on Payload Length field for the REDIRECT payload Vijay > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, April 08, 2009 4:00 PM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-07.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Redirect Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-07.txt > Pages : 12 > Date : 2009-04-08 >=20 > IKEv2 is a protocol for setting up VPN tunnels from a remote location > to a gateway so that the VPN client can access services in the > network behind the gateway. Currently there is no standard mechanism > specified that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to redirect the VPN client to > attach to another gateway. This document proposes a redirect > mechanism for IKEv2. The proposed mechanism can also be used in > Mobile IPv6 to enable the home agent to redirect the mobile node to > another home agent. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-r > edirect-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From mcins1@gmail.com Thu Apr 9 02:09:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291063A6A02 for ; Thu, 9 Apr 2009 02:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 LB0tmQ6gddW1 for ; Thu, 9 Apr 2009 02:09:26 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id EFC5B3A69B6 for ; Thu, 9 Apr 2009 02:09:25 -0700 (PDT) Received: by bwz17 with SMTP id 17so482176bwz.37 for ; Thu, 09 Apr 2009 02:10:33 -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; bh=KEDAMsvlZ0wTXijZgVp/QUMet3AysjBMYDC/3aiX3cw=; b=DEkKm7hIcIaNIFEciNQqIHxG9J72CMzX+8IPCqCxqfnqvNrc2KRJHMdQov6lazdP8b Vhw4sm0gU3X58CLI+d+oIfBHw0iI7p9Kha+uD9vOvXxJC8zVg/uYDFF+sJA/BV0y0Vv8 4WSWHKghidOUvAs4lg1fOIO/1MmU5Mq3kbYuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NksEh8XIh/NxT2V94K3qgrMh/B5vGyvNle+1toCla3fPiTTzeubdL9x/ix8ojAWvvO OXsAFrCERWGvC1FiwoddlJfOoYq11gHWBG8R/k9yYSmxzDAZ8JNfjPPHIShmJRW2CFrk DaCO0h3GLy8D7Cf62ki8j0q1wdDhCdhCoSRTg= MIME-Version: 1.0 Received: by 10.204.76.129 with SMTP id c1mr2018436bkk.9.1239268232655; Thu, 09 Apr 2009 02:10:32 -0700 (PDT) Date: Thu, 9 Apr 2009 11:10:32 +0200 Message-ID: <99043b4a0904090210q16428bd6q67d0f6b956150a99@mail.gmail.com> From: Matthew Cini Sarreo To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636458d30c9f75d04671b9e5e Subject: [IPsec] Correct use of Child SA SPIs in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 09:09:27 -0000 --001636458d30c9f75d04671b9e5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, When a Child SA is created, each endpoint will create a different SPI for the SA. If I understand correctly, this is called the incoming SPI, i.e the SPI which would be expected to be seen in an incoming ESP or AH packet. Is this correct? When deleting a Child SA, should the initiator (of the INFORMATIONAL exchange containing the Delete payload) state the incoming SPI value, the outgoing (that is, the SPI that the other peer assigned to the Child SA), or both? If both are to be sent (this seems to make most sense), when does a peer recieve the SPI that the other endpoint set for the Child SA? Would both be sent when creating the SA, in a fashion like it is done when creating the IKE SA? Regards, Matt --001636458d30c9f75d04671b9e5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

When a Child SA is created, each endpoint will create a diff= erent SPI for the SA. If I understand correctly, this is called the incomin= g SPI, i.e the SPI which would be expected to be seen in an incoming ESP or= AH packet. Is this correct?

When deleting a Child SA, should the initiator (of the INFORMATIONAL ex= change containing the Delete payload) state the incoming SPI value, the out= going (that is, the SPI that the other peer assigned to the Child SA), or b= oth? If both are to be sent (this seems to make most sense), when does a pe= er recieve the SPI that the other endpoint set for the Child SA? Would both= be sent when creating the SA, in a fashion like it is done when creating t= he IKE SA?

Regards,
Matt
--001636458d30c9f75d04671b9e5e-- From kivinen@iki.fi Thu Apr 9 04:16:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0803A6B6E for ; Thu, 9 Apr 2009 04:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 JDpSIzYq2va4 for ; Thu, 9 Apr 2009 04:16:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E34663A69DB for ; Thu, 9 Apr 2009 04:16:22 -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 n39BHRmn014247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 14:17:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n39BHQgm011731; Thu, 9 Apr 2009 14:17:26 +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: <18909.55622.941180.81915@fireball.kivinen.iki.fi> Date: Thu, 9 Apr 2009 14:17:26 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG Subject: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:16:24 -0000 Paul Hoffman writes: > Greetings again. Tracker issue #98 is the same as the message that > Pasi sent to the mailing list last month; see > . > There is disagreement among the authors of the session resumption > draft how to deal with this issue. > > One proposal is to add text similar to Pasi's to the document in > order to let implementers understand all the things that they might > need to do to prevent damage from a replay attack. If this is the > method chosen, it should probably be as a section in the main body > of the document, not as a "security consideration" because the > issues are more operational than security. > > A different proposal is to get rid of the one-round-trip mode and > have the protocol always take two round trips. This prevents the > attack that Pasi brings up, at a higher cost for the clients and > server. > > If you have a preference between these two proposal, please state it now. This comes back to again to what use the resumption is aimed for (I tried to ask this in meeting, and it seems nobody knows, so it makes it impossible to think whether some optimization in the protocol is needed or not). Anyways, I would prefer to have safer protocol even if it would be one more round trip. It would also make protocol simplier, as we would not need to have separate optional cookie exchange version. So I would vote for 2 round trip version of the protocol. BTW the ticket #98 has wrong component (draft-ietf-ipsecme-ikev2bis), it should have ikev2-resumption instead. Also the ticket component names are not consistent, there is both ikev2bis and draft-ietf-ipsecme-ikev2bis and only the last one of them is used, but all other components ignore the draft-ietf-ipsecme part... -- kivinen@iki.fi From smoonen@us.ibm.com Thu Apr 9 04:43:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96833A6BCC; Thu, 9 Apr 2009 04:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TFtb+ucw0oCe; Thu, 9 Apr 2009 04:43:09 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 9C87A3A6A34; Thu, 9 Apr 2009 04:43:09 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39BdFNu027738; Thu, 9 Apr 2009 05:39:15 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39BiHqS208420; Thu, 9 Apr 2009 05:44:17 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39BiG7x007342; Thu, 9 Apr 2009 05:44:16 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n39BiGdI007339; Thu, 9 Apr 2009 05:44:16 -0600 In-Reply-To: <99043b4a0904090210q16428bd6q67d0f6b956150a99@mail.gmail.com> References: <99043b4a0904090210q16428bd6q67d0f6b956150a99@mail.gmail.com> To: Matthew Cini Sarreo MIME-Version: 1.0 X-KeepSent: FE8B5FA5:59B103E1-85257593:003FF2CC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/09/2009 07:44:04 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/09/2009 07:44:04 AM, Serialize complete at 04/09/2009 07:44:04 AM, S/MIME Sign failed at 04/09/2009 07:44:04 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/09/2009 05:44:16, Serialize complete at 04/09/2009 05:44:16 Message-ID: Date: Thu, 9 Apr 2009 07:44:16 -0400 Content-Type: multipart/alternative; boundary="=_alternative 004075B885257593_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Correct use of Child SA SPIs in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 11:43:10 -0000 This is a multipart message in MIME format. --=_alternative 004075B885257593_= Content-Type: text/plain; charset="US-ASCII" Hi Matt. The relevant texts to read are sections 3.11 of RFC 4306 and sections 5.6 and 5.7 of RFC 4718. In the ikev2bis draft ( http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-02) this information is reflected in sections 1.4.1 and 3.11. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Matthew Cini Sarreo To: ipsec@ietf.org Date: 04/09/2009 05:12 AM Subject: [IPsec] Correct use of Child SA SPIs in IKEv2 Hello, When a Child SA is created, each endpoint will create a different SPI for the SA. If I understand correctly, this is called the incoming SPI, i.e the SPI which would be expected to be seen in an incoming ESP or AH packet. Is this correct? When deleting a Child SA, should the initiator (of the INFORMATIONAL exchange containing the Delete payload) state the incoming SPI value, the outgoing (that is, the SPI that the other peer assigned to the Child SA), or both? If both are to be sent (this seems to make most sense), when does a peer recieve the SPI that the other endpoint set for the Child SA? Would both be sent when creating the SA, in a fashion like it is done when creating the IKE SA? Regards, Matt_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004075B885257593_= Content-Type: text/html; charset="US-ASCII"
Hi Matt.  The relevant texts to read are sections 3.11 of RFC 4306 and sections 5.6 and 5.7 of RFC 4718.

In the ikev2bis draft (http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-02) this information is reflected in sections 1.4.1 and 3.11.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Matthew Cini Sarreo <mcins1@gmail.com>
To: ipsec@ietf.org
Date: 04/09/2009 05:12 AM
Subject: [IPsec]  Correct use of Child SA SPIs in IKEv2




Hello,

When a Child SA is created, each endpoint will create a different SPI for the SA. If I understand correctly, this is called the incoming SPI, i.e the SPI which would be expected to be seen in an incoming ESP or AH packet. Is this correct?

When deleting a Child SA, should the initiator (of the INFORMATIONAL exchange containing the Delete payload) state the incoming SPI value, the outgoing (that is, the SPI that the other peer assigned to the Child SA), or both? If both are to be sent (this seems to make most sense), when does a peer recieve the SPI that the other endpoint set for the Child SA? Would both be sent when creating the SA, in a fashion like it is done when creating the IKE SA?

Regards,
Matt_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004075B885257593_=-- From smoonen@us.ibm.com Thu Apr 9 09:28:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284963A6C65 for ; Thu, 9 Apr 2009 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mxr590qRNhcb for ; Thu, 9 Apr 2009 09:28:26 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 264253A6CA5 for ; Thu, 9 Apr 2009 09:28:26 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39GS0KQ010386 for ; Thu, 9 Apr 2009 10:28:00 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39GTKm4224314 for ; Thu, 9 Apr 2009 10:29:20 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n39GTKhx023979 for ; Thu, 9 Apr 2009 10:29:20 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n39GTKhA023976 for ; Thu, 9 Apr 2009 10:29:20 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: E429BD49:F49A9675-85257593:0058C1DD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/09/2009 12:20:56 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 04/09/2009 12:20:56 PM, Serialize complete at 04/09/2009 12:20:56 PM, S/MIME Sign failed at 04/09/2009 12:20:56 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 04/09/2009 10:29:20, Serialize complete at 04/09/2009 10:29:20 Message-ID: Date: Thu, 9 Apr 2009 12:29:19 -0400 Content-Type: multipart/alternative; boundary="=_alternative 0059CEC985257593_=" Subject: [IPsec] GCM ICV lengths X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 16:28:27 -0000 This is a multipart message in MIME format. --=_alternative 0059CEC985257593_= Content-Type: text/plain; charset="US-ASCII" Can anyone comment on current / best practices with AES-GCM ICV lengths? I note that algorithm identifiers are defined for ICV lengths of 8, 12 and 16 octets. I also see that RFC 4869 defines standard AES-GCM suites using 16-octet ICVs. Are most implementations supporting all three ICV choices or just the 16-octet ICV choice? Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0059CEC985257593_= Content-Type: text/html; charset="US-ASCII"
Can anyone comment on current / best practices with AES-GCM ICV lengths?  I note that algorithm identifiers are defined for ICV lengths of 8, 12 and 16 octets.  I also see that RFC 4869 defines standard AES-GCM suites using 16-octet ICVs.  Are most implementations supporting all three ICV choices or just the 16-octet ICV choice?

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0059CEC985257593_=-- From latten@austin.ibm.com Thu Apr 9 10:10:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1BC3A6A17 for ; Thu, 9 Apr 2009 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 kmoGiDnLU2Dp for ; Thu, 9 Apr 2009 10:10:49 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id BDB0A3A69F7 for ; Thu, 9 Apr 2009 10:10:49 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39H8kiu009316 for ; Thu, 9 Apr 2009 11:08:46 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39HBoi3222900 for ; Thu, 9 Apr 2009 11:11:50 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39HBnVA021127 for ; Thu, 9 Apr 2009 11:11:49 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n39HBn0l021118; Thu, 9 Apr 2009 11:11:49 -0600 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n39HBn0H054172; Thu, 9 Apr 2009 12:11:49 -0500 From: Joy Latten To: Scott C Moonen In-Reply-To: References: Content-Type: text/plain Date: Thu, 09 Apr 2009 12:01:16 -0500 Message-Id: <1239296476.13724.3.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] GCM ICV lengths X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 17:10:50 -0000 On Thu, 2009-04-09 at 12:29 -0400, Scott C Moonen wrote: > > Can anyone comment on current / best practices with AES-GCM ICV > lengths? I note that algorithm identifiers are defined for ICV > lengths of 8, 12 and 16 octets. I also see that RFC 4869 defines > standard AES-GCM suites using 16-octet ICVs. Are most implementations > supporting all three ICV choices or just the 16-octet ICV choice? > I believe Linux kernel supports 8, 12, and 16. regards, Joy From SChew@mocana.com Thu Apr 9 13:18:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FFE3A6827 for ; Thu, 9 Apr 2009 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 1n5wuw2NhRuM for ; Thu, 9 Apr 2009 13:18:03 -0700 (PDT) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) by core3.amsl.com (Postfix) with ESMTP id 239953A6407 for ; Thu, 9 Apr 2009 13:18:03 -0700 (PDT) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Thu, 9 Apr 2009 13:14:38 -0700 From: Soo-Fei Chew To: "ipsec@ietf.org" Date: Thu, 9 Apr 2009 13:14:41 -0700 Thread-Topic: transform id for ESP GMAC for IKEv1 Phase2 Thread-Index: Acm5T9C+tEljDTdgTdOUsSu6UJaLKw== Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551ACEA@yugi.mocana.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:18:07 -0000 --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_ Content-Type: multipart/alternative; boundary="_000_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_" --_000_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID is 21 but i= t doesn't specify for IKEv1. If I use 21 for ikev1, it conflicts with RFC4= 196 section 5.2. Please advise what to put as transform ID for ESP IKEv1. Thanks, SooFei Soo-Fei Chew Senior Engineer Mocana Corporation [cid:image001.jpg@01C9B915.244C1EF0] Securing the Internet of Things Request a free trial of Mocana's software at http://www.mocana.co= m/evaluate.html schew@mocana.com 350 Samsome Street Suite 1010, San Francisco, CA 94105 p +1 415 617 0055 ext. 3011 f +1 415 617 0056 Confidentiality Notice: The information contained in this electronic trans= mission is confidential, and may be protected from disclosure under applica= ble law. This transmission is intended only for the use of the individual = to whom it is addressed. If you are not the addressee, or the employee or = agent responsible for delivering this transmission to the intended recipien= t, please notify us immediately by telephone at the telephone number above,= and destroy this transmission in its entirety. Any use, dissemination, re= view, distribution, disclosure, copying or taking of any action whatsoever = in reliance upon or in connection with the contents of this transmission is= strictly prohibited. --_000_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Per RFC4543, s= ection 9, for ike v2 the ESP Phase 2 transform ID is 21 but it doe= sn’t specify for IKEv1.  If I use 21 for ikev1, it conflicts with RFC4196 section 5.2.

Please advise what to put as transform ID for ESP IKEv1.=

 

Thanks,

SooFei

 

Soo-Fei Chew   
Senior Engineer
Mocana Corporation


Securing the Internet of Things
Request a free trial&nb= sp;of Mocana's software at http://www.mocana.com/evaluate= .html

350 Samsome Street Suite 1010,<= /p>

San Francisco, CA 94105

p +1 415 617 0055 ext. 3011=

f +1 415 617 0056

Confidentiality Notice:  The information contained in this electronic transmission is confidential, and = may be protected from disclosure under applicable law.  This transmission = is intended only for the use of the individual to whom it is addressed.  = If you are not the addressee, or the employee or agent responsible for deliver= ing this transmission to the intended recipient, please notify us immediately b= y telephone at the telephone number above, and destroy this transmission in i= ts entirety.  Any use, dissemination, review, distribution, disclosure, copying or taking of any action whatsoever in reliance upon or in connectio= n with the contents of this transmission is strictly prohibited.

 

--_000_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_-- --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2195; creation-date="Thu, 09 Apr 2009 13:14:37 GMT"; modification-date="Thu, 09 Apr 2009 13:14:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA4AGkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtdV8f ppWq3Fi+ntIYX2hxJjPAPpUMXxEM4zHpEhHr5oA/lXOa/arceMNRL/dSQEj1OBVyz09pwMDao49A K9d0aEYJ21su55/tark0mbTfECRFydGkx7Sg/wAqrH4nx4ONLYntmUf4VUudKaFCynIHX1H4VGvh e2Mf9qazN9is1HI6PL6AD/JqYww32o/mNyrX0Ztan8QI9Nv3tGsGkKKh3CTH3lDenvUUXxEM4zHp EhHr5oA/lUWpanoq6tNbPoEdw6JGWmkYZYFQR2Pb+VTx6Jpmq2/m6XvgdRzbucjHsf8A69Z8tGMF zQfrf/gl81Rt8shW+IEiLk6NJj2lB/lVY/E+PBxpbE9syj/CqtzpDwgkfw9exH4Gud1SzG0zKuGU /NjuPWt6VHDzdnH8WZTq1Y63O41Px+mm3Yt209nzGkgIkx95QfT3qGL4iGcZj0iQj180AfyrnNbt hca6hb7iWsBI9fkFXLLT2nAwAqD8hU+xoKCbWvzKdWq5tJ7G03xAkRcnRpMe0oP8qr/8LOi/6Bj/ APf0f4VUudJaJCwPAGTwc/lVFPCl7q7iSCIQrn55pflTHr7/AIUQp4b7at82DnXvo7np1nP9qsoL jbt82NX25zjIzU1V7GJYNPt4lkEipEqhx0YAdasV5T30O5banmOskf8ACSamO4mGf++RXQaDCZkT bEWXJ3HHH51Q1jX9B0zXboSaIZ7xXw8rMMNwPr7dqSTxdd3SAW3l28JHAiHP516c41JQVo2Vv0OK DhCTu+p1V49jZEyOqySqMhOw9zXBeINRmvzNLcPwEIVey+wqafU5phjceevaue1K9Eg8mNgw6sw7 1eGw7Uia9VSVkbmqFP7buQv3tkO7/v2tb+hzJEEkDYwTkj/PpXJa9dG18TTtjKtHEGHf/VrVuzv2 RQ8T5Vh1FOdJunF9Gl+RNOSjJrzO8voo7+IyW2GlTlkHUivPdSG2KZWGCEIII6GtH+2LpJFkhkKM pyMDpTLnxjp12dmp6PBfMB/rVO0nr7VFGnUg9FdGlScJK17EepENquwYMht4MAdSNgrp9E0yfylk lhMSZyS/GfwrI1fxcNI1FYrTTLdCYY284jLgFQQPwGBVVvEF7e7ZJLppF6jGAPy6UpQqygtLKwRl CE3d9Tsry40+3+bYszqOn8Iri/EGs3eowTJLLthCHEScKPr60T6nLKuM4HcDgVz+o3yuvkxPuz99 h/Kqw+H95E1q11ZHsGk/8gey/wCvdP8A0EVbqppP/IHsv+vdP/QRVuvKluzvjsjm7/wNpepX817c SXHmTNuYK4AHGOOPaoU+HukRnKTXa/SXH9K53WNIE9n4p1Q/axfW+oBbWRJXUxriPO0A45yc10Wh 6dHo3jK+sLFJYrFrGKXYzsy+ZuYEjPfAGa2WIqpW5mZujTfQc3w/0p12vcXjD0Muf6VGfhzopH37 ke+8f4Vp+Lf7Q/4Re/8A7M8z7V5fy+V9/bkbtv8Atbc4965zQDpv/CT2I8LfavsvkP8A2l5nmbOg 2bt//LTd6ds5oWJrL7TD2NPsbF94G0rULtrmd5/MYKDtcAcKFHb0FQp8PdIjzsmu1z12y4/pXQ6l 9q/su6+w4+1eS/k5/v4O39cVxHhf+xBfaX9i/tX+1yh+3Z3/AHtvzefv4+90xznpxQsRVSspMHSg +hsN8P8ASnXa9xeMPQy5/pUZ+HGikECS5HuHHH6V1E/m/Z5PJx5u07M9N2OK8nkOnHS9OKnUj4k+ 2Q/bt3m7s+Yu/f8Aw7PT8KFiay+0w9jT7HcX3gbS9QufPnkuNwRUADgABRgdvaoU+HukRnKTXa/S XH9K6qvNbzTCun67raLdf2lbayRbSCR/kTzEGAucbSGOeOaFiKqVlJjdKD1aOib4f6U67XuLxh6G XP8ASo/+Fc6L/fuf++x/hXWV5rrX9nG917+3jf8A9q+Y39m+V5n+r2jy/K28ZznP60fWay+0xexp 9jqZPEEWlava6EtrLIqiOLziw4zgDjv1H5H0roaxvDFuj+G9InnhVrlLOMeY6fODtGeTyK2awNQo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9k= --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ACEAyugimocanaloc_-- From Black_David@emc.com Fri Apr 10 11:38:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C3E28C10B for ; Fri, 10 Apr 2009 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.33 X-Spam-Level: X-Spam-Status: No, score=-5.33 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 4tQRIsQixAzs for ; Fri, 10 Apr 2009 11:38:47 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7DFD03A6DFB for ; Fri, 10 Apr 2009 11:38:47 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3AIdsV3009870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 14:39:55 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Fri, 10 Apr 2009 14:39:47 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3AIdkCx029212; Fri, 10 Apr 2009 14:39:47 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 14:39:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9BA0B.B8BD19D2" Date: Fri, 10 Apr 2009 14:39:45 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0262201B@CORPUSMX80A.corp.emc.com> In-reply-to: <50DADDE6B33B1B47904E685AAFDC18241A8551ACEA@yugi.mocana.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Thread-Index: Acm5T9C+tEljDTdgTdOUsSu6UJaLKwAu08MQ References: <50DADDE6B33B1B47904E685AAFDC18241A8551ACEA@yugi.mocana.local> To: , X-OriginalArrivalTime: 10 Apr 2009 18:39:46.0422 (UTC) FILETIME=[B8C6E960:01C9BA0B] X-EMM-EM: Active Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:38:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BA0B.B8BD19D2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9BA0B.B8BD19D2" ------_=_NextPart_002_01C9BA0B.B8BD19D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmm - the IKEv1 (actually ISAKMP) and IKEv2 encryption algorithm registries appear to have diverged, starting with the value 21 (e.g., Camellia in CBC mode has different values in the two registries). =20 The current answer for GMAC usage in IKEv1 appears to be "Not Supported". In order to change this, IANA would need to be directed to allocate a new value in the appropriate ISAKMP registry. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei Chew Sent: Thursday, April 09, 2009 4:15 PM To: ipsec@ietf.org Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 =09 =09 Hi =20 Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID is 21 but it doesn't specify for IKEv1. If I use 21 for ikev1, it conflicts with RFC4196 section 5.2. Please advise what to put as transform ID for ESP IKEv1. =20 Thanks, SooFei =20 Soo-Fei Chew =20 Senior Engineer Mocana Corporation =20 =09 Securing the Internet of Things Request a free trial of Mocana's software at =20 http://www.mocana.com/evaluate.html=20 schew@mocana.com 350 Samsome Street Suite 1010, San Francisco, CA 94105 p +1 415 617 0055 ext. 3011 f +1 415 617 0056 =09 Confidentiality Notice: The information contained in this electronic transmission is confidential, and may be protected from disclosure under applicable law. This transmission is intended only for the use of the individual to whom it is addressed. If you are not the addressee, or the employee or agent responsible for delivering this transmission to the intended recipient, please notify us immediately by telephone at the telephone number above, and destroy this transmission in its entirety. Any use, dissemination, review, distribution, disclosure, copying or taking of any action whatsoever in reliance upon or in connection with the contents of this transmission is strictly prohibited. =20 ------_=_NextPart_002_01C9BA0B.B8BD19D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hmm - the=20 IKEv1 (actually ISAKMP) and IKEv2 encryption
with the=20 value 21 (e.g., Camellia in CBC mode has
different=20 values in the two registries).
 
The current=20 answer for GMAC usage in IKEv1 appears to
be=20 "Not Supported".  In order to change this, = IANA
would need=20 to be directed to allocate a new = value=20 in
the appropriate ISAKMP = registry.

Thanks,
--David

------------------------------------------= ----------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 293-7953           = ; =20 FAX: +1 (508)=20 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 394-7754
----------------------------------------------------

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei=20 Chew
Sent: Thursday, April 09, 2009 4:15 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] transform id for ESP GMAC = for IKEv1=20 Phase2

Hi

 

Per RFC4543,=20 section 9, for ike v2 the ESP Phase = 2=20 transform ID is 21 but it doesn’t specify for IKEv1.  If I = use 21 for=20 ikev1, it conflicts with RFC4196=20 section 5.2.

Please advise what to = put as=20 transform ID for ESP IKEv1.

 

Thanks,

SooFei

 

Soo-Fei=20 Chew   
Senior Engineer
Mocana = Corporation


Securing = the Internet of=20 Things
Request a free=20 trial of Mocana's software at http://www.mocana.com/evalua= te.html=20

schew@mocana.com<= /o:p>

350 Samsome Street Suite=20 1010,

San Francisco, CA=20 94105

p +1 = 415 617 0055 ext.=20 3011

f +1 415 617 = 0056

Confidentiality Notice: =  The=20 information contained in this electronic transmission is confidential, = and may=20 be protected from disclosure under applicable law.  This = transmission is=20 intended only for the use of the individual to whom it is addressed. =  If=20 you are not the addressee, or the employee or agent responsible for = delivering=20 this transmission to the intended recipient, please notify us = immediately by=20 telephone at the telephone number above, and destroy this transmission = in its=20 entirety.  Any use, dissemination, review, distribution, = disclosure,=20 copying or taking of any action whatsoever in reliance upon or in = connection=20 with the contents of this transmission is strictly=20 prohibited.

 

------_=_NextPart_002_01C9BA0B.B8BD19D2-- ------_=_NextPart_001_01C9BA0B.B8BD19D2 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <820293518@10042009-09D7> Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA4AGkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtdV8f ppWq3Fi+ntIYX2hxJjPAPpUMXxEM4zHpEhHr5oA/lXOa/arceMNRL/dSQEj1OBVyz09pwMDao49A K9d0aEYJ21su55/tark0mbTfECRFydGkx7Sg/wAqrH4nx4ONLYntmUf4VUudKaFCynIHX1H4VGvh e2Mf9qazN9is1HI6PL6AD/JqYww32o/mNyrX0Ztan8QI9Nv3tGsGkKKh3CTH3lDenvUUXxEM4zHp EhHr5oA/lUWpanoq6tNbPoEdw6JGWmkYZYFQR2Pb+VTx6Jpmq2/m6XvgdRzbucjHsf8A69Z8tGMF zQfrf/gl81Rt8shW+IEiLk6NJj2lB/lVY/E+PBxpbE9syj/CqtzpDwgkfw9exH4Gud1SzG0zKuGU /NjuPWt6VHDzdnH8WZTq1Y63O41Px+mm3Yt209nzGkgIkx95QfT3qGL4iGcZj0iQj180AfyrnNbt hca6hb7iWsBI9fkFXLLT2nAwAqD8hU+xoKCbWvzKdWq5tJ7G03xAkRcnRpMe0oP8qr/8LOi/6Bj/ APf0f4VUudJaJCwPAGTwc/lVFPCl7q7iSCIQrn55pflTHr7/AIUQp4b7at82DnXvo7np1nP9qsoL jbt82NX25zjIzU1V7GJYNPt4lkEipEqhx0YAdasV5T30O5banmOskf8ACSamO4mGf++RXQaDCZkT bEWXJ3HHH51Q1jX9B0zXboSaIZ7xXw8rMMNwPr7dqSTxdd3SAW3l28JHAiHP516c41JQVo2Vv0OK DhCTu+p1V49jZEyOqySqMhOw9zXBeINRmvzNLcPwEIVey+wqafU5phjceevaue1K9Eg8mNgw6sw7 1eGw7Uia9VSVkbmqFP7buQv3tkO7/v2tb+hzJEEkDYwTkj/PpXJa9dG18TTtjKtHEGHf/VrVuzv2 RQ8T5Vh1FOdJunF9Gl+RNOSjJrzO8voo7+IyW2GlTlkHUivPdSG2KZWGCEIII6GtH+2LpJFkhkKM pyMDpTLnxjp12dmp6PBfMB/rVO0nr7VFGnUg9FdGlScJK17EepENquwYMht4MAdSNgrp9E0yfylk lhMSZyS/GfwrI1fxcNI1FYrTTLdCYY284jLgFQQPwGBVVvEF7e7ZJLppF6jGAPy6UpQqygtLKwRl CE3d9Tsry40+3+bYszqOn8Iri/EGs3eowTJLLthCHEScKPr60T6nLKuM4HcDgVz+o3yuvkxPuz99 h/Kqw+H95E1q11ZHsGk/8gey/wCvdP8A0EVbqppP/IHsv+vdP/QRVuvKluzvjsjm7/wNpepX817c SXHmTNuYK4AHGOOPaoU+HukRnKTXa/SXH9K53WNIE9n4p1Q/axfW+oBbWRJXUxriPO0A45yc10Wh 6dHo3jK+sLFJYrFrGKXYzsy+ZuYEjPfAGa2WIqpW5mZujTfQc3w/0p12vcXjD0Muf6VGfhzopH37 ke+8f4Vp+Lf7Q/4Re/8A7M8z7V5fy+V9/bkbtv8Atbc4965zQDpv/CT2I8LfavsvkP8A2l5nmbOg 2bt//LTd6ds5oWJrL7TD2NPsbF94G0rULtrmd5/MYKDtcAcKFHb0FQp8PdIjzsmu1z12y4/pXQ6l 9q/su6+w4+1eS/k5/v4O39cVxHhf+xBfaX9i/tX+1yh+3Z3/AHtvzefv4+90xznpxQsRVSspMHSg +hsN8P8ASnXa9xeMPQy5/pUZ+HGikECS5HuHHH6V1E/m/Z5PJx5u07M9N2OK8nkOnHS9OKnUj4k+ 2Q/bt3m7s+Yu/f8Aw7PT8KFiay+0w9jT7HcX3gbS9QufPnkuNwRUADgABRgdvaoU+HukRnKTXa/S XH9K6qvNbzTCun67raLdf2lbayRbSCR/kTzEGAucbSGOeOaFiKqVlJjdKD1aOib4f6U67XuLxh6G XP8ASo/+Fc6L/fuf++x/hXWV5rrX9nG917+3jf8A9q+Y39m+V5n+r2jy/K28ZznP60fWay+0xexp 9jqZPEEWlava6EtrLIqiOLziw4zgDjv1H5H0roaxvDFuj+G9InnhVrlLOMeY6fODtGeTyK2awNQo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9k= ------_=_NextPart_001_01C9BA0B.B8BD19D2-- From SChew@mocana.com Fri Apr 10 12:14:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36943A68A8 for ; Fri, 10 Apr 2009 12:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.036 X-Spam-Level: X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 3416ILyVJkqA for ; Fri, 10 Apr 2009 12:14:01 -0700 (PDT) Received: from email.mocana.com (email.mocana.com [67.102.231.118]) by core3.amsl.com (Postfix) with ESMTP id A3F1F3A6981 for ; Fri, 10 Apr 2009 12:14:00 -0700 (PDT) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Fri, 10 Apr 2009 12:10:36 -0700 From: Soo-Fei Chew To: "ipsec@ietf.org" Date: Fri, 10 Apr 2009 12:10:37 -0700 Thread-Topic: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Thread-Index: Acm5T9C+tEljDTdgTdOUsSu6UJaLKwAu08MQAAEu2IA= Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551ADA3@yugi.mocana.local> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A0262201B@CORPUSMX80A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:14:04 -0000 --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_ Content-Type: multipart/alternative; boundary="_000_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_" --_000_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi If AES-GMAC is 'Not Supported" in IKEv1, then in RFC4869 3.3. Suite "Suite-B-GMAC-128" ...................................4 3.4. Suite "Suite-B-GMAC-256" ...................................5 The mentioning of IKEv1 is not applicable at all! Thanks, SooFei ________________________________ From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, April 10, 2009 11:40 AM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Hmm - the IKEv1 (actually ISAKMP) and IKEv2 encryption algorithm registries appear to have diverged, starting with the value 21 (e.g., Camellia in CBC mode has different values in the two registries). The current answer for GMAC usage in IKEv1 appears to be "Not Supported". In order to change this, IANA would need to be directed to allocate a new value in the appropriate ISAKMP registry. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= oo-Fei Chew Sent: Thursday, April 09, 2009 4:15 PM To: ipsec@ietf.org Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Hi Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID is 21 but i= t doesn't specify for IKEv1. If I use 21 for ikev1, it conflicts with RFC4= 196 section 5.2. Please advise what to put as transform ID for ESP IKEv1. Thanks, SooFei Soo-Fei Chew Senior Engineer Mocana Corporation [cid:image001.jpg@01C9B9D5.5B958CF0] Securing the Internet of Things Request a free trial of Mocana's software at http://www.mocana.co= m/evaluate.html schew@mocana.com 350 Samsome Street Suite 1010, San Francisco, CA 94105 p +1 415 617 0055 ext. 3011 f +1 415 617 0056 Confidentiality Notice: The information contained in this electronic trans= mission is confidential, and may be protected from disclosure under applica= ble law. This transmission is intended only for the use of the individual = to whom it is addressed. If you are not the addressee, or the employee or = agent responsible for delivering this transmission to the intended recipien= t, please notify us immediately by telephone at the telephone number above,= and destroy this transmission in its entirety. Any use, dissemination, re= view, distribution, disclosure, copying or taking of any action whatsoever = in reliance upon or in connection with the contents of this transmission is= strictly prohibited. --_000_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi<= /font>

 

If AES-GMAC is 'Not Supported" in IKEv1, then in RFC4869

 

   &nbs= p;  3.3. Suite "Suite-B-GMAC-128" ...................................4

   &nbs= p;  3.4. Suite "Suite-B-GMAC-256" ...................................5

 

The mentioning of IKEv1 is not applicable at all= !

 

Thanks,

SooFei

 

From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, April 10, 2009= 11:40 AM
To: Soo-Fei Chew; ipsec@ietf= .org
Subject: RE: [IPsec] transfo= rm id for ESP GMAC for IKEv1 Phase2

 

Hmm - the IKEv1 (actually ISAKMP) and IKEv2 encryption

algorithm registries appear to have diverged, starting

with the value 21 (e.g., Camellia in CBC mode ha= s

different values in the two registries).<= /font>

 

The current answer for GMAC usage in IKEv1 appea= rs to

be "Not Supported".  In order to change this, IANA

would need to be directed to allocate a new valu= e in

the appropriate ISAKMP registry.

Thanks,
--David

----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953           &= nbsp; FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (9= 78) 394-7754
----------------------------------------------------

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei Chew
Sent: Thursday, April 09, 20= 09 4:15 PM
To: ipsec@ietf.org
Subject: [IPsec] transform i= d for ESP GMAC for IKEv1 Phase2

Hi

 

Per RFC4543, s= ection 9, for ike v2 the ESP Phase 2 transform ID is 21 but it doe= sn’t specify for IKEv1.  If I use 21 for ikev1, it conflicts with RFC4196 section 5.2.

Please advise what to put as transform ID for ESP IKEv1.=

 

Thanks,

SooFei

 

Soo-Fei Chew   
Senior Engineer
Mocana Corporation


Securing the Internet of Things
Request a free trial&nb= sp;of Mocana's software at http://www.mocana.com/evaluate= .html

350 Samsome Street Suite 1010,<= /p>

San Francisco, CA 94105

p +1 415 617 0055 ext. 3011=

f +1 415 617 0056

Confidentiality Notice:  The information contained in this electronic transmission is confidential, and may be prote= cted from disclosure under applicable law.  This transmission is intended o= nly for the use of the individual to whom it is addressed.  If you are not= the addressee, or the employee or agent responsible for delivering this transmission to the intended recipient, please notify us immediately by telephone at the telephone number above, and destroy this transmission in i= ts entirety.  Any use, dissemination, review, distribution, disclosure, copying or taking of any action whatsoever in reliance upon or in connectio= n with the contents of this transmission is strictly prohibited.

 

--_000_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_-- --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2195; creation-date="Fri, 10 Apr 2009 12:10:35 GMT"; modification-date="Fri, 10 Apr 2009 12:10:35 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA4AGkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtdV8f ppWq3Fi+ntIYX2hxJjPAPpUMXxEM4zHpEhHr5oA/lXOa/arceMNRL/dSQEj1OBVyz09pwMDao49A K9d0aEYJ21su55/tark0mbTfECRFydGkx7Sg/wAqrH4nx4ONLYntmUf4VUudKaFCynIHX1H4VGvh e2Mf9qazN9is1HI6PL6AD/JqYww32o/mNyrX0Ztan8QI9Nv3tGsGkKKh3CTH3lDenvUUXxEM4zHp EhHr5oA/lUWpanoq6tNbPoEdw6JGWmkYZYFQR2Pb+VTx6Jpmq2/m6XvgdRzbucjHsf8A69Z8tGMF zQfrf/gl81Rt8shW+IEiLk6NJj2lB/lVY/E+PBxpbE9syj/CqtzpDwgkfw9exH4Gud1SzG0zKuGU /NjuPWt6VHDzdnH8WZTq1Y63O41Px+mm3Yt209nzGkgIkx95QfT3qGL4iGcZj0iQj180AfyrnNbt hca6hb7iWsBI9fkFXLLT2nAwAqD8hU+xoKCbWvzKdWq5tJ7G03xAkRcnRpMe0oP8qr/8LOi/6Bj/ APf0f4VUudJaJCwPAGTwc/lVFPCl7q7iSCIQrn55pflTHr7/AIUQp4b7at82DnXvo7np1nP9qsoL jbt82NX25zjIzU1V7GJYNPt4lkEipEqhx0YAdasV5T30O5banmOskf8ACSamO4mGf++RXQaDCZkT bEWXJ3HHH51Q1jX9B0zXboSaIZ7xXw8rMMNwPr7dqSTxdd3SAW3l28JHAiHP516c41JQVo2Vv0OK DhCTu+p1V49jZEyOqySqMhOw9zXBeINRmvzNLcPwEIVey+wqafU5phjceevaue1K9Eg8mNgw6sw7 1eGw7Uia9VSVkbmqFP7buQv3tkO7/v2tb+hzJEEkDYwTkj/PpXJa9dG18TTtjKtHEGHf/VrVuzv2 RQ8T5Vh1FOdJunF9Gl+RNOSjJrzO8voo7+IyW2GlTlkHUivPdSG2KZWGCEIII6GtH+2LpJFkhkKM pyMDpTLnxjp12dmp6PBfMB/rVO0nr7VFGnUg9FdGlScJK17EepENquwYMht4MAdSNgrp9E0yfylk lhMSZyS/GfwrI1fxcNI1FYrTTLdCYY284jLgFQQPwGBVVvEF7e7ZJLppF6jGAPy6UpQqygtLKwRl CE3d9Tsry40+3+bYszqOn8Iri/EGs3eowTJLLthCHEScKPr60T6nLKuM4HcDgVz+o3yuvkxPuz99 h/Kqw+H95E1q11ZHsGk/8gey/wCvdP8A0EVbqppP/IHsv+vdP/QRVuvKluzvjsjm7/wNpepX817c SXHmTNuYK4AHGOOPaoU+HukRnKTXa/SXH9K53WNIE9n4p1Q/axfW+oBbWRJXUxriPO0A45yc10Wh 6dHo3jK+sLFJYrFrGKXYzsy+ZuYEjPfAGa2WIqpW5mZujTfQc3w/0p12vcXjD0Muf6VGfhzopH37 ke+8f4Vp+Lf7Q/4Re/8A7M8z7V5fy+V9/bkbtv8Atbc4965zQDpv/CT2I8LfavsvkP8A2l5nmbOg 2bt//LTd6ds5oWJrL7TD2NPsbF94G0rULtrmd5/MYKDtcAcKFHb0FQp8PdIjzsmu1z12y4/pXQ6l 9q/su6+w4+1eS/k5/v4O39cVxHhf+xBfaX9i/tX+1yh+3Z3/AHtvzefv4+90xznpxQsRVSspMHSg +hsN8P8ASnXa9xeMPQy5/pUZ+HGikECS5HuHHH6V1E/m/Z5PJx5u07M9N2OK8nkOnHS9OKnUj4k+ 2Q/bt3m7s+Yu/f8Aw7PT8KFiay+0w9jT7HcX3gbS9QufPnkuNwRUADgABRgdvaoU+HukRnKTXa/S XH9K6qvNbzTCun67raLdf2lbayRbSCR/kTzEGAucbSGOeOaFiKqVlJjdKD1aOib4f6U67XuLxh6G XP8ASo/+Fc6L/fuf++x/hXWV5rrX9nG917+3jf8A9q+Y39m+V5n+r2jy/K28ZznP60fWay+0xexp 9jqZPEEWlava6EtrLIqiOLziw4zgDjv1H5H0roaxvDFuj+G9InnhVrlLOMeY6fODtGeTyK2awNQo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9k= --_004_50DADDE6B33B1B47904E685AAFDC18241A8551ADA3yugimocanaloc_-- From Black_David@emc.com Fri Apr 10 13:43:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE323A68FF for ; Fri, 10 Apr 2009 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.282 X-Spam-Level: X-Spam-Status: No, score=-5.282 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 taV2S97KtMvZ for ; Fri, 10 Apr 2009 13:43:12 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B3B853A680C for ; Fri, 10 Apr 2009 13:43:11 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3AKiIWb012914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 16:44:18 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Fri, 10 Apr 2009 16:44:12 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3AKiB8b006154; Fri, 10 Apr 2009 16:44:11 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 16:44:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9BA1D.1A167D68" Date: Fri, 10 Apr 2009 16:44:10 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A026220A2@CORPUSMX80A.corp.emc.com> In-reply-to: <50DADDE6B33B1B47904E685AAFDC18241A8551ADA3@yugi.mocana.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Thread-Index: Acm5T9C+tEljDTdgTdOUsSu6UJaLKwAu08MQAAEu2IAAAzBjcA== References: <9FA859626025B64FBC2AF149D97C944A0262201B@CORPUSMX80A.corp.emc.com> <50DADDE6B33B1B47904E685AAFDC18241A8551ADA3@yugi.mocana.local> To: , X-OriginalArrivalTime: 10 Apr 2009 20:44:11.0158 (UTC) FILETIME=[1A1B3B60:01C9BA1D] X-EMM-EM: Active Cc: pasi.eronen@nokia.com Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 20:43:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BA1D.1A167D68 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9BA1D.1A167D68" ------_=_NextPart_002_01C9BA1D.1A167D68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That looks like an oversight at least wrt RFC 4869. =20 Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to allocate this value, or is there a lower overhead and faster means of getting this done? Thanks, --David =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei Chew Sent: Friday, April 10, 2009 3:11 PM To: ipsec@ietf.org Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 =09 =09 Hi =20 If AES-GMAC is 'Not Supported" in IKEv1, then in RFC4869 =20 3.3. Suite "Suite-B-GMAC-128" ...................................4 3.4. Suite "Suite-B-GMAC-256" ...................................5 =20 The mentioning of IKEv1 is not applicable at all! =20 Thanks, SooFei =20 =09 ________________________________ From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Friday, April 10, 2009 11:40 AM To: Soo-Fei Chew; ipsec@ietf.org Subject: RE: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 =20 Hmm - the IKEv1 (actually ISAKMP) and IKEv2 encryption algorithm registries appear to have diverged, starting with the value 21 (e.g., Camellia in CBC mode has different values in the two registries). =20 The current answer for GMAC usage in IKEv1 appears to be "Not Supported". In order to change this, IANA would need to be directed to allocate a new value in the appropriate ISAKMP registry. Thanks, --David =09 ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- =09 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei Chew Sent: Thursday, April 09, 2009 4:15 PM To: ipsec@ietf.org Subject: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 Hi =20 Per RFC4543, section 9, for ike v2 the ESP Phase 2 transform ID is 21 but it doesn't specify for IKEv1. If I use 21 for ikev1, it conflicts with RFC4196 section 5.2. Please advise what to put as transform ID for ESP IKEv1. =20 Thanks, SooFei =20 Soo-Fei Chew =20 Senior Engineer Mocana Corporation =20 =09 Securing the Internet of Things Request a free trial of Mocana's software at =20 http://www.mocana.com/evaluate.html=20 schew@mocana.com 350 Samsome Street Suite 1010, San Francisco, CA 94105 p +1 415 617 0055 ext. 3011 f +1 415 617 0056 =09 Confidentiality Notice: The information contained in this electronic transmission is confidential, and may be protected from disclosure under applicable law. This transmission is intended only for the use of the individual to whom it is addressed. If you are not the addressee, or the employee or agent responsible for delivering this transmission to the intended recipient, please notify us immediately by telephone at the telephone number above, and destroy this transmission in its entirety. Any use, dissemination, review, distribution, disclosure, copying or taking of any action whatsoever in reliance upon or in connection with the contents of this transmission is strictly prohibited. =20 ------_=_NextPart_002_01C9BA1D.1A167D68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That looks=20 like an oversight at least wrt RFC 4869.
 
Chairs (of=20 ipsecme) and Pasi (AD) - is a new RFC needed to
allocate=20 this value, or is there = a lower=20 overhead and faster
means of=20 getting this done?

Thanks,
--David

 

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei=20 Chew
Sent: Friday, April 10, 2009 3:11 PM
To:=20 ipsec@ietf.org
Subject: Re: [IPsec] transform id for ESP = GMAC for=20 IKEv1 Phase2

Hi

 

If AES-GMAC is = 'Not=20 Supported" in IKEv1, then in RFC4869

 

     =20 3.3. Suite "Suite-B-GMAC-128"=20 ...................................4

     =20 3.4. Suite "Suite-B-GMAC-256"=20 ...................................5

 

The mentioning = of IKEv1 is=20 not applicable at all!

 

Thanks,

SooFei

 

From:=20 Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, April 10, 2009 = 11:40=20 AM
To: Soo-Fei = Chew;=20 ipsec@ietf.org
Subject: RE:=20 [IPsec] transform id for ESP GMAC for IKEv1=20 Phase2

 

Hmm - the IKEv1 = (actually=20 ISAKMP) and IKEv2 encryption

algorithm = registries=20 appear to have diverged, starting

with the value = 21 (e.g.,=20 Camellia in CBC mode has

different values = in the=20 two registries).

 

The current = answer for=20 GMAC usage in IKEv1 appears to

be "Not = Supported". =20 In order to change this, IANA

would need to be = directed=20 to allocate a new value in

the appropriate = ISAKMP=20 registry.

Thanks,
--David

-----------------------------------------= -----------
David=20 L. Black, Distinguished Engineer
EMC Corporation, 176 South St., = Hopkinton,=20 MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508)=20 = 293-7786
black_david@emc.com       = =20 Mobile: +1 (978)=20 = 394-7754
----------------------------------------------------

From:=20 ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Soo-Fei = Chew
Sent: Thursday, April 09, = 2009 4:15=20 PM
To:=20 ipsec@ietf.org
Subject:=20 [IPsec] transform id for ESP GMAC for IKEv1=20 Phase2

Hi

 

Per = RFC4543,=20 section 9, for ike v2 the ESP = Phase 2=20 transform ID is 21 but it doesn’t specify for IKEv1.  If = I use 21 for=20 ikev1, it conflicts with RFC4196=20 section 5.2.

Please advise what to = put as=20 transform ID for ESP IKEv1.

 

Thanks,

SooFei

 

Soo-Fei=20 Chew   
Senior Engineer
Mocana = Corporation


Securing = the Internet of=20 Things
Request a free=20 trial of Mocana's software = at http://www.mocana.com/evalua= te.html=20

schew@mocana.com<= /o:p>

350 Samsome Street = Suite=20 1010,

San Francisco, CA=20 94105

p +1 = 415 617 0055 ext.=20 3011

f +1 415 617 = 0056

Confidentiality Notice: =  The=20 information contained in this electronic transmission is = confidential, and=20 may be protected from disclosure under applicable law.  This=20 transmission is intended only for the use of the individual to whom = it is=20 addressed.  If you are not the addressee, or the employee or = agent=20 responsible for delivering this transmission to the intended = recipient,=20 please notify us immediately by telephone at the telephone number = above, and=20 destroy this transmission in its entirety.  Any use, = dissemination,=20 review, distribution, disclosure, copying or taking of any action = whatsoever=20 in reliance upon or in connection with the contents of this = transmission is=20 strictly prohibited.

 

= ------_=_NextPart_002_01C9BA1D.1A167D68-- ------_=_NextPart_001_01C9BA1D.1A167D68 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <989404020@10042009-09DE> Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA4AGkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtdV8f ppWq3Fi+ntIYX2hxJjPAPpUMXxEM4zHpEhHr5oA/lXOa/arceMNRL/dSQEj1OBVyz09pwMDao49A K9d0aEYJ21su55/tark0mbTfECRFydGkx7Sg/wAqrH4nx4ONLYntmUf4VUudKaFCynIHX1H4VGvh e2Mf9qazN9is1HI6PL6AD/JqYww32o/mNyrX0Ztan8QI9Nv3tGsGkKKh3CTH3lDenvUUXxEM4zHp EhHr5oA/lUWpanoq6tNbPoEdw6JGWmkYZYFQR2Pb+VTx6Jpmq2/m6XvgdRzbucjHsf8A69Z8tGMF zQfrf/gl81Rt8shW+IEiLk6NJj2lB/lVY/E+PBxpbE9syj/CqtzpDwgkfw9exH4Gud1SzG0zKuGU /NjuPWt6VHDzdnH8WZTq1Y63O41Px+mm3Yt209nzGkgIkx95QfT3qGL4iGcZj0iQj180AfyrnNbt hca6hb7iWsBI9fkFXLLT2nAwAqD8hU+xoKCbWvzKdWq5tJ7G03xAkRcnRpMe0oP8qr/8LOi/6Bj/ APf0f4VUudJaJCwPAGTwc/lVFPCl7q7iSCIQrn55pflTHr7/AIUQp4b7at82DnXvo7np1nP9qsoL jbt82NX25zjIzU1V7GJYNPt4lkEipEqhx0YAdasV5T30O5banmOskf8ACSamO4mGf++RXQaDCZkT bEWXJ3HHH51Q1jX9B0zXboSaIZ7xXw8rMMNwPr7dqSTxdd3SAW3l28JHAiHP516c41JQVo2Vv0OK DhCTu+p1V49jZEyOqySqMhOw9zXBeINRmvzNLcPwEIVey+wqafU5phjceevaue1K9Eg8mNgw6sw7 1eGw7Uia9VSVkbmqFP7buQv3tkO7/v2tb+hzJEEkDYwTkj/PpXJa9dG18TTtjKtHEGHf/VrVuzv2 RQ8T5Vh1FOdJunF9Gl+RNOSjJrzO8voo7+IyW2GlTlkHUivPdSG2KZWGCEIII6GtH+2LpJFkhkKM pyMDpTLnxjp12dmp6PBfMB/rVO0nr7VFGnUg9FdGlScJK17EepENquwYMht4MAdSNgrp9E0yfylk lhMSZyS/GfwrI1fxcNI1FYrTTLdCYY284jLgFQQPwGBVVvEF7e7ZJLppF6jGAPy6UpQqygtLKwRl CE3d9Tsry40+3+bYszqOn8Iri/EGs3eowTJLLthCHEScKPr60T6nLKuM4HcDgVz+o3yuvkxPuz99 h/Kqw+H95E1q11ZHsGk/8gey/wCvdP8A0EVbqppP/IHsv+vdP/QRVuvKluzvjsjm7/wNpepX817c SXHmTNuYK4AHGOOPaoU+HukRnKTXa/SXH9K53WNIE9n4p1Q/axfW+oBbWRJXUxriPO0A45yc10Wh 6dHo3jK+sLFJYrFrGKXYzsy+ZuYEjPfAGa2WIqpW5mZujTfQc3w/0p12vcXjD0Muf6VGfhzopH37 ke+8f4Vp+Lf7Q/4Re/8A7M8z7V5fy+V9/bkbtv8Atbc4965zQDpv/CT2I8LfavsvkP8A2l5nmbOg 2bt//LTd6ds5oWJrL7TD2NPsbF94G0rULtrmd5/MYKDtcAcKFHb0FQp8PdIjzsmu1z12y4/pXQ6l 9q/su6+w4+1eS/k5/v4O39cVxHhf+xBfaX9i/tX+1yh+3Z3/AHtvzefv4+90xznpxQsRVSspMHSg +hsN8P8ASnXa9xeMPQy5/pUZ+HGikECS5HuHHH6V1E/m/Z5PJx5u07M9N2OK8nkOnHS9OKnUj4k+ 2Q/bt3m7s+Yu/f8Aw7PT8KFiay+0w9jT7HcX3gbS9QufPnkuNwRUADgABRgdvaoU+HukRnKTXa/S XH9K6qvNbzTCun67raLdf2lbayRbSCR/kTzEGAucbSGOeOaFiKqVlJjdKD1aOib4f6U67XuLxh6G XP8ASo/+Fc6L/fuf++x/hXWV5rrX9nG917+3jf8A9q+Y39m+V5n+r2jy/K28ZznP60fWay+0xexp 9jqZPEEWlava6EtrLIqiOLziw4zgDjv1H5H0roaxvDFuj+G9InnhVrlLOMeY6fODtGeTyK2awNQo oooAKKKKACiiigAooooAKKKKACiiigAooooA/9k= ------_=_NextPart_001_01C9BA1D.1A167D68-- From paul.hoffman@vpnc.org Fri Apr 10 16:34:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23313A6ABD for ; Fri, 10 Apr 2009 16:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 Wn7xfEX5CFkM for ; Fri, 10 Apr 2009 16:34:48 -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 CE8073A684B for ; Fri, 10 Apr 2009 16:34:47 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ANZocB043902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 16:35:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A026220A2@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A0262201B@CORPUSMX80A.corp.emc.com> <50DADDE6B33B1B47904E685AAFDC18241A8551ADA3@yugi.mocana.local> <9FA859626025B64FBC2AF149D97C944A026220A2@CORPUSMX80A.corp.emc.com> Date: Fri, 10 Apr 2009 16:35:46 -0700 To: Black_David@emc.com, , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: pasi.eronen@nokia.com Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 23:34:48 -0000 At 4:44 PM -0400 4/10/09, Black_David@emc.com wrote: >That looks like an oversight at least wrt RFC 4869. Actually, this started with an oversight in RFC 4543. Section 5 clearly says that it is for IKEv1 and IKEv2, but section 9 only seems to cover IKEv2. >Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to >allocate this value, or is there a lower overhead and faster >means of getting this done? This can probably be done by Pasi, given the nature of the error. Otherwise, we probably need a revision to RFC 4543. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Sat Apr 11 01:01:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127C43A6AE1 for ; Sat, 11 Apr 2009 01:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 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 WNBk0M6YRRxz for ; Sat, 11 Apr 2009 01:01:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9BA9E3A6807 for ; Sat, 11 Apr 2009 01:01:37 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B46A930C001; Sat, 11 Apr 2009 11:02:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6C9AF2CC003 for ; Sat, 11 Apr 2009 11:02:45 +0300 (IDT) X-CheckPoint: {49E04BA2-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 n3B82iqO020934 for ; Sat, 11 Apr 2009 11:02:45 +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; Sat, 11 Apr 2009 11:02:44 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sat, 11 Apr 2009 11:02:40 +0300 Thread-Topic: Redirect -07 comments Thread-Index: Acm6e9boig8OKMfhSKqqn1LaOvchCw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEE10@il-ex01.ad.checkpoint.com> 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_0000_01C9BA95.060E1750" MIME-Version: 1.0 Subject: [IPsec] Redirect -07 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 08:01:39 -0000 ------=_NextPart_000_0000_01C9BA95.060E1750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, Here's a bunch of comments on the latest draft, some minor, some not so minor. Thanks, Yaron - 1: During during -> during - 1: Can be also be -> can also be - 3: I suggest to start this section with an exhaustive list of locations where the Redirect payload can occur (IKA_SA_INIT response, IKE_AUTH last response, Informational from gateway). - 3: "The VPN client indicates support for the IKEv2 redirect mechanism by including..." -> By including ..., the VPN client indicates that it supports the IKEv2 redirect mechanism and that it is willing to be redirected. - 3: "It initiates a new IKE_SA_INIT exchange with the VPN gateway listed in the REDIRECT payload", add: "provided this is allowed by its IPsec policy". - 3: The last paragraph (re: MIP6) is out of context here, and I was unable to understand it. I suggest to clarify and extend it into a separate section. - 5: "If the gateway decides to redirect the client during the IKE_AUTH Exchange..." - this should start a new section. - Same paragraph: add "The gateway MUST verify the client's AUTH payload before sending the Redirect payload, and the client MUST verify the gateway's AUTH payload before acting on the Redirect payload." - "In case the IKE_AUTH exchange involves EAP authentication" - add: "The gateway MUST NOT send and the client MUST NOT accept a redirect in any earlier message." - 6.2: Now that we've appended the nonce, we should signal the length of the Identity field explicitly (possibly by stealing 1 octet from the Identity Type). Even though the client can theoretically compute it using the length of the expected nonce. ------=_NextPart_000_0000_01C9BA95.060E1750 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQxMTA4MDIzN1owIwYJKoZIhvcNAQkEMRYEFNJ/xs3sTI+t 63R7o8elvtYO1jgoMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA kcA0WQeur+kYH18iVK/+9U+oysm6uXWIQ9vtNNkZqKKxJcuoOCF3VT+yS1vOLfctNEqUiObqZW/9 WIqQYQZHX0FJaUj3DBqsBpos8xixTxrIqQHtkYN5LkXLYzAbby2dXsU8iipMEvbs3NvWHrDISqVv eRRCLCTh/ZjgrF6Dg7Fu53r4imar3EtmiIol1tzL8S6xwVf6a5/hu4etTX7VbqNZk01IrnpIfcB8 JM7nLOg1uM1e7Hpa7n4LRLexy0guFiRNd3nUDWHeCll7owHpvSKZP9ETVerB7adApGrjI1OiYFb0 chmo+5MmQFAemGQJkoYJgSNrQfn0Z1IbLPa9dQAAAAAAAA== ------=_NextPart_000_0000_01C9BA95.060E1750-- From ynir@checkpoint.com Sat Apr 11 23:22:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB20A3A6904 for ; Sat, 11 Apr 2009 23:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsseMkFhIp7e for ; Sat, 11 Apr 2009 23:22:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9E19D3A6834 for ; Sat, 11 Apr 2009 23:22:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4240E30C006; Sun, 12 Apr 2009 09:23:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 044FF2CC001; Sun, 12 Apr 2009 09:23:37 +0300 (IDT) X-CheckPoint: {49E185D4-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 n3C6NaqO017159; Sun, 12 Apr 2009 09:23:36 +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, 12 Apr 2009 09:23:35 +0300 From: Yoav Nir To: Paul Hoffman , IPsecme WG Date: Sun, 12 Apr 2009 09:25:07 +0300 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: Acm4c1LNSnIxqOkbRL2+ULfEJVnS+gCw4pKA Message-ID: <9FB7C7CE79B84449B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 06:22:29 -0000 I prefer the second proposal. I would rather have one (even if longer) var= iation of the protocol over two variations (even if one is shorter) With such a possible attack published, auditors are going to force large in= stallations to use the safer (and longer) version anyway, as it is up to th= e gateway to decide.=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Paul Hoffman > Sent: Wednesday, April 08, 2009 8:56 PM > To: IPsecme WG > Subject: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > Greetings again. Tracker issue #98 is the same as the message=20 > that Pasi sent to the mailing list last month; see=20 > tml>. There is disagreement among the authors of the session=20 > resumption draft how to deal with this issue. >=20 > One proposal is to add text similar to Pasi's to the document=20 > in order to let implementers understand all the things that=20 > they might need to do to prevent damage from a replay attack.=20 > If this is the method chosen, it should probably be as a=20 > section in the main body of the document, not as a "security=20 > consideration" because the issues are more operational than security. >=20 > A different proposal is to get rid of the one-round-trip mode=20 > and have the protocol always take two round trips. This=20 > prevents the attack that Pasi brings up, at a higher cost for=20 > the clients and server. >=20 > If you have a preference between these two proposal, please=20 > state it now.=20 >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. > = Email secured by Check Point From ldondeti@qualcomm.com Mon Apr 13 11:07:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD003A6D46 for ; Mon, 13 Apr 2009 11:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-6rT7nDIjMl for ; Mon, 13 Apr 2009 11:06:59 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 909913A6C6F for ; Mon, 13 Apr 2009 11:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1239646091; x=1271182091; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49E37F77.3080202@qualcomm.com>|Date:=20Mo n,=2013=20Apr=202009=2023:37:51=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Yoav=20Nir=20|CC:=20Paul=20Hoffman=20, =20IPsecme=20WG=20|Subject:=20Re:=20[IPse c]=20Issue=20#98:=201=20or=20two=20round=20trips=20for=20 resumption|References:=20=20=20<9FB7C7CE79B84449B52622B506C780361332A13E62@i l-ex01.ad.checkpoint.com>|In-Reply-To:=20<9FB7C7CE79B8444 9B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-15=3B =20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5583"=3B=20 a=3D"17081228"; bh=f4eKJdJGJ30AL3wb3+ut9/Mubrod/7iPfiZgW65RSa0=; b=PRizs1BiYMxvsEldMomhTc5wazj0A4a31rDaZNzedcz6/ffNs+MVyvGi z5tdkuvd95/KcTSlsRN2piKWBTN9SVq9Fy/HpKK5l8oS8j7aJrYtyWKdk kP3pZBXMAPcfcE6ocmllPZIEo0I7hflvQl46roY8krujb72PPru04zIX0 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5583"; a="17081228" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2009 11:07:57 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3DI7vmV021671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Apr 2009 11:07:57 -0700 Received: from [10.50.65.110] (qconnect-10-50-65-110.qualcomm.com [10.50.65.110]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3DI7qqb023661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Apr 2009 11:07:55 -0700 (PDT) Message-ID: <49E37F77.3080202@qualcomm.com> Date: Mon, 13 Apr 2009 23:37:51 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Yoav Nir References: <9FB7C7CE79B84449B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:07:00 -0000 I prefer the first. In terms of how to document it, we have examples of that already in IKEv2 spec. On 4/12/2009 11:55 AM, Yoav Nir wrote: > I prefer the second proposal. I would rather have one (even if > longer) variation of the protocol over two variations (even if one is > shorter) > > With such a possible attack published, auditors are going to force > large installations to use the safer (and longer) version anyway, as > it is up to the gateway to decide. Are you saying that currently large installations use the 6-message version of IKEv2? thanks, Lakshminath > >> -----Original Message----- From: ipsec-bounces@ietf.org >> [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: >> Wednesday, April 08, 2009 8:56 PM To: IPsecme WG Subject: [IPsec] >> Issue #98: 1 or two round trips for resumption >> >> Greetings again. Tracker issue #98 is the same as the message that >> Pasi sent to the mailing list last month; see >> > tml>. There is disagreement among the authors of the session >> resumption draft how to deal with this issue. >> >> One proposal is to add text similar to Pasi's to the document in >> order to let implementers understand all the things that they might >> need to do to prevent damage from a replay attack. If this is the >> method chosen, it should probably be as a section in the main body >> of the document, not as a "security consideration" because the >> issues are more operational than security. >> >> A different proposal is to get rid of the one-round-trip mode and >> have the protocol always take two round trips. This prevents the >> attack that Pasi brings up, at a higher cost for the clients and >> server. >> >> If you have a preference between these two proposal, please state >> it now. >> >> --Paul Hoffman, Director --VPN Consortium >> _______________________________________________ IPsec mailing list >> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> > Email secured by Check Point > _______________________________________________ IPsec mailing list > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec > From vijay@wichorus.com Mon Apr 13 12:26:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4789A3A68F3 for ; Mon, 13 Apr 2009 12:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] 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 5FrvtuAgKyNo for ; Mon, 13 Apr 2009 12:26:15 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 62A9B3A68E3 for ; Mon, 13 Apr 2009 12:26:15 -0700 (PDT) Received: from 99.51.129.145 ([99.51.129.145]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Apr 2009 19:27:25 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 13 Apr 2009 12:27:25 -0700 From: Vijay Devarapalli To: Yaron Sheffer , IPsecme WG Message-ID: Thread-Topic: [IPsec] Redirect -07 comments Thread-Index: Acm6e9boig8OKMfhSKqqn1LaOvchCwB8gj09 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEE10@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Redirect -07 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 19:26:16 -0000 Hi Yaron, Thanks for the detailed review. Just responding to those that need more discussion or where I have comments. On 4/11/09 1:02 AM, "Yaron Sheffer" wrote: > - 3: I suggest to start this section with an exhaustive list of locations > where the Redirect payload can occur (IKA_SA_INIT response, IKE_AUTH last > response, Informational from gateway). Section 1 already talks about all three. I think a better option would be re-name section 3 as "IKEv2 Initial Exchange with Redirect". The sections that come later are already called "Gateway Initiated Redirect" and "Redirect During IKE_AUTH Exchange". > - 3: "The VPN client indicates support for the IKEv2 redirect mechanism by > including..." -> By including ..., the VPN client indicates that it supports > the IKEv2 redirect mechanism and that it is willing to be redirected. Hmm... The client can always exclude the REDIRECT_SUPPORTED payload based on its configuration if it does not want to be redirected. So do we need to mention this? > - 3: The last paragraph (re: MIP6) is out of context here, and I was unable > to understand it. I suggest to clarify and extend it into a separate > section. When redirect is used with Mobile IPv6, there is a separate Home Agent discovery mechanism. So the Mobile IPv6 stack would have a home agent configured. If the IKEv2 redirect mechanism changes the gateway information, then the state becomes inconsistent. The original intent was talk about that. I replaced the paragraph with the following. When this mechanism is used with Mobile IPv6, care must be taken to ensure that the home agent information is consistent with the IKEv2 gateway information. The Mobile IPv6 home agent discovery mechanisms (for instance, RFC 5026 [4]) would have a configured the mobile node with a particular home agent. When the mobile node initiates an IKEv2 exchange with the home agent and is redirected to another gateway, the home agent information should also be updated, subject to the policy on the mobile node. > - 6.2: Now that we've appended the nonce, we should signal the length of the > Identity field explicitly (possibly by stealing 1 octet from the Identity > Type). Even though the client can theoretically compute it using the length > of the expected nonce. Good point. I added a 'GW Identity Length' field to both REDIRECT and REDIRECTED_FROM payloads. I added the field to the REDIRECTED_FROM payload also for consistency. Vijay From paul.hoffman@vpnc.org Mon Apr 13 13:02:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0158C3A6990 for ; Mon, 13 Apr 2009 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.461, 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 Vp0SNc00-pcU for ; Mon, 13 Apr 2009 13:02:09 -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 E6F583A6944 for ; Mon, 13 Apr 2009 13:02:08 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DK3EiM057441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 13:03:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <49E37F77.3080202@qualcomm.com> References: <9FB7C7CE79B84449B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> <49E37F77.3080202@qualcomm.com> Date: Mon, 13 Apr 2009 13:03:12 -0700 To: Lakshminath Dondeti From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:02:10 -0000 At 11:37 PM +0530 4/13/09, Lakshminath Dondeti wrote: >Are you saying that currently large installations use the 6-message version of IKEv2? Are you saying that the threat model for 1-round-trip session resumption are the same as for IKEv2 without cookies? If not, could you explain the above comment further? --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Mon Apr 13 14:03:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95213A67A4 for ; Mon, 13 Apr 2009 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 qNvPeoKwJ0XN for ; Mon, 13 Apr 2009 14:03:16 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 24B673A6C22 for ; Mon, 13 Apr 2009 14:03:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 52F2030C002; Tue, 14 Apr 2009 00:04:24 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0E3602CC001; Tue, 14 Apr 2009 00:04:24 +0300 (IDT) X-CheckPoint: {49E3A5A6-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 n3DL4NqO017763; Tue, 14 Apr 2009 00:04:23 +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; Tue, 14 Apr 2009 00:04:23 +0300 From: Yaron Sheffer To: Vijay Devarapalli , IPsecme WG Date: Tue, 14 Apr 2009 00:04:19 +0300 Thread-Topic: [IPsec] Redirect -07 comments Thread-Index: Acm6e9boig8OKMfhSKqqn1LaOvchCwB8gj09AAMyX2A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF040@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBEE10@il-ex01.ad.checkpoint.com> In-Reply-To: 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_0051_01C9BC94.8EA8F930" MIME-Version: 1.0 Subject: Re: [IPsec] Redirect -07 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:03:17 -0000 ------=_NextPart_000_0051_01C9BC94.8EA8F930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, See comments to your comments below. Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Monday, April 13, 2009 22:27 > To: Yaron Sheffer; IPsecme WG > Subject: Re: [IPsec] Redirect -07 comments > > Hi Yaron, > > Thanks for the detailed review. Just responding to those that need more > discussion or where I have comments. > > On 4/11/09 1:02 AM, "Yaron Sheffer" wrote: > > > - 3: I suggest to start this section with an exhaustive list of > locations > > where the Redirect payload can occur (IKA_SA_INIT response, IKE_AUTH > last > > response, Informational from gateway). > > Section 1 already talks about all three. > > I think a better option would be re-name section 3 as "IKEv2 Initial > Exchange with Redirect". The sections that come later are already called > "Gateway Initiated Redirect" and "Redirect During IKE_AUTH Exchange". > [YS] Sec. 1 is sort of conversational. A list would make it clear that ONLY these 3 options are allowed. > > - 3: "The VPN client indicates support for the IKEv2 redirect mechanism > by > > including..." -> By including ..., the VPN client indicates that it > supports > > the IKEv2 redirect mechanism and that it is willing to be redirected. > > Hmm... The client can always exclude the REDIRECT_SUPPORTED payload based > on > its configuration if it does not want to be redirected. So do we need to > mention this? > [YS] I think it's a useful clarification. But I can live without it. > > - 3: The last paragraph (re: MIP6) is out of context here, and I was > unable > > to understand it. I suggest to clarify and extend it into a separate > > section. > > When redirect is used with Mobile IPv6, there is a separate Home Agent > discovery mechanism. So the Mobile IPv6 stack would have a home agent > configured. If the IKEv2 redirect mechanism changes the gateway > information, > then the state becomes inconsistent. The original intent was talk about > that. I replaced the paragraph with the following. > > When this mechanism is used with Mobile IPv6, care must be taken to > ensure that the home agent information is consistent with the IKEv2 > gateway information. The Mobile IPv6 home agent discovery mechanisms > (for instance, RFC 5026 [4]) would have a configured the mobile node > with a particular home agent. When the mobile node initiates an > IKEv2 exchange with the home agent and is redirected to another > gateway, the home agent information should also be updated, subject > to the policy on the mobile node. > [YS] Much better. Thanks. > > - 6.2: Now that we've appended the nonce, we should signal the length of > the > > Identity field explicitly (possibly by stealing 1 octet from the > Identity > > Type). Even though the client can theoretically compute it using the > length > > of the expected nonce. > > Good point. I added a 'GW Identity Length' field to both REDIRECT and > REDIRECTED_FROM payloads. I added the field to the REDIRECTED_FROM payload > also for consistency. > > Vijay > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0051_01C9BC94.8EA8F930 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQxMzIxMDQxOVowIwYJKoZIhvcNAQkEMRYEFGbCOhM/t9E+ Jw7epmpbEoTERsQYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA G95mhzQc1nrGtB2d2opA2a4L2d2znt5SbuRqypWg9QymwkJ69vAAYsXKmmT0ilAEyaxdW2lXizm8 AdLbheCMEqpFxNdWO6bzc7/YgYkybMS0qjYclZauiwjc24y0NY6HVpxNhkGe3uoVGH2PCy13s1Ue R2EX/JTT0DG/HJZDa5EpplARXu9YopEJzA8YRpZfip0/eygfR6oX2KlVHrK81IGct9gp8A9Zv26g 6NXifd//5TD53A+vb8KnfHw5/LcQazOeNmZEPHQLexi9RU/dojeM+bsrvfjKLyVuuBYCOK+Liuut iRIhGLiui7WNmTULZEsapDm7an8P5wqiqcsregAAAAAAAA== ------=_NextPart_000_0051_01C9BC94.8EA8F930-- From root@core3.amsl.com Mon Apr 13 14:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 82B2628C16D; Mon, 13 Apr 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090413214501.82B2628C16D@core3.amsl.com> Date: Mon, 13 Apr 2009 14:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-08.txt Pages : 13 Date : 2009-04-13 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-13144334.I-D@ietf.org> --NextPart-- From ldondeti@qualcomm.com Mon Apr 13 20:59:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7333A69F0 for ; Mon, 13 Apr 2009 20:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 b+GcBeYzitej for ; Mon, 13 Apr 2009 20:59:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 251D03A68DF for ; Mon, 13 Apr 2009 20:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1239681667; x=1271217667; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49E40A72.3070305@qualcomm.com>|Date:=20Tu e,=2014=20Apr=202009=2009:30:50=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Paul=20Hoffman=20|CC:=20IPsecme=20WG=20 |Subject:=20Re:=20[IPsec]=20Issue=20#98:=201=20or=20two =20round=20trips=20for=20resumption|References:=20=20<9FB7C7CE79B84449B52622 B506C780361332A13E62@il-ex01.ad.checkpoint.com>=20<49E37F 77.3080202@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3DISO-8859- 15=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5583"=3B=20 a=3D"17110501"; bh=zvslZ+5WF08/WhWKoJ4DWhbAyjTOaOCKR9AkzRgM/PI=; b=VFM0wFEJ/5k6ihWnB/Um1ztKtwExJqZdVKm7JwVlYRM8Q4yms0/f+/xQ qraLm59aJDVWX/SaM7WJAKnnVaxhAsd6FrMdvfOhV56RI2r9XWqNXGzsh A9TAAZ/A9A2YMC0ucQl9/WpzSemrRE5JGCLqkvrvE9Gt5DbvSicdcDicB g=; X-IronPort-AV: E=McAfee;i="5300,2777,5583"; a="17110501" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2009 21:01:07 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3E416GL029875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Apr 2009 21:01:07 -0700 Received: from [10.50.73.223] (qconnect-10-50-73-223.qualcomm.com [10.50.73.223]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3E40oYd030077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Apr 2009 21:00:58 -0700 Message-ID: <49E40A72.3070305@qualcomm.com> Date: Tue, 14 Apr 2009 09:30:50 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Paul Hoffman References: <9FB7C7CE79B84449B52622B506C780361332A13E62@il-ex01.ad.checkpoint.com> <49E37F77.3080202@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 03:59:57 -0000 I am saying they are similar (I wouldn't say they are the same, as they are two different protocols operating in different contexts). regards, Lakshminath On 4/14/2009 1:33 AM, Paul Hoffman wrote: > At 11:37 PM +0530 4/13/09, Lakshminath Dondeti wrote: >> Are you saying that currently large installations use the 6-message >> version of IKEv2? > > Are you saying that the threat model for 1-round-trip session > resumption are the same as for IKEv2 without cookies? If not, could > you explain the above comment further? > > --Paul Hoffman, Director --VPN Consortium > From kivinen@iki.fi Tue Apr 14 04:30:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D173A63EC for ; Tue, 14 Apr 2009 04:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 fzk57dLBRwVW for ; Tue, 14 Apr 2009 04:30:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBC03A6A90 for ; Tue, 14 Apr 2009 04:30:38 -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 n3EBVgxx017389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:31:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3EBVdJm028195; Tue, 14 Apr 2009 14:31:39 +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: <18916.29723.723882.97532@fireball.kivinen.iki.fi> Date: Tue, 14 Apr 2009 14:31:39 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <9FA859626025B64FBC2AF149D97C944A0262201B@CORPUSMX80A.corp.emc.com> <50DADDE6B33B1B47904E685AAFDC18241A8551ADA3@yugi.mocana.local> <9FA859626025B64FBC2AF149D97C944A026220A2@CORPUSMX80A.corp.emc.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 31 min X-Total-Time: 39 min Cc: SChew@mocana.com, ipsec@ietf.org, pasi.eronen@nokia.com, Black_David@emc.com Subject: Re: [IPsec] transform id for ESP GMAC for IKEv1 Phase2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 11:30:58 -0000 Paul Hoffman writes: > At 4:44 PM -0400 4/10/09, Black_David@emc.com wrote: > >That looks like an oversight at least wrt RFC 4869. > > Actually, this started with an oversight in RFC 4543. Section 5 > clearly says that it is for IKEv1 and IKEv2, but section 9 only > seems to cover IKEv2. Yes. > >Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to > >allocate this value, or is there a lower overhead and faster > >means of getting this done? > > This can probably be done by Pasi, given the nature of the error. > Otherwise, we probably need a revision to RFC 4543. It would be easier to fix that if the value would be missing from the IKEv2 registry as those are expert review actions. The whole ikev1 (http://www.iana.org/assignments/isakmp-registry) registry is completele mess. For example the top level iana list (http://www.iana.org/protocols/) only contains following registries pointing to the isakmp-registry: - ISAKMP AH Transform Identifiers - IPSEC Security Association Attributes - ISAKMP Identifiers - Signature Encoding Algorithm Values The RFC2407 lists more registries: 6.1 IPSEC Situation Definition 6.2 IPSEC Security Protocol Identifiers 6.3 IPSEC ISAKMP Transform Identifiers 6.4 IPSEC AH Transform Identifiers 6.5 IPSEC ESP Transform Identifiers 6.6 IPSEC IPCOMP Transform Identifiers 6.7 IPSEC Security Association Attributes 6.8 IPSEC Labeled Domain Identifiers 6.9 IPSEC Identification Type 6.10 IPSEC Notify Message Types And those are the registries actually included in the isakmp-registry file. In addition to those the isakmp-registry also contains the "ISAKMP Domain of Interpretation (DOI)", and "Next Payload Types" registries. The "Next Payload Types" which was created afterwords when we noticed we do need it. I do not think its creation is specified in any RFC. Don't even know when the DOI registry was created. Most of those IKEv1 registries do require RFC and IESG review (IPsec Situation Definition, IPSEC Security Protocol Identifiers, IPSEC ISAKMP Transform Identifiers, IPSEC AH Transform Identifiers, IPSEC ESP Transform Identifiers, IPSEC IPCOMP Transform Identifiers, IPSEC Identification Type). Rest just require Internet Draft to specify it... As this change to the isakmp-registry changes the IPSEC ESP Transform Identifiers registry, which do require Standard Track RFC or IESG review, I think we cannot simply modify the registry, but we at minimum need to make errata for the RFC4543 which reserves values also from the IKEv1 registry. Of course as everybody should be using the IKEv2, and everybody should be moving away from the obsoleted IKEv1 protocol, we can also just say that you cannot use those algorithms with obsoleted IKEv1 protocol, and you need to use IKEv2 for it :-) Anyways IANA should fix their toplevel list (http://www.iana.org/protocols/) to include all the registries listed in the isakmp-registry file, i.e.: ---------------------------------------------------------------------- IPSEC Situation Definition RFC 2407 Standards Action IPSEC Security Protocol Identifiers RFC 2407 0-248 Standards Track RFC; 249-255 Reserved for private use amongst cooperating systems IPSEC ISAKMP Transform Identifiers RFC 2407 0-248 Standards Track RFC; 249-255 Reserved for private use amongst cooperating systems IPSEC AH Transform Identifiers RFC 2407 0-248 Standards Track RFC; 249-255 Reserved for private use amongst cooperating systems IPSEC ESP Transform Identifiers RFC 2407 0-248 Standards Track RFC; 249-255 Reserved for private use amongst cooperating systems IPSEC IPCOMP Transform Identifiers RFC 2407 0-47 Standards Track RFC; 48-63 Reserved for private use amongst cooperating systems IPSEC Security Association Attributes RFC 2407 1-32000 Specification Required; 32001-32767 Reserved for private use amongst cooperating systems Signature Encoding Algorithm Values RFC 4359 Standards Action IPSEC Labeled Domain Identifiers RFC 2407 First Come First Serve IPSEC Identification Type RFC 2407 0-248 Standards Track RFC; 249-255 Reserved for private use amongst cooperating systems IPSEC Notify Message Types RFC 2407 8192-16000 and 24576-32000 Specification Required; 16001-16383 and 32001-32767 Reserved for private use amongst cooperating systems ISAKMP Domain of Interpretation (DOI) RFC ? Specification Required Next Payload Types RFC ? 0-127 ???, 128-255 Reserved for private use amongst cooperating systems -- kivinen@iki.fi From root@core3.amsl.com Wed Apr 15 10:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 920213A6BBE; Wed, 15 Apr 2009 10:00:01 -0700 (PDT) From: IETF Secretariat To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090415170001.920213A6BBE@core3.amsl.com> Date: Wed, 15 Apr 2009 10:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Virtual Interim Meeting for IPSECME X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:00:01 -0000 The IPSECME WG will have a conference call on Tuesday, 5 May 2009 at 15:00 GMT (11:00 EDT, 08:00 PDT), for two hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Details for the meeting can be found on the IPSECME Wiki page: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls From yaronf@checkpoint.com Thu Apr 16 00:36:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D71C3A6B64 for ; Thu, 16 Apr 2009 00:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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 wUpG4gcsPPh1 for ; Thu, 16 Apr 2009 00:36:24 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9D9DE3A69D2 for ; Thu, 16 Apr 2009 00:36:23 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 14E1530C002; Thu, 16 Apr 2009 10:37:35 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C4B6D2CC001 for ; Thu, 16 Apr 2009 10:37:34 +0300 (IDT) X-CheckPoint: {49E6DCE0-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 n3G7bYqO017394 for ; Thu, 16 Apr 2009 10:37:34 +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; Thu, 16 Apr 2009 10:37:33 +0300 From: Yaron Sheffer To: IPsecme WG Date: Thu, 16 Apr 2009 10:37:32 +0300 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> 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_0010_01C9BE7F.595E3500" MIME-Version: 1.0 Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 07:36:25 -0000 ------=_NextPart_000_0010_01C9BE7F.595E3500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 2 week working group last call for draft-ietf-ipsecme-ikev2-redirect-08. The target status for this document is Proposed Standard. This is the document's second last call, following comments by a number of people and several document revisions. Please send your comments to the ipsec list by April 30, 2009, as follow-ups to this message. Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document. The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08. Thanks, Yaron ------=_NextPart_000_0010_01C9BE7F.595E3500 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQxNjA3MzczMlowIwYJKoZIhvcNAQkEMRYEFOqUoL4+XgOW kwhAMsaSFQuD/NEHMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA FLZXUtLdmfDKGPw5s36uia6huSl2SmbCYIbIZdDMgE+4OtjiRY1ayvhWj79MqlfLA46weSVteKUV NKM10rHrpRYjUG6q3D7EhIO5kafflxk+e/wZdmYIiZ26UsFft/Xi2G6SNHBsS98u+753ChfdfP5F M9GHJkaIsCsFBlTFBDABC1fxf/UXdJs/Zc7yuVzumlWFhIYhdxlk/5clanthAKWsgjLltpe42bVF 2gD+x1kEWVrdxNBGJW0LWs1PT/6glGoQP66AsbQdDVYU35anLbwhdH7NSAvP5IZZoodrm77I4VAi 6o545PTyePeu0wUGBxaz0HtNZESYPXTPZgl5TAAAAAAAAA== ------=_NextPart_000_0010_01C9BE7F.595E3500-- From ynir@checkpoint.com Thu Apr 16 01:11:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8008A3A6CA9 for ; Thu, 16 Apr 2009 01:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNJNbRJL8C+y for ; Thu, 16 Apr 2009 01:11:25 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4E3173A6882 for ; Thu, 16 Apr 2009 01:11:25 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7386D2CC005; Thu, 16 Apr 2009 11:12:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 234682CC001 for ; Thu, 16 Apr 2009 11:12:37 +0300 (IDT) X-CheckPoint: {49E6E516-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 n3G8CaqO027630 for ; Thu, 16 Apr 2009 11:12:36 +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; Thu, 16 Apr 2009 11:12:36 +0300 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 16 Apr 2009 11:14:19 +0300 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAAF4W9A= Message-ID: <9FB7C7CE79B84449B52622B506C780361332A141BF@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:11:26 -0000 I see that in section 6 the following: In such cases, the gateway should send the REDIRECT notification payload in the final IKE_AUTH response message that carries the AUTH payload and the traffic selectors. The gateway MUST NOT send and the client MUST NOT accept a redirect in an earlier IKE_AUTH message.=20 I like that, and that was my position earlier, but wasn't the conclusion at= San Francisco that the REDIRECT could come in either the first AUTH respon= se (where we know the ID the client is using, temporary or not) *OR* in the= last response? When did we decide to not allow it in the first resopnse? Other than that, I think the document is fine and ready for publication. Yaron Sheffer wrote: > This is a 2 week working group last call for=20 > draft-ietf-ipsecme-ikev2-redirect-08. The target status for=20 > this document is Proposed Standard. This is the document's=20 > second last call, following comments by a number of people=20 > and several document revisions. >=20 > Please send your comments to the ipsec list by April 30,=20 > 2009, as follow-ups to this message. >=20 > Please clearly indicate the position of any issue in the=20 > Internet Draft, and if possible provide alternative text.=20 > Please also indicate the nature or severity of the error or=20 > correction, e.g. major technical, minor technical, nit, so=20 > that we can quickly judge the extent of problems with the document. >=20 > The document can be accessed here: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08. >=20 > Thanks, > Yaron Email secured by Check Point From mcins1@gmail.com Thu Apr 16 05:57:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D17B3A6C2B for ; Thu, 16 Apr 2009 05:57:19 -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 T9dz8+VBkNPF for ; Thu, 16 Apr 2009 05:57:18 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 7ABC53A6BAD for ; Thu, 16 Apr 2009 05:57:18 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so283112qwb.31 for ; Thu, 16 Apr 2009 05:58: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; bh=ZfNnHf0zrUVGbhV8oMwp6cZ1x5qdDiaGgwo9PqyeZms=; b=vISkCIy8H30Ga8e1blbytHGNVIUDOFzyz6WnMRt2eDwB7/jWIq/U2SBVGEU5vqEKtb Om5j5PXLdMQlJuD6SC/TQlf524yzfRT1hOLiiW82aVW7PsvC6d//pgtRUfCDBlG4kJI3 E3hu9e/qv42I85Ua5Aqrz6ojyCFPMieMwjq9M= 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; b=l6bbhdpueOpI6Gx2HGXLlJumHayozBZfgY7ljkU8em/0FbtcADVt6gmgrEHjW+SDm8 V428H4AAOvREYUbDy2KJrodMTD6JJx+rhjjWy3QmfIgmZvqyJfPqv7o562mRswiK2ySH vcOEkcX3PoSqlWs8aBYbD9MPpwIRl+PuYNvf4= MIME-Version: 1.0 Received: by 10.220.95.202 with SMTP id e10mr299546vcn.12.1239886710626; Thu, 16 Apr 2009 05:58:30 -0700 (PDT) In-Reply-To: <1236809211.3129.92.camel@faith.austin.ibm.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2EC73@il-ex01.ad.checkpoint.com> <1236809211.3129.92.camel@faith.austin.ibm.com> Date: Thu, 16 Apr 2009 14:58:30 +0200 Message-ID: <99043b4a0904160558q6cf026ffre8a8fb3390dafc40@mail.gmail.com> From: Matthew Cini Sarreo To: Joy Latten Content-Type: multipart/alternative; boundary=0016e64eacb4f2db3f0467ab9eb1 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 12:57:19 -0000 --0016e64eacb4f2db3f0467ab9eb1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't know the current status about this. I would suggest that this could be left as it currently is. When reading the section about rekeying IKE SAs (1.3.2), it is easily deduced that rekeying will have the effect of resetting the Message IDs of the SA to 0. Section 2.18 also states this. Perhaps, having a single paragraph discussing Rekeying of IKE SAs using the CREATE_CHILD_SA exchange would make understanding the process faster. In 2.2, the reader could be redirected to the new, unified section about rekeying after the section (2.2) states that Message IDs are reset when rekeying an IKE SA. Maybe something like: 2.2. Use of Sequence Numbers for Message ID The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT messages (including retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD), and when an IKE SA is being rekeyed (the new IKE SA that will take place of the expiring SA MUST have the Message ID set to 0). For information about rekeying, see section *Rekeying an IKE_SA with CREATE_CHILD_SA.* The Message ID is then incremened for each subsequent exchange. 2009/3/11 Joy Latten > > On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote: > > 2.2. Use of Sequence Numbers for Message ID > > > > The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT > > messages (including retries of the message due to responses such as > > COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), and incremented for > > each subsequent exchange. > > > > Tero: > > > > Add text: > > > > The Message ID is reset to zero also after IKE SA rekey for the new > > IKE SA. > > > That paragraph has another sentence "Rekeying an IKE SA resets the > sequence numbers." Perhaps the above and this could be > combined. Something like: > > Rekeying an IKE SA resets the sequence number counter to zero for the > new IKE SA. > > regards, > Joy > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e64eacb4f2db3f0467ab9eb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't know the current status about this.

I would suggest that= this could be left as it currently is. When reading the section about reke= ying IKE SAs (1.3.2), it is easily deduced that rekeying will have the effe= ct of resetting the Message IDs of the SA to 0. Section 2.18 also states th= is.

Perhaps, having a single paragraph discussing Rekeying of IKE SAs using= the CREATE_CHILD_SA exchange would make understanding the process faster. = In 2.2, the reader could be redirected to the new, unified section about re= keying after the section (2.2) states that Message IDs are reset when rekey= ing an IKE SA. Maybe something like:

2.2. Use of Sequence Numbers for Message ID

The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT = messages (including retries of the message due to responses such as=A0COOKI= E and INVALID_KE_PAYLOAD), and when an IKE SA is being rekeyed (the new IKE= SA that will take place of the expiring SA MUST have the Message ID set to= 0). For information about rekeying, see section Rekeying an IKE_SA with= CREATE_CHILD_SA. The Message ID is then incremened for each subsequent= exchange.

2009/3/11 Joy Latten <<= a href=3D"mailto:latten@austin.ibm.com">latten@austin.ibm.com>

On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote:
> 2.2. Use of Sequence Numbers for Message ID
>
> The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT=
> messages (including retries of the message due to responses such as > COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), and incremented for > each subsequent exchange.
>
> Tero:
>
> Add text:
>
> The Message ID is reset to zero also after IKE SA rekey for the new > IKE SA.
>
That paragraph has another sentence "Rekeying an IKE SA resets t= he
sequence numbers." Perhaps the above and this could be
combined. Something like:

Rekeying an IKE SA resets the sequence number counter to zero for the
new IKE SA.

regards,
Joy



_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016e64eacb4f2db3f0467ab9eb1-- From root@core3.amsl.com Thu Apr 16 07:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4BD833A6B6E; Thu, 16 Apr 2009 07:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090416140001.4BD833A6B6E@core3.amsl.com> Date: Thu, 16 Apr 2009 07:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 14:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-ietf-ipsecme-esp-null-heuristics-00.txt Pages : 33 Date : 2009-04-16 This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-esp-null-heuristics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-16064741.I-D@ietf.org> --NextPart-- From mcins1@gmail.com Thu Apr 16 09:30:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F085A28C23F for ; Thu, 16 Apr 2009 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 Cp7SDC0i9CPe for ; Thu, 16 Apr 2009 09:30:17 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 079FF28C237 for ; Thu, 16 Apr 2009 09:30:16 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so511018and.4 for ; Thu, 16 Apr 2009 09:31:29 -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; bh=gl756QjQgN2SNFe1YMtM/sLuw6ajRsh35GGqCE+qUz8=; b=GvuvuwBoZ6/+AgknY8XwARTVRZ5BwY/G8B0y0nWuCSAloIgNU0CngCa8RDYF8phFnH QOQ7DFRIjVUJ6nyrz/9g/0743fmh4yzpIhCxf8KPA/3oZTiwvijtoztmirdIQSuX7n0Z +cx91xor7v6PgQjck+x4k8dWB8rqfkhX0vaJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IWH15eL3tjS3zzQXBqIOkBimEHBSLB5/HwbHPyHIiRCWswmp7Urk7R8apAC8WeVyVz y0eZD4jsit7HUq6UNMYuKkmvalxhJ7S9c422/0ev16rtua4ja2BpMLNlU1HlZFRw1WJm ndpviV70ePxLLhkO2p2oZ4uPB0P2MqkMSf7ZE= MIME-Version: 1.0 Received: by 10.220.92.139 with SMTP id r11mr555780vcm.15.1239899489622; Thu, 16 Apr 2009 09:31:29 -0700 (PDT) Date: Thu, 16 Apr 2009 18:31:29 +0200 Message-ID: <99043b4a0904160931m74a46401u5d943c23f6afbdfa@mail.gmail.com> From: Matthew Cini Sarreo To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001636284c74a2f8a30467ae980d Subject: [IPsec] IKEv2: Moving Child SA traffic from an SA to a new SA when rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:30:18 -0000 --001636284c74a2f8a30467ae980d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, When rekeying an IKE SA, the traffic from the old (expiring) SA has to be moved to the new (rekeyed) SA. How does this go about? Are equivalent Child SAs created for the rekeyed IKE SA created and the ones in the old IKE SA deleted (by deleting the IKE SA), or is all data of the Child SA (SPIs, keys etc) copied as-is to the new SA. As a visual example: IKE SA A - Expiring IKE SA B - Rekeyed One Child SA New Child SA SPI (incoming) 0x12345678 SPI (incoming) 0xABCDEFAB Protocol AH Protocol AH Same cryptographic suite as A's Child SA or IKE SA A - Expiring IKE SA B - Rekeyed One Child SA Copy if Child SA from A SPI (incoming) 0x12345678 SPI (incoming) 0x12345678 Protocol AH Protocol AH Same cryptographic suite as A's Child SA (copied) >From section 2.8, "inherits Child SAs" seems to refer to the second case (copying) but I would like to be 100% sure that this is the case. Thanks for clarifications. Regards, Matthew --001636284c74a2f8a30467ae980d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SGVsbG8sPGJyPjxicj5XaGVuIHJla2V5aW5nIGFuIElLRSBTQSwgdGhlIHRyYWZmaWMgZnJvbSB0 aGUgb2xkIChleHBpcmluZykgU0EgaGFzIHRvIGJlIG1vdmVkIHRvIHRoZSBuZXcgKHJla2V5ZWQp IFNBLiBIb3cgZG9lcyB0aGlzIGdvIGFib3V0PyBBcmUgZXF1aXZhbGVudCBDaGlsZCBTQXMgY3Jl YXRlZCBmb3IgdGhlIHJla2V5ZWQgSUtFIFNBIGNyZWF0ZWQgYW5kIHRoZSBvbmVzIGluIHRoZSBv bGQgSUtFIFNBIGRlbGV0ZWQgKGJ5IGRlbGV0aW5nIHRoZSBJS0UgU0EpLCBvciBpcyBhbGwgZGF0 YSBvZiB0aGUgQ2hpbGQgU0EgKFNQSXMsIGtleXMgZXRjKSBjb3BpZWQgYXMtaXMgdG8gdGhlIG5l dyBTQS48YnI+Cjxicj5BcyBhIHZpc3VhbCBleGFtcGxlOjxicj48YnI+SUtFIFNBIEEgLSBFeHBp cmluZ6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgSUtFIFNBIEIgLSBSZWtleWVkPGJyPk9uZSBD aGlsZCBTQaCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgTmV3IENoaWxkIFNBPGJy PlNQSSAoaW5jb21pbmcpIDB4MTIzNDU2NzigoKCgoKCgoKCgoKCgoCBTUEkgKGluY29taW5nKSAw eEFCQ0RFRkFCPGJyPgpQcm90b2NvbCBBSKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoCBQcm90b2NvbCBBSDxicj6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKAgU2FtZSBjcnlwdG9ncmFwaGljIHN1aXRlIGFzIEEmIzM5O3MgQ2hp bGQgU0E8YnI+PGJyPm9yPGJyPjxicj5JS0UgU0EgQSAtIEV4cGlyaW5noKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoCBJS0UgU0EgQiAtIFJla2V5ZWQ8YnI+CgpPbmUgQ2hpbGQgU0GgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIENvcHkgaWYgQ2hpbGQgU0EgZnJvbSBBPGJyPgpTUEkg KGluY29taW5nKSAweDEyMzQ1Njc4oKCgoKCgoKCgoKCgoKAgU1BJIChpbmNvbWluZykgMHgxMjM0 NTY3ODxicj4KUHJvdG9jb2wgQUigoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg UHJvdG9jb2wgQUg8YnI+CqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoCBTYW1lIGNyeXB0b2dyYXBoaWMgc3VpdGUgYXMgQSYjMzk7cyBDaGlsZCBT QSAoY29waWVkKTxicj48YnI+RnJvbSBzZWN0aW9uIDIuOCwgJnF1b3Q7aW5oZXJpdHMgQ2hpbGQg U0FzJnF1b3Q7IHNlZW1zIHRvIHJlZmVyIHRvIHRoZSBzZWNvbmQgY2FzZSAoY29weWluZykgYnV0 IEkgd291bGQgbGlrZSB0byBiZSAxMDAlIHN1cmUgdGhhdCB0aGlzIGlzIHRoZSBjYXNlLjxicj4K PGJyPlRoYW5rcyBmb3IgY2xhcmlmaWNhdGlvbnMuPGJyPjxicj5SZWdhcmRzLDxicj5NYXR0aGV3 PGJyPgo8YnI+Cg== --001636284c74a2f8a30467ae980d-- From jsun2501@gmail.com Thu Apr 16 10:42:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6DD3A67B7 for ; Thu, 16 Apr 2009 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyIkpKUUpFFo for ; Thu, 16 Apr 2009 10:42:23 -0700 (PDT) Received: from ins2.sd.spawar.navy.mil (ins2.sd.spawar.navy.mil [IPv6:2001:480:10:4::3]) by core3.amsl.com (Postfix) with ESMTP id 289993A6802 for ; Thu, 16 Apr 2009 10:42:22 -0700 (PDT) Received: from pescado.nosc.mil (pescado.nosc.mil [128.49.4.90]) by ins2.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id n3GHhVI8025992 for ; Thu, 16 Apr 2009 10:43:34 -0700 Received: from [128.49.163.29] (sunjeff.sd.spawar.navy.mil [128.49.163.29]) by pescado.nosc.mil (Netscape Messaging Server 4.15) with ESMTP id KI7FWJ00.34W; Thu, 16 Apr 2009 10:43:31 -0700 Message-ID: <49E76E43.3040804@gmail.com> Date: Thu, 16 Apr 2009 10:43:31 -0700 From: "J. Sun" User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Matthew Cini Sarreo References: <99043b4a0904160931m74a46401u5d943c23f6afbdfa@mail.gmail.com> In-Reply-To: <99043b4a0904160931m74a46401u5d943c23f6afbdfa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2: Moving Child SA traffic from an SA to a new SA when rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:42:24 -0000 Matthew, It has to be Case #2. No where in the CREATE_CHILD_SA - IKE_SA Rekey exchange do you update to the other endpoint the new CHILD_SA SPIs - without exchanging the CHILD_SA SPIs, you'll most definitely run into interoperability issues, namely you'll start black holing traffic. As a result, it would be what you consider a copy. However, you shouldn't really think about it in that way. Depending on implementation, generally speaking - CHILD_SAs existing in a SAD would simply have an object that essentially references the parenting IKE_SA. After the successful IKE_SA Rekey, the CHILD_SA simply would update this object to simply point to its new parent, the rekeyed IKE_SA. But to qualify, it all really depends on implementation. - Jeff Sun Matthew Cini Sarreo wrote: > Hello, > > When rekeying an IKE SA, the traffic from the old (expiring) SA has to > be moved to the new (rekeyed) SA. How does this go about? Are > equivalent Child SAs created for the rekeyed IKE SA created and the > ones in the old IKE SA deleted (by deleting the IKE SA), or is all > data of the Child SA (SPIs, keys etc) copied as-is to the new SA. > > As a visual example: > > IKE SA A - Expiring IKE SA B - Rekeyed > One Child SA New Child SA > SPI (incoming) 0x12345678 SPI (incoming) 0xABCDEFAB > Protocol AH Protocol AH > Same > cryptographic suite as A's Child SA > > or > > IKE SA A - Expiring IKE SA B - Rekeyed > One Child SA Copy if Child SA from A > SPI (incoming) 0x12345678 SPI (incoming) 0x12345678 > Protocol AH Protocol AH > Same > cryptographic suite as A's Child SA (copied) > > From section 2.8, "inherits Child SAs" seems to refer to the second > case (copying) but I would like to be 100% sure that this is the case. > > Thanks for clarifications. > > Regards, > Matthew > > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vijay@wichorus.com Thu Apr 16 10:56:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DC53A6801 for ; Thu, 16 Apr 2009 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 mEPQOL99LaAO for ; Thu, 16 Apr 2009 10:56:05 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id F296D3A6917 for ; Thu, 16 Apr 2009 10:55:52 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id gD2n1b0180ldTLk5BHx6Tl; Thu, 16 Apr 2009 17:57:06 +0000 Received: from [10.166.254.159] ([99.51.129.145]) by OMTA04.westchester.pa.mail.comcast.net with comcast id gHwb1b00B38Mh0K3QHwgKQ; Thu, 16 Apr 2009 17:57:01 +0000 Message-ID: <49E77152.2020000@wichorus.com> Date: Thu, 16 Apr 2009 10:56:34 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Yoav Nir References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A141BF@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C780361332A141BF@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:56:06 -0000 Hello, Yoav Nir wrote: > I see that in section 6 the following: > > In such cases, the gateway should send the REDIRECT notification > payload in the final IKE_AUTH response message that carries the AUTH > payload and the traffic selectors. The gateway MUST NOT send and the > client MUST NOT accept a redirect in an earlier IKE_AUTH message. > > I like that, and that was my position earlier, but wasn't the conclusion at San Francisco that the REDIRECT could come in either the first AUTH response (where we know the ID the client is using, temporary or not) *OR* in the last response? The text you quote above refers to the case when the gateway decides to redirect based on the EAP exchange or a as a result of interaction with the AAA server or some external entity (when multiple auth is used). The redirect is done in the final IKE_AUTH message. > When did we decide to not allow it in the first resopnse? We allow it. The first paragraph in section 6 and the message exchange just below it show this. Vijay > > Other than that, I think the document is fine and ready for publication. > > Yaron Sheffer wrote: > >> This is a 2 week working group last call for >> draft-ietf-ipsecme-ikev2-redirect-08. The target status for >> this document is Proposed Standard. This is the document's >> second last call, following comments by a number of people >> and several document revisions. >> >> Please send your comments to the ipsec list by April 30, >> 2009, as follow-ups to this message. >> >> Please clearly indicate the position of any issue in the >> Internet Draft, and if possible provide alternative text. >> Please also indicate the nature or severity of the error or >> correction, e.g. major technical, minor technical, nit, so >> that we can quickly judge the extent of problems with the document. >> >> The document can be accessed here: >> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08. >> >> Thanks, >> Yaron > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Fri Apr 17 02:01:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441C73A6838 for ; Fri, 17 Apr 2009 02:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 LS-R4iQhj5Av for ; Fri, 17 Apr 2009 02:01:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 18D533A6814 for ; Fri, 17 Apr 2009 02:01:55 -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 n3H934S0005318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2009 12:03:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3H933NF022201; Fri, 17 Apr 2009 12:03: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: <18920.17863.406190.627466@fireball.kivinen.iki.fi> Date: Fri, 17 Apr 2009 12:03:03 +0300 From: Tero Kivinen To: "J. Sun" In-Reply-To: <49E76E43.3040804@gmail.com> References: <99043b4a0904160931m74a46401u5d943c23f6afbdfa@mail.gmail.com> <49E76E43.3040804@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" , Matthew Cini Sarreo Subject: Re: [IPsec] IKEv2: Moving Child SA traffic from an SA to a new SA when rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:01:57 -0000 J. Sun writes: > Matthew, > It has to be Case #2. No where in the CREATE_CHILD_SA - IKE_SA Rekey > exchange do you update to the other endpoint the new CHILD_SA SPIs - > without exchanging the CHILD_SA SPIs, you'll most definitely run into > interoperability issues, namely you'll start black holing traffic. As a > result, it would be what you consider a copy. However, you shouldn't > really think about it in that way. Depending on implementation, > generally speaking - CHILD_SAs existing in a SAD would simply have an > object that essentially references the parenting IKE_SA. After the > successful IKE_SA Rekey, the CHILD_SA simply would update this object to > simply point to its new parent, the rekeyed IKE_SA. But to qualify, it > all really depends on implementation. Actually it is more like of move, not copy, i.e. just like you explain in the end. There is no two copies of the same Child SA, there is only one, and that one has exactly one parent SA, i.e. either the old or new IKE SA, depending on where we are at the IKE SA rekey process. I.e. it is mostly: IKE SA A - Expiring IKE SA B - Rekeyed No Child SAs Moved Child SA from A all Childs are moved to new IKE SA SPI (incoming) 0x12345678 Protocol AH Same cryptographic suite as A's Child SA (moved) I.e. after that you MUST send all management traffic relating the Child SA using the new IKE SA B, you cannot use IKE SA A anymore for delete notifications or similar relating to the Child SA which was moved. Note, also that in case of the simultaneous rekeys, you need to move the Child SAs to the winning IKE SA. -- kivinen@iki.fi From mcins1@gmail.com Fri Apr 17 04:46:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E2D3A6D22 for ; Fri, 17 Apr 2009 04:46:36 -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 MxPgiZPkWF8I for ; Fri, 17 Apr 2009 04:46:36 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id E94693A69D8 for ; Fri, 17 Apr 2009 04:46:35 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so789178qwb.31 for ; Fri, 17 Apr 2009 04:47:49 -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; bh=4DVPwtcfSrwk6WtJOpO0pbLfcjvKolJN1G0PPU9xcvE=; b=byOmi4oEpK2j+1TzIX8/S/PsaNGZ/UajEo8XpwKWJzVr25d2yh2sHFp4D61xpHFyk1 Woxl97ddP+Ajv+CDYVhBEPgJ0zrUHDMlhOaXBKKg5vmDS/AuOh7aw8V9Sup+73GA2UVY ScaC1JqZYsMfN60C541rzPctQY6s6Elpa7PCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uVYtsqpZpoLghbP2LHFygvvgARu7fbJBF+cK3DpuePJsgeC7iOpF/fST2kPFHrbHda Dusrw5MHkdO03nJrPWmMNYiUV7gJtsQqpgMxpQtYmudu3RSlIPAsc35rwFynOh7aKs77 2uMCtRLissQFOa39LcxbnFZk5MeuSYBoUsfrs= MIME-Version: 1.0 Received: by 10.220.95.202 with SMTP id e10mr2643320vcn.12.1239968868954; Fri, 17 Apr 2009 04:47:48 -0700 (PDT) Date: Fri, 17 Apr 2009 13:47:48 +0200 Message-ID: <99043b4a0904170447x39bd0e0do4ecf07dd16ca7a3d@mail.gmail.com> From: Matthew Cini Sarreo To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016e64eacb4f770fe0467bebfa8 Subject: [IPsec] IKEv2: Ambiguous REKEY_SA text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:46:36 -0000 --0016e64eacb4f770fe0467bebfa8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, When reading section 2.8.3. Rekeying the IKE SA Versus Reauthentication: "IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads)," seems to indicate (at least, when one reads this for the first time) that rekeying an IKE SA will include a notify payload containing REKEY_SA but this seems to be incorrect as nowhere in the text it is stated that rekeying an IKE SA would include a REKEY_SA notify payload. Regards, Matt --0016e64eacb4f770fe0467bebfa8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

When reading section 2.8.3. Rekeying the IKE SA Versus Reaut= hentication:

"IKEv2 does not have any special support for reaut= hentication. Reauthentication is done by creating a new IKE SA from scratch= (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payload= s),"

seems to indicate (at least, when one reads this for the first time) th= at rekeying an IKE SA will include a notify payload containing REKEY_SA but= this seems to be incorrect as nowhere in the text it is stated that rekeyi= ng an IKE SA would include a REKEY_SA notify payload.

Regards,
Matt
--0016e64eacb4f770fe0467bebfa8-- From ynir@checkpoint.com Sat Apr 18 11:15:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B133A696E for ; Sat, 18 Apr 2009 11:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJdburdpQVaT for ; Sat, 18 Apr 2009 11:15:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 082233A6E2E for ; Sat, 18 Apr 2009 11:15:03 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 766D430C001; Sat, 18 Apr 2009 21:16:17 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 307BF2CC003; Sat, 18 Apr 2009 21:16:17 +0300 (IDT) X-CheckPoint: {49EA1566-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 n3IIGGqO028239; Sat, 18 Apr 2009 21:16:16 +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; Sat, 18 Apr 2009 21:16:16 +0300 From: Yoav Nir To: Vijay Devarapalli Date: Sat, 18 Apr 2009 21:16:15 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: Acm+vML0AFae3BYLTCO7DlQcE/OongBk35+i Message-ID: <9FB7C7CE79B84449B52622B506C78036133291CB91@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361332A141BF@il-ex01.ad.checkpoint.com>, <49E77152.2020000@wichorus.com> In-Reply-To: <49E77152.2020000@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 18:15:05 -0000 Vijay Devarapalli wrote: > > Hello, >=20 > Yoav Nir wrote: > > I see that in section 6 the following: > > > > In such cases, the gateway should send the REDIRECT notification > > payload in the final IKE_AUTH response message that carries the AUTH > > payload and the traffic selectors. The gateway MUST NOT send and th= e > > client MUST NOT accept a redirect in an earlier IKE_AUTH message. > > > > I like that, and that was my position earlier, but wasn't the conclusio= n at=20 > > San Francisco that the REDIRECT could come in either the first AUTH=20 > > response (where we know the ID the client is using, temporary or not)=20 > > *OR* in the last response? > > The text you quote above refers to the case when the gateway decides to > redirect based on the EAP exchange or a as a result of interaction with > the AAA server or some external entity (when multiple auth is used). The > redirect is done in the final IKE_AUTH message. > > > When did we decide to not allow it in the first resopnse? > > We allow it. The first paragraph in section 6 and the message exchange > just below it show this. > > Vijay The first paragraph refers to the non-EAP case. The paragraph I quoted=20 is the one that refers to the EAP case, and this is the case where it makes= =20 sense to allow the REDIRECT both in the first and last IKE_AUTH=20 responses.=20 The case for the last response is the one that you made: The AAA server may tell the gateway to send the user to another gateway. The case for the first response is a little different. The content of the I= Di=20 payload tells the gateway to what domain the user belongs. "Domain"=20 could map to a specific AAA server, and/or to a specific gateway. Suppose a user connects to gateway-A with the IDi payload containing "jdoe@companyB.com". This is enough to tell the gateway that the user should use gateway-B instead - policy says that all companyB=20 employees connect to the gateway-B. Or maybe the user is=20 "jdoe@company.it" and all such users should connect to the gateway in Italy. In both cases there is no point in authenticating to the local AAA server. The gateway knows immediately to send the user to the=20 appropriate gateway. That is why I think (and I believe that was the conclusion in SF) that the REDIRECT may come in both the first and last responses. Yoav = Email secured by Check Point From vijay@wichorus.com Sun Apr 19 20:43:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824683A6C8D for ; Sun, 19 Apr 2009 20:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 O2rZ68qN-kjU for ; Sun, 19 Apr 2009 20:43:44 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id A381A3A6D0F for ; Sun, 19 Apr 2009 20:43:44 -0700 (PDT) Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Apr 2009 03:44:55 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 19 Apr 2009 20:44:55 -0700 From: Vijay Devarapalli To: Yoav Nir Message-ID: Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: Acm+vML0AFae3BYLTCO7DlQcE/OongBk35+iAEaHOK0= In-Reply-To: <9FB7C7CE79B84449B52622B506C78036133291CB91@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 03:43:45 -0000 Hi, On 4/18/09 11:16 AM, "Yoav Nir" wrote: > Vijay Devarapalli wrote: >> >> Hello, >> >> Yoav Nir wrote: >>> I see that in section 6 the following: >>> >>> In such cases, the gateway should send the REDIRECT notification >>> payload in the final IKE_AUTH response message that carries the AUTH >>> payload and the traffic selectors. The gateway MUST NOT send and the >>> client MUST NOT accept a redirect in an earlier IKE_AUTH message. >>> >>> I like that, and that was my position earlier, but wasn't the conclusion at >>> San Francisco that the REDIRECT could come in either the first AUTH >>> response (where we know the ID the client is using, temporary or not) >>> *OR* in the last response? >> >> The text you quote above refers to the case when the gateway decides to >> redirect based on the EAP exchange or a as a result of interaction with >> the AAA server or some external entity (when multiple auth is used). The >> redirect is done in the final IKE_AUTH message. >> >>> When did we decide to not allow it in the first resopnse? >> >> We allow it. The first paragraph in section 6 and the message exchange >> just below it show this. >> >> Vijay > > The first paragraph refers to the non-EAP case. The paragraph I quoted > is the one that refers to the EAP case, and this is the case where it makes > sense to allow the REDIRECT both in the first and last IKE_AUTH > responses. > > The case for the last response is the one that you made: The AAA server > may tell the gateway to send the user to another gateway. > > The case for the first response is a little different. The content of the IDi > payload tells the gateway to what domain the user belongs. "Domain" > could map to a specific AAA server, and/or to a specific gateway. > > Suppose a user connects to gateway-A with the IDi payload containing > "jdoe@companyB.com". This is enough to tell the gateway that the > user should use gateway-B instead - policy says that all companyB > employees connect to the gateway-B. Or maybe the user is > "jdoe@company.it" and all such users should connect to the gateway > in Italy. In both cases there is no point in authenticating to the local > AAA server. The gateway knows immediately to send the user to the > appropriate gateway. > > That is why I think (and I believe that was the conclusion in SF) that > the REDIRECT may come in both the first and last responses. Ok, got it. Redirect in the first IKE_AUTH response is always allowed, even if there is an EAP exchange. I will clarify it in the next revision. Vijay > > Yoav > > Email secured by Check Point From mcins1@gmail.com Mon Apr 20 00:08:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F83D3A69F6 for ; Mon, 20 Apr 2009 00:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 CfVfqjQbgqx5 for ; Mon, 20 Apr 2009 00:08:36 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id D5C0B3A68FC for ; Mon, 20 Apr 2009 00:08:35 -0700 (PDT) Received: by qyk42 with SMTP id 42so2186995qyk.29 for ; Mon, 20 Apr 2009 00:09:51 -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=LhIchqWBpdCh1cXdURwhq1f2mGU2uzKE4TRmeoD0vGo=; b=c3f2YUPbAil1j9mfiJEst8IL4V4D8evR0bdWKhzB2kTdPXrl3MhT4JriRa5G/JasLc BMTEeHAiwBWGzq6/rSpaXUCcARvUu80uDajT8q8P+JC1DrTpX29/AjkSAHu1BRNvk4KG 9rGLgUDxnQykAVbL8Tndhti1xYxZYJZFX48tg= 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=bBAymVBSNtMispo55g8cgCIwf4v3NCdAFMIvwvsl2y+vrsdCJHxC5g35+4cOX772LJ tEeuA+pqduSrYkLlyN0bkO9vvGIBPlLRcATX6Bz8RxJPOiuZtw4A5BXOzH4S8D8j4y6C YNkoWytv+I09tHOWyL3llihgmJKm1ywCXYQ7s= MIME-Version: 1.0 Received: by 10.220.73.203 with SMTP id r11mr5350093vcj.61.1240211390946; Mon, 20 Apr 2009 00:09:50 -0700 (PDT) Date: Mon, 20 Apr 2009 09:09:50 +0200 Message-ID: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> From: Matthew Cini Sarreo To: "ipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] IKEv2 INVALID_MESSAGE_ID X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:08:36 -0000 If an implementation decides to send the INVALID_MESSAGE_ID notification, shoild it ONLY send this after an IKE_AUTH exchange has been completed? It seems to be so as section 2.3 states that an INFORMATIONAL exchange is started, but it is not clear what should be done if a message of the two initial exchanges has an invalid message id (an implementation should always use 0 for IKE_SA_INIT and 1 for IKE_AUTH, but what if this does not happen?) Regards, Matt From ynir@checkpoint.com Mon Apr 20 00:26:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CE63A68FB for ; Mon, 20 Apr 2009 00:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 UJ50-WNdFRza for ; Mon, 20 Apr 2009 00:26:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CC5843A67D1 for ; Mon, 20 Apr 2009 00:26:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7EB4830C004; Mon, 20 Apr 2009 10:27:51 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 447842CC001; Mon, 20 Apr 2009 10:27:51 +0300 (IDT) X-CheckPoint: {49EC2050-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 n3K7RoqO017772; Mon, 20 Apr 2009 10:27:50 +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; Mon, 20 Apr 2009 10:27:50 +0300 From: Yoav Nir To: Vijay Devarapalli Date: Mon, 20 Apr 2009 10:29:44 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: Acm+vML0AFae3BYLTCO7DlQcE/OongBk35+iAEaHOK0AB2br4A== Message-ID: <9FB7C7CE79B84449B52622B506C78036133859761B@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036133291CB91@il-ex01.ad.checkpoint.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: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:26:39 -0000 Hi Come to think of it, I'm wondering about something else. Let's suppose that the gateway cannot tell where the user should connect. T= he EAP exchange with the AAA server begins. The AAA server realizes that th= e user name ("jdoe") is not in its database, and the user should be redirec= ted to gateway B. What now? Does it complete the exchange successfully, and redirect? Or do= es it fail the exchange and redirect? I think the obvious answer is to fail the exchange and redirect. I think w= e should mandate that even with EAP failure, the client should honor the RE= DIRECT. If the gateway authentication fails (the AUTH payload in the first IKE_AUTH= response fails to authenticate) then I'm not sure what the right action is= . REDIRECT is accepted in an unauthenticated INITIAL exchange. Why not, th= en, in a failed authentication IKE_AUTH exchange? Vijay Devarapalli wrote:=20 > Hi, >=20 > On 4/18/09 11:16 AM, "Yoav Nir" wrote: >=20 > > Vijay Devarapalli wrote: > >>=20 > >> Hello, > >>=20 > >> Yoav Nir wrote: > >>> I see that in section 6 the following: > >>>=20 > >>> In such cases, the gateway should send the REDIRECT=20 > notification > >>> payload in the final IKE_AUTH response message that=20 > carries the AUTH > >>> payload and the traffic selectors. The gateway MUST=20 > NOT send and the > >>> client MUST NOT accept a redirect in an earlier=20 > IKE_AUTH message. > >>>=20 > >>> I like that, and that was my position earlier, but wasn't the=20 > >>> conclusion at San Francisco that the REDIRECT could come=20 > in either=20 > >>> the first AUTH response (where we know the ID the client=20 > is using,=20 > >>> temporary or not) > >>> *OR* in the last response? > >>=20 > >> The text you quote above refers to the case when the=20 > gateway decides=20 > >> to redirect based on the EAP exchange or a as a result of=20 > interaction=20 > >> with the AAA server or some external entity (when multiple auth is=20 > >> used). The redirect is done in the final IKE_AUTH message. > >>=20 > >>> When did we decide to not allow it in the first resopnse? > >>=20 > >> We allow it. The first paragraph in section 6 and the message=20 > >> exchange just below it show this. > >>=20 > >> Vijay > >=20 > > The first paragraph refers to the non-EAP case. The=20 > paragraph I quoted=20 > > is the one that refers to the EAP case, and this is the=20 > case where it=20 > > makes sense to allow the REDIRECT both in the first and=20 > last IKE_AUTH=20 > > responses. > >=20 > > The case for the last response is the one that you made: The AAA=20 > > server may tell the gateway to send the user to another gateway. > >=20 > > The case for the first response is a little different. The=20 > content of=20 > > the IDi payload tells the gateway to what domain the user=20 > belongs. "Domain" > > could map to a specific AAA server, and/or to a specific gateway. > >=20 > > Suppose a user connects to gateway-A with the IDi payload=20 > containing=20 > > "jdoe@companyB.com". This is enough to tell the gateway=20 > that the user=20 > > should use gateway-B instead - policy says that all=20 > companyB employees=20 > > connect to the gateway-B. Or maybe the user is=20 > "jdoe@company.it" and=20 > > all such users should connect to the gateway > > in Italy. In both cases there is no point in=20 > authenticating to the local > > AAA server. The gateway knows immediately to send the user to the=20 > > appropriate gateway. > >=20 > > That is why I think (and I believe that was the conclusion=20 > in SF) that=20 > > the REDIRECT may come in both the first and last responses. >=20 > Ok, got it. Redirect in the first IKE_AUTH response is always=20 > allowed, even if there is an EAP exchange. I will clarify it=20 > in the next revision. >=20 > Vijay >=20 > >=20 > > Yoav Email secured by Check Point From yaronf@checkpoint.com Mon Apr 20 00:42:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9103A6912 for ; Mon, 20 Apr 2009 00:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 3EXmsVM-NTUa for ; Mon, 20 Apr 2009 00:42:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3B7843A67D1 for ; Mon, 20 Apr 2009 00:42:08 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 13AB630C006; Mon, 20 Apr 2009 10:43:23 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C762D2CC001; Mon, 20 Apr 2009 10:43:22 +0300 (IDT) X-CheckPoint: {49EC23F3-2-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 n3K7h6qT022221; Mon, 20 Apr 2009 10:43:22 +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; Mon, 20 Apr 2009 10:43:08 +0300 From: Yaron Sheffer To: Yoav Nir , Vijay Devarapalli Date: Mon, 20 Apr 2009 10:43:05 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: Acm+vML0AFae3BYLTCO7DlQcE/OongBk35+iAEaHOK0AB2br4AAAoz7Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4BE2@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036133291CB91@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036133859761B@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036133859761B@il-ex01.ad.checkpoint.com> 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_007F_01C9C1A4.C9914D30" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:42:10 -0000 ------=_NextPart_000_007F_01C9C1A4.C9914D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Below. > -----Original Message----- > From: Yoav Nir > Sent: Monday, April 20, 2009 10:30 > To: Vijay Devarapalli > Cc: Yaron Sheffer; IPsecme WG > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 > > Hi > > Come to think of it, I'm wondering about something else. > > Let's suppose that the gateway cannot tell where the user should connect. > The EAP exchange with the AAA server begins. The AAA server realizes that > the user name ("jdoe") is not in its database, and the user should be > redirected to gateway B. > > What now? Does it complete the exchange successfully, and redirect? Or > does it fail the exchange and redirect? > > I think the obvious answer is to fail the exchange and redirect. I think > we should mandate that even with EAP failure, the client should honor the > REDIRECT. > > If the gateway authentication fails (the AUTH payload in the first > IKE_AUTH response fails to authenticate) then I'm not sure what the right > action is. REDIRECT is accepted in an unauthenticated INITIAL exchange. > Why not, then, in a failed authentication IKE_AUTH exchange? > [YS] No, failing authentication is different from being unauthenticated. The client may have a policy that says that it's willing to be redirected at IKE_SA_INIT. But if it receives an AUTH value that is explicitly untrusted (say, with a revoked certificate), I think it should not act on it. Even though a malicious gateway could have responded in the first exchange etc. etc. Also note that it may be hard to untangle client authentication from gateway authentication, e.g. when using symmetric password authentication such as EAP-EKE . > Vijay Devarapalli wrote: > > > Hi, > > > > On 4/18/09 11:16 AM, "Yoav Nir" wrote: > > > > > Vijay Devarapalli wrote: > > >> > > >> Hello, > > >> > > >> Yoav Nir wrote: > > >>> I see that in section 6 the following: > > >>> > > >>> In such cases, the gateway should send the REDIRECT > > notification > > >>> payload in the final IKE_AUTH response message that > > carries the AUTH > > >>> payload and the traffic selectors. The gateway MUST > > NOT send and the > > >>> client MUST NOT accept a redirect in an earlier > > IKE_AUTH message. > > >>> > > >>> I like that, and that was my position earlier, but wasn't the > > >>> conclusion at San Francisco that the REDIRECT could come > > in either > > >>> the first AUTH response (where we know the ID the client > > is using, > > >>> temporary or not) > > >>> *OR* in the last response? > > >> > > >> The text you quote above refers to the case when the > > gateway decides > > >> to redirect based on the EAP exchange or a as a result of > > interaction > > >> with the AAA server or some external entity (when multiple auth is > > >> used). The redirect is done in the final IKE_AUTH message. > > >> > > >>> When did we decide to not allow it in the first resopnse? > > >> > > >> We allow it. The first paragraph in section 6 and the message > > >> exchange just below it show this. > > >> > > >> Vijay > > > > > > The first paragraph refers to the non-EAP case. The > > paragraph I quoted > > > is the one that refers to the EAP case, and this is the > > case where it > > > makes sense to allow the REDIRECT both in the first and > > last IKE_AUTH > > > responses. > > > > > > The case for the last response is the one that you made: The AAA > > > server may tell the gateway to send the user to another gateway. > > > > > > The case for the first response is a little different. The > > content of > > > the IDi payload tells the gateway to what domain the user > > belongs. "Domain" > > > could map to a specific AAA server, and/or to a specific gateway. > > > > > > Suppose a user connects to gateway-A with the IDi payload > > containing > > > "jdoe@companyB.com". This is enough to tell the gateway > > that the user > > > should use gateway-B instead - policy says that all > > companyB employees > > > connect to the gateway-B. Or maybe the user is > > "jdoe@company.it" and > > > all such users should connect to the gateway > > > in Italy. In both cases there is no point in > > authenticating to the local > > > AAA server. The gateway knows immediately to send the user to the > > > appropriate gateway. > > > > > > That is why I think (and I believe that was the conclusion > > in SF) that > > > the REDIRECT may come in both the first and last responses. > > > > Ok, got it. Redirect in the first IKE_AUTH response is always > > allowed, even if there is an EAP exchange. I will clarify it > > in the next revision. > > > > Vijay > > > > > > > > Yoav ------=_NextPart_000_007F_01C9C1A4.C9914D30 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMDA3NDMwNVowIwYJKoZIhvcNAQkEMRYEFAep3WHp4CPB RRoiZ8uvA2MZsG9qMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Hq26apjPwdARuUJhGZpWt7kiavgBwa/Nck33BPVzWP1IYtN9LhMyiqO4u/OeJOrMDfV4JfLM7FXc OWwPQyguzPU5028Kqr/WTAUx+6sSeX41v2LjB0GPoZ57lo1zMWQvjla/6J3QHltYcuMR3qxHrydR dzcdwt6tERPrSjHgGzunYmvqLVUHbEz9OUNEMp7EJW7O3jYNLaOOtCDv/3NOgbv/U1IA5ftOzpfD HS0a/VyNFc9+5jwZchnpBplkCDzTPTYo1V/jl+JSNoTRxZNcstOe3IiM9ufuRsePHjipH2Lv+Y41 yzbhaMglcQfze8yr1Pw1nNfnB6oYYKj/QZNOsgAAAAAAAA== ------=_NextPart_000_007F_01C9C1A4.C9914D30-- From ynir@checkpoint.com Mon Apr 20 00:45:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A41B3A69FD for ; Mon, 20 Apr 2009 00:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 Lq0sL3MgNsi4 for ; Mon, 20 Apr 2009 00:45:16 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 75D0A3A6884 for ; Mon, 20 Apr 2009 00:45:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E81F30C005; Mon, 20 Apr 2009 10:46:31 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 61EFE2CC001; Mon, 20 Apr 2009 10:46:31 +0300 (IDT) X-CheckPoint: {49EC24B0-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 n3K7kUqO023291; Mon, 20 Apr 2009 10:46:31 +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; Mon, 20 Apr 2009 10:46:30 +0300 From: Yoav Nir To: Matthew Cini Sarreo , "ipsec@ietf.org" Date: Mon, 20 Apr 2009 10:48:25 +0300 Thread-Topic: [IPsec] IKEv2 INVALID_MESSAGE_ID Thread-Index: AcnBhwQY+eKebJvXQdWrdmaWXIPkEwABMmaw Message-ID: <9FB7C7CE79B84449B52622B506C780361338597629@il-ex01.ad.checkpoint.com> References: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> In-Reply-To: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] IKEv2 INVALID_MESSAGE_ID X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:45:17 -0000 Hi Matt. You can't initiate INFORMATIONAL exchanges before the IKE_AUTH exchange(s) = concluded successfully.=20 Section 2.3 prohibits sending INVALID_MESSAGE_ID in responses, so you don't= use that for the IKE_AUTH exchange. If the IKE_AUTH exchange contains invalid message IDs, these requests MUST = be ignored. I don't think you ever begin to use the message window until af= ter the IKE_AUTH exchange, and INVALID_MESSAGE_ID is not some kind of MALFO= RMED_PACKET. It's specifically to tell the other side about window problems= . Hope this helps Yoav > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Matthew Cini Sarreo > Sent: Monday, April 20, 2009 10:10 AM > To: ipsec@ietf.org > Subject: [IPsec] IKEv2 INVALID_MESSAGE_ID >=20 > If an implementation decides to send the INVALID_MESSAGE_ID=20 > notification, shoild it ONLY send this after an IKE_AUTH=20 > exchange has been completed? It seems to be so as section 2.3=20 > states that an INFORMATIONAL exchange is started, but it is=20 > not clear what should be done if a message of the two initial=20 > exchanges has an invalid message id (an implementation should=20 > always use 0 for IKE_SA_INIT and 1 for IKE_AUTH, but what if=20 > this does not happen?) >=20 Email secured by Check Point From yaronf@checkpoint.com Mon Apr 20 02:32:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FFA3A6E9A for ; Mon, 20 Apr 2009 02:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 7JrZFBvsgnGa for ; Mon, 20 Apr 2009 02:32:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 34BA83A6ECF for ; Mon, 20 Apr 2009 02:32:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D593D30C005; Mon, 20 Apr 2009 12:33:57 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8D4702CC001; Mon, 20 Apr 2009 12:33:57 +0300 (IDT) X-CheckPoint: {49EC3DDC-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 n3K9XuqO026700; Mon, 20 Apr 2009 12:33:57 +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; Mon, 20 Apr 2009 12:33:56 +0300 From: Yaron Sheffer To: Matthew Cini Sarreo , "ipsec@ietf.org" Date: Mon, 20 Apr 2009 12:33:55 +0300 Thread-Topic: [IPsec] IKEv2: Ambiguous REKEY_SA text Thread-Index: Acm/Ult9KLZkcwn1RdulrGTtPVxVJwCSHNQA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4C47@il-ex01.ad.checkpoint.com> References: <99043b4a0904170447x39bd0e0do4ecf07dd16ca7a3d@mail.gmail.com> In-Reply-To: <99043b4a0904170447x39bd0e0do4ecf07dd16ca7a3d@mail.gmail.com> 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_00B9_01C9C1B4.44DF2AC0" MIME-Version: 1.0 Subject: Re: [IPsec] IKEv2: Ambiguous REKEY_SA text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 09:32:44 -0000 ------=_NextPart_000_00B9_01C9C1B4.44DF2AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00BA_01C9C1B4.44DF2AC0" ------=_NextPart_001_00BA_01C9C1B4.44DF2AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Matt, Please see Sec. 1.3.3 of draft-ietf-ipsecme-ikev2bis-02. I believe it answers your question. Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Matthew Cini Sarreo Sent: Friday, April 17, 2009 14:48 To: ipsec@ietf.org Subject: [IPsec] IKEv2: Ambiguous REKEY_SA text Hello, When reading section 2.8.3. Rekeying the IKE SA Versus Reauthentication: "IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads)," seems to indicate (at least, when one reads this for the first time) that rekeying an IKE SA will include a notify payload containing REKEY_SA but this seems to be incorrect as nowhere in the text it is stated that rekeying an IKE SA would include a REKEY_SA notify payload. Regards, Matt ------=_NextPart_001_00BA_01C9C1B4.44DF2AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Matt,

 

Please see Sec. 1.3.3 of = draft-ietf-ipsecme-ikev2bis-02. I believe it answers your question.

 

Thanks,

=

      =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Matthew Cini = Sarreo
Sent: Friday, April 17, = 2009 14:48
To: ipsec@ietf.org
Subject: [IPsec] IKEv2: = Ambiguous REKEY_SA text

 

Hello,

When reading section 2.8.3. Rekeying the IKE SA Versus = Reauthentication:

"IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify = payloads),"

seems to indicate (at least, when one reads this for the first time) = that rekeying an IKE SA will include a notify payload containing REKEY_SA but = this seems to be incorrect as nowhere in the text it is stated that rekeying = an IKE SA would include a REKEY_SA notify payload.

Regards,
Matt

------=_NextPart_001_00BA_01C9C1B4.44DF2AC0-- ------=_NextPart_000_00B9_01C9C1B4.44DF2AC0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMDA5MzM1NVowIwYJKoZIhvcNAQkEMRYEFNzP0afdvqtk BJIyPNmd9IACzGQ/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Javtu5NaGLZnXVpiuASyzrhHfHu1BRqAzftayw0DFOL4Z0vxd/44ZRgnA1gj+uoGnWCP0DLgh8z/ XIQGYi4UPUwYW9VcRMr0XDeesEvNxvPpenWQ0+smN6u3lpIGKqIiThRO16EXvkwF+mQzRjZDg6f3 Bt0/3f41CCyZqOqGuwKXfwAa0sqAQzGxjlqiUdY6Q+679VAof8fKJgXLxRntdFGxt4wOCWSWxJpl TYX0rBKH6EvQhMT0PhoPAmca/i2nfPl41aaO5MirXMThEOmkEmL1WIoMw8Jg8qY1hd/qNm1HKlOK i6RQUzfSTGlgOI4sAlHZhJAQE5Tk0rHqFD7PpgAAAAAAAA== ------=_NextPart_000_00B9_01C9C1B4.44DF2AC0-- From paul.hoffman@vpnc.org Mon Apr 20 10:14:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D203A69DF for ; Mon, 20 Apr 2009 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 hwJ2zonpGXG6 for ; Mon, 20 Apr 2009 10:14:43 -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 673FC3A696F for ; Mon, 20 Apr 2009 10:14:43 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3KHFuHX068743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Apr 2009 10:15:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 20 Apr 2009 10:15:55 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 17:14:44 -0000 Greetings again. Of the people who replied, two favored mandating two round trips, and one favored keeping the current one round trip. That (anemic) result, plus the comment that lead to this thread, leads me to say that we need to change draft-ietf-ipsecme-ikev2-resumption to require two round trips. Draft authors: please prepare a -03 with only the two-round-trip solution, and pull out the text about the one-round-trip option. If someone really objects to this, please prepare a personal Internet Draft that lists exactly how you would change the current -03 draft to cover all the security issues that were brought forward. --Paul Hoffman, Director --VPN Consortium From ldondeti@qualcomm.com Mon Apr 20 10:44:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA4B3A6E20 for ; Mon, 20 Apr 2009 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.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 umfoqCj4qYFf for ; Mon, 20 Apr 2009 10:44:44 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id EE9D33A67D4 for ; Mon, 20 Apr 2009 10:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240249560; x=1271785560; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49ECB4D1.4040306@qualcomm.com>|Date:=20Mo n,=2020=20Apr=202009=2023:15:53=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Paul=20Hoffman=20|CC:=20IPsecme=20WG=20 |Subject:=20Re:=20[IPsec]=20Issue=20#98:=201=20or=20two =20round=20trips=20for=20resumption|References:=20=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3DIS O-8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5590 "=3B=20a=3D"17275867"; bh=4cETa2A5EYKKE+gBC4Vymwqkab4D/E7UvhB9fJnhTog=; b=VRZis/3oqI0Xs0YaBwBR2sNseEPtuM0a6O8njpXzbrle2K8Ab3mXrKwz e8WEVNAdxdjb+O3XpVYrt64QzgVLJegTMEAm6h2fQIwZNsHFhfJ66u/rv F4KTUDJ+qwhDwO4QqnSVt467HkdpNYwE9gnY5tI6Gte3rTZRATm4XwlIf w=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17275867" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 10:45:59 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KHjx9L011579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 10:45:59 -0700 Received: from [10.50.72.84] (qconnect-10-50-72-84.qualcomm.com [10.50.72.84]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KHjssS009762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2009 10:45:58 -0700 Message-ID: <49ECB4D1.4040306@qualcomm.com> Date: Mon, 20 Apr 2009 23:15:53 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 17:44:45 -0000 Paul, Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with? Let me help you out. It is not really applicable. Here is why: RFC 3552 says that "While it is not a requirement that any given protocol or system be immune to all forms of attack, it is still necessary for authors to consider as many forms as possible. Part of the purpose of the Security Considerations section is to explain what attacks are out of scope and what countermeasures can be applied to defend against them. In" That poorly written and poorly edited RFC (notice the dangling "In") is all we have as guidance unfortunately. What it does say is that it is perfectly fine to specify what attacks are out of scope. We cannot have someone noting that "auditors" will force large installations to do this or that and have that dictate using a grossly inefficient resumption protocol! It begs that questions of who those auditors are, what jurisdiction they are operating under and assuming what threat model? The IKEv2 RFC really defines what is in scope. Server state exhaustion attacks are not in scope for being mandatorily made "more difficult" for some definition of more. Finally, if we don't like options, we are in the wrong standards body! When we design a security protocol for a variety of threat models and performance constraints, we are bound to have options. Thank you. best regards, Lakshminath On 4/20/2009 10:45 PM, Paul Hoffman wrote: > > > Greetings again. Of the people who replied, two favored mandating two > round trips, and one favored keeping the current one round trip. That > (anemic) result, plus the comment that lead to this thread, leads me > to say that we need to change draft-ietf-ipsecme-ikev2-resumption to > require two round trips. > > Draft authors: please prepare a -03 with only the two-round-trip > solution, and pull out the text about the one-round-trip option. > > If someone really objects to this, please prepare a personal Internet > Draft that lists exactly how you would change the current -03 draft > to cover all the security issues that were brought forward. > > --Paul Hoffman, Director --VPN Consortium > _______________________________________________ IPsec mailing list > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Mon Apr 20 11:19:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DAB3A6E23 for ; Mon, 20 Apr 2009 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 UUmfyg0qjBrw for ; Mon, 20 Apr 2009 11:19:44 -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 105093A6FD3 for ; Mon, 20 Apr 2009 11:19:43 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3KIKu9m073290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2009 11:20:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <49ECB4D1.4040306@qualcomm.com> References: <49ECB4D1.4040306@qualcomm.com> Date: Mon, 20 Apr 2009 11:20:55 -0700 To: Lakshminath Dondeti From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 18:19:45 -0000 At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: >Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with? No, I can summarize it after it is deleted, given that I deleted it in my last message. The security issues that Pasi sent to the mailing list over a month ago include: - A replay of a ticket can cause exhaustion of many resources, not just CPU or state on the gateway. Pasi listed these about a month ago. - A replay of a ticket can cause a legitimate resumption to fail, depending on the algorithms used in the IKE SA. This is unrelated to your, um, interesting logic about RFC 3552. The WG can decide its threat models as it sees fit. >The IKEv2 RFC really defines what is in scope. Server state exhaustion attacks are not in scope for being mandatorily made "more difficult" for some definition of more. I don't see anything in RFC 4306 that limits the scope of the threat models for extensions. --Paul Hoffman, Director --VPN Consortium From ldondeti@qualcomm.com Mon Apr 20 12:07:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F2C3A6A8D for ; Mon, 20 Apr 2009 12:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 oUMOXjbRdEZc for ; Mon, 20 Apr 2009 12:07:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id ED7253A681D for ; Mon, 20 Apr 2009 12:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240254496; x=1271790496; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49ECC81A.4050308@qualcomm.com>|Date:=20Tu e,=2021=20Apr=202009=2000:38:10=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Paul=20Hoffman=20|CC:=20IPsecme=20WG=20 |Subject:=20Re:=20[IPsec]=20Issue=20#98:=201=20or=20two =20round=20trips=20for=20resumption|References:=20=09=20<49ECB4D1.4040306@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/plain =3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5590"=3B=20a=3D"17267090"; bh=6vZ0UVbSM1sUj37lFujXCcGWhwI0yi97qOgkpklV7XA=; b=tWuz2GIGkhvcEdgtjexKzLkIODyhqDn2YLw6/4vk1i0s3Pj0S/uV72HY F3wauWWtItuzuJyphpJeTXKB0vf5txUXisBVrQWYOjl/PAKCIaTS94kCo C2BCcfqiMNktduYHp6hkgBOhxU8C/dHCgZoNMCbqR/Hge0BTAE/8UuInC U=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17267090" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 12:08:15 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KJ8Fbx005727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 12:08:15 -0700 Received: from [10.50.72.84] (qconnect-10-50-72-84.qualcomm.com [10.50.72.84]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KJ8Bxr025986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2009 12:08:14 -0700 (PDT) Message-ID: <49ECC81A.4050308@qualcomm.com> Date: Tue, 21 Apr 2009 00:38:10 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Paul Hoffman References: <49ECB4D1.4040306@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:07:01 -0000 On 4/20/2009 11:50 PM, Paul Hoffman wrote: > At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: >> Before the one roundtrip mechanism is deleted, could you summarize >> how the security issue that was raised is applicable under the >> threat model we work with? > > No, I can summarize it after it is deleted, given that I deleted it > in my last message. > > The security issues that Pasi sent to the mailing list over a month > ago include: > > - A replay of a ticket can cause exhaustion of many resources, not > just CPU or state on the gateway. Pasi listed these about a month > ago. That was some interesting logic based on a fictional deployment. Are we to optimize specifically for Pasi's vision of deploying networks? > > - A replay of a ticket can cause a legitimate resumption to fail, > depending on the algorithms used in the IKE SA. > > This is unrelated to your, um, interesting logic about RFC 3552. The > WG can decide its threat models as it sees fit. Huh, and presumably without ever documenting such a threat model! > >> The IKEv2 RFC really defines what is in scope. Server state >> exhaustion attacks are not in scope for being mandatorily made >> "more difficult" for some definition of more. > > I don't see anything in RFC 4306 that limits the scope of the threat > models for extensions. So, are you suggesting that we design IKEv2 for one threat model and IKEv2 session resumption for another? regards, Lakshminath > > --Paul Hoffman, Director --VPN Consortium > _______________________________________________ IPsec mailing list > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec > From vidyan@qualcomm.com Mon Apr 20 12:53:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DCC3A6853 for ; Mon, 20 Apr 2009 12:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.16 X-Spam-Level: X-Spam-Status: No, score=-103.16 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, 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 y4RAoZcbyNFb for ; Mon, 20 Apr 2009 12:53:20 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 09ECD3A6B13 for ; Mon, 20 Apr 2009 12:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240257114; x=1271793114; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Paul=20Hoffman=20,=20IPsecme=20 WG=20|Date:=20Mon,=2020=20Apr=202009=2012 :51:52=20-0700|Subject:=20RE:=20[IPsec]=20Issue=20#98:=20 1=20or=20two=20round=20trips=20for=20resumption |Thread-Topic:=20[IPsec]=20Issue=20#98:=201=20or=20two=20 round=20trips=20for=20resumption|Thread-Index:=20Acm4c1P8 WoL3UZlSR3CfzRDY8fsogwJfaPwg|Message-ID:=20 |References:=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5590"=3B=20a=3D"17268787"; bh=2434aGDBOGOKmnFtfYKxr7lzcVTexKFa5rHSH9Ri9E8=; b=seWaSFA2rEqP59xtg18XlxrtDHKUSkCNFJx1rX7EjzvLHMpWHsesl9pR 0CgGfed3RMa41e9VndBBMiMTpoSzY+B0cugNA20+hOFu1QgceZlkLtT0J AmH+wQdg18MZ2W7AY/9asEMYz6nxWDJah/58dFZ2W7GIcm2GcnSHsN2Fx g=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17268787" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 12:51:53 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KJprhF031703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 12:51:53 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3KJprap000899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Apr 2009 12:51:53 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 20 Apr 2009 12:51:52 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Mon, 20 Apr 2009 12:51:51 -0700 From: "Narayanan, Vidya" To: Paul Hoffman , IPsecme WG Date: Mon, 20 Apr 2009 12:51:52 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: Acm4c1P8WoL3UZlSR3CfzRDY8fsogwJfaPwg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:53:22 -0000 Considering that I didn't know what "now" meant and this message didn't hav= e a deadline, I hope my input is considered. I prefer the first option - w= e need to document the associated threat model with each assumption, but, d= eployments need to figure out what their threat model is. The one RT resum= ption mechanism is key for handoff situations and for certain environments,= it doesn't allow new attacks that are feasible outside of the IPsec use an= yway. If we threw out this model, we will be preventing a whole class of u= se cases that could otherwise use this resumption mechanism. =20 Note that for these use cases, it is not much more expensive to just do the= DH and use regular IKEv2, instead of using resumption, if the latter also = involved as many roundtrips.=20 Thanks, Vidya=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Wednesday, April 08, 2009 10:56 AM > To: IPsecme WG > Subject: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > Greetings again. Tracker issue #98 is the same as the message that Pasi > sent to the mailing list last month; see archive/web/ipsec/current/msg04050.html>. There is disagreement among > the authors of the session resumption draft how to deal with this > issue. >=20 > One proposal is to add text similar to Pasi's to the document in order > to let implementers understand all the things that they might need to > do to prevent damage from a replay attack. If this is the method > chosen, it should probably be as a section in the main body of the > document, not as a "security consideration" because the issues are more > operational than security. >=20 > A different proposal is to get rid of the one-round-trip mode and have > the protocol always take two round trips. This prevents the attack that > Pasi brings up, at a higher cost for the clients and server. >=20 > If you have a preference between these two proposal, please state it > now. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Mon Apr 20 14:11:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CD13A6E39 for ; Mon, 20 Apr 2009 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_23=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 QD6GpGbkRpZv for ; Mon, 20 Apr 2009 14:11:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 86DC33A6F51 for ; Mon, 20 Apr 2009 14:11:17 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E08AE30C001; Tue, 21 Apr 2009 00:12:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9CD4D2CC001; Tue, 21 Apr 2009 00:12:32 +0300 (IDT) X-CheckPoint: {49ECE18F-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 n3KLCVqO002179; Tue, 21 Apr 2009 00:12:32 +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; Tue, 21 Apr 2009 00:12:31 +0300 From: Yaron Sheffer To: "Narayanan, Vidya" , Paul Hoffman , IPsecme WG Date: Tue, 21 Apr 2009 00:12:30 +0300 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: Acm4c1P8WoL3UZlSR3CfzRDY8fsogwJfaPwgAAJlP9A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> References: In-Reply-To: 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_00DC_01C9C214.625C7250" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:11:49 -0000 ------=_NextPart_000_00DC_01C9C214.625C7250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [As a coauthor of this draft:] Hi Vidya, Can you please give a more detailed description of this use case, where: - The gateway doesn't care about CPU consumption, to the extent where it doesn't mind the extra DH+RSA operations for thousands of simultaneously arriving clients, and, - The number of round trips until something useful happens (e.g. user interaction) is so low that our 1 extra RT becomes critical. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Narayanan, Vidya > Sent: Monday, April 20, 2009 22:52 > To: Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > Considering that I didn't know what "now" meant and this message didn't > have a deadline, I hope my input is considered. I prefer the first option > - we need to document the associated threat model with each assumption, > but, deployments need to figure out what their threat model is. The one > RT resumption mechanism is key for handoff situations and for certain > environments, it doesn't allow new attacks that are feasible outside of > the IPsec use anyway. If we threw out this model, we will be preventing a > whole class of use cases that could otherwise use this resumption > mechanism. > > Note that for these use cases, it is not much more expensive to just do > the DH and use regular IKEv2, instead of using resumption, if the latter > also involved as many roundtrips. > > Thanks, > Vidya > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Paul Hoffman > > Sent: Wednesday, April 08, 2009 10:56 AM > > To: IPsecme WG > > Subject: [IPsec] Issue #98: 1 or two round trips for resumption > > > > Greetings again. Tracker issue #98 is the same as the message that Pasi > > sent to the mailing list last month; see > archive/web/ipsec/current/msg04050.html>. There is disagreement among > > the authors of the session resumption draft how to deal with this > > issue. > > > > One proposal is to add text similar to Pasi's to the document in order > > to let implementers understand all the things that they might need to > > do to prevent damage from a replay attack. If this is the method > > chosen, it should probably be as a section in the main body of the > > document, not as a "security consideration" because the issues are more > > operational than security. > > > > A different proposal is to get rid of the one-round-trip mode and have > > the protocol always take two round trips. This prevents the attack that > > Pasi brings up, at a higher cost for the clients and server. > > > > If you have a preference between these two proposal, please state it > > now. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00DC_01C9C214.625C7250 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMDIxMDE1NlowIwYJKoZIhvcNAQkEMRYEFAyLeImTEyo7 NXUWmJIDa0aDCFmWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA lhdkxfl6mgh95NtPl8siZlMGYcrscoTe8ZAolsQvLWoM5D6WEnRdMJa6j/JUgdDvclb3J1ol838W +Zjx9WRhFOVG++tsmD5DOT2L6xnzouDoFBX9hblmTu6IEadcl6v1Lh80Ykjjnqh5iVPKj+VN3QQB jFOyUpK3xxgYQ/xJbC7LiBv4u1rBwk5JSwOpBXKRv+MahzGSXSfXBcZKzyNlNMPQYl0QAnZ/1DkK 4y72UiCeRcEawqjnm7UWPtBVnz9j3GRx6drwGo7+ZxFEHhtiIs2vFcgTrZTUVWAhzHDU8rIzhk/u UfPpFE4K7MWKTpZGrSaCkxPa25ilfGV+NTwO3wAAAAAAAA== ------=_NextPart_000_00DC_01C9C214.625C7250-- From Nicolas.Williams@sun.com Mon Apr 20 15:09:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B084728C2B1 for ; Mon, 20 Apr 2009 15:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.174, 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 5GBNYkb8hmsJ for ; Mon, 20 Apr 2009 15:09:41 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 6F0DE28C263 for ; Mon, 20 Apr 2009 15:09:35 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KMAooo021604 for ; Mon, 20 Apr 2009 22:10:51 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 n3KMAo0S041168 for ; Mon, 20 Apr 2009 16:10:50 -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 n3KM1M0p014899; Mon, 20 Apr 2009 17:01:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KM1L8O014898; Mon, 20 Apr 2009 17:01:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 20 Apr 2009 17:01:21 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20090420220121.GD1500@Sun.COM> References: <49ECB4D1.4040306@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: IPsecme WG , Lakshminath Dondeti Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:09:41 -0000 On Mon, Apr 20, 2009 at 11:20:55AM -0700, Paul Hoffman wrote: > At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote: > >Before the one roundtrip mechanism is deleted, could you summarize > >how the security issue that was raised is applicable under the threat > >model we work with? > > No, I can summarize it after it is deleted, given that I deleted it in > my last message. > > The security issues that Pasi sent to the mailing list over a month > ago include: > > - A replay of a ticket can cause exhaustion of many resources, not > just CPU or state on the gateway. Pasi listed these about a month ago. > > - A replay of a ticket can cause a legitimate resumption to fail, > depending on the algorithms used in the IKE SA. Can a replay cache help? Note though that getting replay caches to perform well is hard. Ask any Kerberos V implementor. Nico -- From paul.hoffman@vpnc.org Mon Apr 20 17:40:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240923A69B9 for ; Mon, 20 Apr 2009 17:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 nzE8actPdC5a for ; Mon, 20 Apr 2009 17:40:26 -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 2CB033A6900 for ; Mon, 20 Apr 2009 17:40:25 -0700 (PDT) Received: from [10.20.30.163] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3L0fYdI098982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2009 17:41:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18902.1841.592643.614727@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72E@il-ex01.ad.checkpoint.com> <18902.1841.592643.614727@fireball.kivinen.iki.fi> Date: Mon, 20 Apr 2009 17:41:33 -0700 To: Tero Kivinen , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Issue #63: Position of arbitrary notify payloads X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 00:40:27 -0000 At 3:55 PM +0300 4/3/09, Tero Kivinen wrote: >Btw, is there any reason why [V+] is not listed in the IKE_AUTH >excghange with EAP in the intermediate EAP messages and final AUTH >request from the initiator? We could add it, but I think that would surprise some implementers. Is it really needed? --Paul Hoffman, Director --VPN Consortium From vidyan@qualcomm.com Mon Apr 20 18:22:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AA53A6B20 for ; Mon, 20 Apr 2009 18:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.887 X-Spam-Level: X-Spam-Status: No, score=-104.887 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 HJWC4L9VPfbC for ; Mon, 20 Apr 2009 18:22:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 646E13A69CD for ; Mon, 20 Apr 2009 18:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240277042; x=1271813042; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Yaron=20Sheffer=20,=0D=0A=20=20 =20=20=20=20=20=20Paul=20Hoffman=0D=0A=09,=20IPsecme=20WG=20|Date:=20Mon, =2020=20Apr=202009=2018:23:57=20-0700|Subject:=20RE:=20[I Psec]=20Issue=20#98:=201=20or=20two=20round=20trips=20for =20resumption|Thread-Topic:=20[IPsec]=20Issue=20#98:=201 =20or=20two=20round=20trips=20for=20resumption |Thread-Index:=20Acm4c1P8WoL3UZlSR3CfzRDY8fsogwJfaPwgAAJl P9AACPBbIA=3D=3D|Message-ID:=20|References: =20=0D=0A=20=0D=0A=20<7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5 B@il-ex01.ad.checkpoint.com>|In-Reply-To:=20<7F9A6D26EB51 614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5590"=3B=20a=3D"17291146"; bh=OirWY7rUdrcQLWXdEOZEHDxHMTo4z2SMMJyy/srNCdQ=; b=OKp4buRB77GFGMklKgp2YdOEdFXUckNmgNmjq8KZhL/DYbQMP/2imsUl KOeLOeKvRElApfDTFDwn0WSjLDSO5t35YdT9KKzKFCWwG1S+kZTjSoQ/y f+57TfjQxv7j+ul5zot+vBdEm5xzZjGYIJS76rc58DtQd1xcy/IH7kk6E A=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17291146" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 18:24:02 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L1O210010986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 18:24:02 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L1O1pK015191 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Apr 2009 18:24:01 -0700 (PDT) Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 20 Apr 2009 18:24:01 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Mon, 20 Apr 2009 18:24:00 -0700 From: "Narayanan, Vidya" To: Yaron Sheffer , Paul Hoffman , IPsecme WG Date: Mon, 20 Apr 2009 18:23:57 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: Acm4c1P8WoL3UZlSR3CfzRDY8fsogwJfaPwgAAJlP9AACPBbIA== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:22:47 -0000 Hi Yaron,=20 We are going back to revisiting consensus here and re-explaining the use ca= ses and I'd certainly like to keep this to as minimum a revisit as possible= . The use cases go back to what has been documented in the problem stateme= nt we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now= expired, but, you should be still able to get to the draft. =20 As a key point, I'll note that the situation where resumption is used here = is a handoff case for a particular client and does not involve all clients = connecting at once, where DH could be a problem. And, in these cases, ther= e is no user interaction involved - the mobile devices are doing everything= they can to make handoffs seamless and work with no user or even applicati= on involvement. =20 If you are only worried about the case of simultaneous reconnection of thou= sands of nodes, you can feel free to always use the 2-RT method in your gat= eway implementation - I am pointing out that it is not the universally appl= icable use case. And, in most cellular deployments, IPsec is used for untr= usted access networks (e.g., WLAN), while the DHCP servers and AAA servers = are accessible from other access networks as well. And, a handoff from cel= lular to WLAN needs to be seamless - you can envision an IPsec SA being set= up all the time, but only resumed and actively used after you handoff to W= LAN. =20 I really don't fancy the "one threat model fits all" solution, since we can= not claim to envision all the use cases that will arise tomorrow, even if w= e manage to find a way to fit this one model for existing use cases. And, = in this case, we can't even fit it for existing use cases - so, let's docum= ent the applicable threat model and move forward.=20 Vidya > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > Sent: Monday, April 20, 2009 2:13 PM > To: Narayanan, Vidya; Paul Hoffman; IPsecme WG > Subject: RE: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > [As a coauthor of this draft:] >=20 > Hi Vidya, >=20 > Can you please give a more detailed description of this use case, > where: >=20 > - The gateway doesn't care about CPU consumption, to the extent where > it > doesn't mind the extra DH+RSA operations for thousands of > simultaneously > arriving clients, and, > - The number of round trips until something useful happens (e.g. user > interaction) is so low that our 1 extra RT becomes critical. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf Of > > Narayanan, Vidya > > Sent: Monday, April 20, 2009 22:52 > > To: Paul Hoffman; IPsecme WG > > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > > > Considering that I didn't know what "now" meant and this message > didn't > > have a deadline, I hope my input is considered. I prefer the first > option > > - we need to document the associated threat model with each > assumption, > > but, deployments need to figure out what their threat model is. The > one > > RT resumption mechanism is key for handoff situations and for certain > > environments, it doesn't allow new attacks that are feasible outside > of > > the IPsec use anyway. If we threw out this model, we will be > preventing a > > whole class of use cases that could otherwise use this resumption > > mechanism. > > > > Note that for these use cases, it is not much more expensive to just > do > > the DH and use regular IKEv2, instead of using resumption, if the > latter > > also involved as many roundtrips. > > > > Thanks, > > Vidya > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > > Of Paul Hoffman > > > Sent: Wednesday, April 08, 2009 10:56 AM > > > To: IPsecme WG > > > Subject: [IPsec] Issue #98: 1 or two round trips for resumption > > > > > > Greetings again. Tracker issue #98 is the same as the message that > Pasi > > > sent to the mailing list last month; see > > archive/web/ipsec/current/msg04050.html>. There is disagreement > among > > > the authors of the session resumption draft how to deal with this > > > issue. > > > > > > One proposal is to add text similar to Pasi's to the document in > order > > > to let implementers understand all the things that they might need > to > > > do to prevent damage from a replay attack. If this is the method > > > chosen, it should probably be as a section in the main body of the > > > document, not as a "security consideration" because the issues are > more > > > operational than security. > > > > > > A different proposal is to get rid of the one-round-trip mode and > have > > > the protocol always take two round trips. This prevents the attack > that > > > Pasi brings up, at a higher cost for the clients and server. > > > > > > If you have a preference between these two proposal, please state > it > > > now. > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. From vidyan@qualcomm.com Mon Apr 20 21:18:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC3C3A69F0 for ; Mon, 20 Apr 2009 21:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, 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 AE8SzWTN0cf1 for ; Mon, 20 Apr 2009 21:18:28 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B5C333A68A4 for ; Mon, 20 Apr 2009 21:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240287585; x=1271823585; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Paul=20Hoffman=20,=20IPsecme=20 WG=20|Date:=20Mon,=2020=20Apr=202009=2021 :19:34=20-0700|Subject:=20RE:=20[IPsec]=20Issue=20#98:=20 1=20or=20two=20round=20trips=20for=20resumption |Thread-Topic:=20[IPsec]=20Issue=20#98:=201=20or=20two=20 round=20trips=20for=20resumption|Thread-Index:=20AcnB27Ub oe4CC4pCSKyuzjbDPZN2CwAXF3Xg|Message-ID:=20 |References:=20=0D =0A=20|In-Reply-To: =20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5590"=3B=20a=3D"17282459"; bh=QtWaOEbBBzkHu7Tsg8LeLxxpkzEQyEhZ6ivcMjVwbKs=; b=Z6vxkJKruO+ResIp26QgFRALebUekfdrqZgCBvpVfO0MYTSCQWswQ0Ae 4m227kim4d8ziExh/YiM7hfcww/JyI86mQ4YIFqAElU8MjutAlxHQaW6P kPwZ4QyYPziiH/QM1u6kWtyYaiygN5KLI0KwixHA0jsPItwcl95Kyouek w=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17282459" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 21:19:44 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L4Jiue025357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 21:19:44 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L4Jdtw011990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Apr 2009 21:19:42 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 20 Apr 2009 21:19:39 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 20 Apr 2009 21:19:38 -0700 From: "Narayanan, Vidya" To: Paul Hoffman , IPsecme WG Date: Mon, 20 Apr 2009 21:19:34 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnB27Uboe4CC4pCSKyuzjbDPZN2CwAXF3Xg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 04:18:29 -0000 Hi Paul, For my clarification, could you please state who are the people on each sid= e of this? I've gone through all emails I have on this thread and I only se= e Yoav's email supporting the second approach. It is entirely possible tha= t my email isn't working as it should - but, I'd appreciate a pointer to th= e second email that supported removing the one RT exchange. =20 Thanks, Vidya > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Monday, April 20, 2009 10:16 AM > To: IPsecme WG > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > >=20 > Greetings again. Of the people who replied, two favored mandating two > round trips, and one favored keeping the current one round trip. That > (anemic) result, plus the comment that lead to this thread, leads me to > say that we need to change draft-ietf-ipsecme-ikev2-resumption to > require two round trips. >=20 > Draft authors: please prepare a -03 with only the two-round-trip > solution, and pull out the text about the one-round-trip option. >=20 > If someone really objects to this, please prepare a personal Internet > Draft that lists exactly how you would change the current -03 draft to > cover all the security issues that were brought forward. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From vidyan@qualcomm.com Mon Apr 20 22:10:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052E93A6EB5 for ; Mon, 20 Apr 2009 22:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, 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 0nSXWbfgGK2Z for ; Mon, 20 Apr 2009 22:10:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D66B93A6F30 for ; Mon, 20 Apr 2009 22:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240290676; x=1271826676; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Narayanan,=20Vidya"=20,=0D=0A=20 =20=20=20=20=20=20=20Paul=20Hoffman=0D=0A=09,=20IPsecme=20WG=20|Date:=20Mon ,=2020=20Apr=202009=2022:11:10=20-0700|Subject:=20RE:=20[ IPsec]=20Issue=20#98:=201=20or=20two=20round=20trips=20fo r=20resumption|Thread-Topic:=20[IPsec]=20Issue=20#98:=201 =20or=20two=20round=20trips=20for=20resumption |Thread-Index:=20AcnB27Uboe4CC4pCSKyuzjbDPZN2CwAXF3XgAAHY U9A=3D|Message-ID:=20|References:=20=0D=0A=09=0D=0A=20|In-Reply-To: =20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5590"=3B=20a=3D"17283302"; bh=xLtWF6LhpqDZ2gsyZp+ugzGmz61XmIlfGFy0DjzuUWI=; b=QMLGO9tMRIoHwxB+ET/qWE0yPiLF4ZhFpf1PlzwyV8Q8ceMaJcSjWZ7d 97svRO1MVi5Gltkzwt3dIyZyYiU/7mtBDq5cwEna0YsUf6Tq0fKpZiz8t 91jjwlZzxd9FtttPeUVAqsuwjwVWobwePhmRfVFpN6Ghg+p0h8+Vl2n7J U=; X-IronPort-AV: E=McAfee;i="5300,2777,5590"; a="17283302" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2009 22:11:16 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L5BFEZ009659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Apr 2009 22:11:15 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3L5BD0I015976 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 Apr 2009 22:11:15 -0700 (PDT) Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 20 Apr 2009 22:11:13 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Mon, 20 Apr 2009 22:11:12 -0700 From: "Narayanan, Vidya" To: "Narayanan, Vidya" , Paul Hoffman , IPsecme WG Date: Mon, 20 Apr 2009 22:11:10 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnB27Uboe4CC4pCSKyuzjbDPZN2CwAXF3XgAAHYU9A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 05:10:01 -0000 Replying to my own email to note that I did receive the clarification offli= ne from Yaron - it did turn out that my email was not picking up all elemen= ts of the mail thread properly. =20 Thanks, Vidya > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Narayanan, Vidya > Sent: Monday, April 20, 2009 9:20 PM > To: Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > Hi Paul, > For my clarification, could you please state who are the people on each > side of this? I've gone through all emails I have on this thread and I > only see Yoav's email supporting the second approach. It is entirely > possible that my email isn't working as it should - but, I'd appreciate > a pointer to the second email that supported removing the one RT > exchange. >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > > Of Paul Hoffman > > Sent: Monday, April 20, 2009 10:16 AM > > To: IPsecme WG > > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > > > > > > > Greetings again. Of the people who replied, two favored mandating two > > round trips, and one favored keeping the current one round trip. That > > (anemic) result, plus the comment that lead to this thread, leads me > to > > say that we need to change draft-ietf-ipsecme-ikev2-resumption to > > require two round trips. > > > > Draft authors: please prepare a -03 with only the two-round-trip > > solution, and pull out the text about the one-round-trip option. > > > > If someone really objects to this, please prepare a personal Internet > > Draft that lists exactly how you would change the current -03 draft > to > > cover all the security issues that were brought forward. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue Apr 21 02:17:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2283A6910 for ; Tue, 21 Apr 2009 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 3OIYGMbpSP36 for ; Tue, 21 Apr 2009 02:17:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C656C3A67CF for ; Tue, 21 Apr 2009 02:17:15 -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 n3L9IPJd014614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 12:18:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3L9INGp003125; Tue, 21 Apr 2009 12:18:23 +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: <18925.36703.614261.257050@fireball.kivinen.iki.fi> Date: Tue, 21 Apr 2009 12:18:23 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBE72E@il-ex01.ad.checkpoint.com> <18902.1841.592643.614727@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 24 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #63: Position of arbitrary notify payloads X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 09:17:17 -0000 Paul Hoffman writes: > At 3:55 PM +0300 4/3/09, Tero Kivinen wrote: > >Btw, is there any reason why [V+] is not listed in the IKE_AUTH > >excghange with EAP in the intermediate EAP messages and final AUTH > >request from the initiator? > > We could add it, but I think that would surprise some implementers. > Is it really needed? I do not think any of the [V+] payloads are really needed, as section 3.12 clearly says that "A Vendor ID payload may be sent as part of any message.". My question was more of "was this omission trying to say something". I.e. does that it is NOT listed in that those messages trying to say that those messages are not logical place for vendor ID payloads. (I actually only now noticed the text about most logical place). I would at least expect that vendor ID payloads could be also used in the last AUTH message from client to server, i.e. after the EAP authentication is finished. The server is already marked so that it can use [V+] in its last response. I.e. for server the logical places are first and last response, but for client the only logical place listed is the first request, last request was ommitted. I agree that during the EAP exchanges itself (the ones repeted 1..N times) the vendor ID payloads might not be that logical (as most likely all extensions during that is done inside the EAP messages itself, not as IKEv2 vendor ID payloads). But I think the last request is bit different case, and I myself consider that as one that could be logical place for vendor ID payload for some extension. Currently it is bit funny that only places where vendor ID payloads are not supposed to be most logical are: - IKE_AUTH exchange with EAP: EAP payload request - IKE_AUTH exchange with EAP: EAP payload response - IKE_AUTH exchange with EAP: last request from client - CREATE_CHILD_SA for Child SA: generic error case response - INFORMATIONAL exchange: request - INFORMATIONAL exchange: response It is not very "most logical" locations if it is listed in 71% of cases (i.e. 15 packets out of 21). I think the most logical place currently to send those vendor ID payloads is only during IKE_SA_INIT exchange request, and IKE_SA_INIT exchange normal response. We currently do not have any extensions which would send them in any other locations, and I have not seen any implementations sending them in any other locations yet. If you want to pick the "most logical" place, then I would only put it on those exchanges, and say that they can still be part of any other message too if needed. -- kivinen@iki.fi From ynir@checkpoint.com Tue Apr 21 03:28:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079AA3A6FFF for ; Tue, 21 Apr 2009 03:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 9zd721m7Mi5z for ; Tue, 21 Apr 2009 03:28:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9FD1C3A6EDB for ; Tue, 21 Apr 2009 03:28:20 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E33F30C001; Tue, 21 Apr 2009 13:29:35 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5E5342CC002; Tue, 21 Apr 2009 13:29:35 +0300 (IDT) X-CheckPoint: {49ED9C53-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 n3LATYqO009701; Tue, 21 Apr 2009 13:29:34 +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; Tue, 21 Apr 2009 13:29:34 +0300 From: Yoav Nir To: Yaron Sheffer , Vijay Devarapalli Date: Tue, 21 Apr 2009 13:31:32 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: Acm+vML0AFae3BYLTCO7DlQcE/OongBk35+iAEaHOK0AB2br4AAAoz7QADhi0DA= Message-ID: <9FB7C7CE79B84449B52622B506C78036133859779B@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036133291CB91@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036133859761B@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4BE2@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4BE2@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:28:22 -0000 So are we working with the assumption that the gateway (or the AAA server) = can always authenticate any user that connects?=20 > -----Original Message----- > From: Yaron Sheffer=20 > Sent: Monday, April 20, 2009 10:43 AM > To: Yoav Nir; Vijay Devarapalli > Cc: IPsecme WG > Subject: RE: [IPsec] WG Last Call:=20 > draft-ietf-ipsecme-ikev2-redirect-08 >=20 > Below. >=20 > > -----Original Message----- > > From: Yoav Nir > > Sent: Monday, April 20, 2009 10:30 > > To: Vijay Devarapalli > > Cc: Yaron Sheffer; IPsecme WG > > Subject: RE: [IPsec] WG Last Call:=20 > > draft-ietf-ipsecme-ikev2-redirect-08 > >=20 > > Hi > >=20 > > Come to think of it, I'm wondering about something else. > >=20 > > Let's suppose that the gateway cannot tell where the user=20 > should connect. > > The EAP exchange with the AAA server begins. The AAA server=20 > realizes=20 > > that the user name ("jdoe") is not in its database, and the user=20 > > should be redirected to gateway B. > >=20 > > What now? Does it complete the exchange successfully, and=20 > redirect? =20 > > Or does it fail the exchange and redirect? > >=20 > > I think the obvious answer is to fail the exchange and redirect. I=20 > > think we should mandate that even with EAP failure, the=20 > client should=20 > > honor the REDIRECT. > >=20 > > If the gateway authentication fails (the AUTH payload in the first=20 > > IKE_AUTH response fails to authenticate) then I'm not sure what the=20 > > right action is. REDIRECT is accepted in an=20 > unauthenticated INITIAL exchange. > > Why not, then, in a failed authentication IKE_AUTH exchange? > >=20 > [YS] No, failing authentication is different from being=20 > unauthenticated. The client may have a policy that says that=20 > it's willing to be redirected at IKE_SA_INIT. But if it=20 > receives an AUTH value that is explicitly untrusted (say,=20 > with a revoked certificate), I think it should not act on it.=20 > Even though a malicious gateway could have responded in the=20 > first exchange etc. > etc. >=20 > Also note that it may be hard to untangle client=20 > authentication from gateway authentication, e.g. when using=20 > symmetric password authentication such as EAP-EKE=20 > . Email secured by Check Point From kivinen@iki.fi Tue Apr 21 04:51:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9DF28C106 for ; Tue, 21 Apr 2009 04:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 5v+t-3ZQ3uxg for ; Tue, 21 Apr 2009 04:51:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 518983A6826 for ; Tue, 21 Apr 2009 04:51:52 -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 n3LBr2M7017861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 14:53:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3LBr04C022283; Tue, 21 Apr 2009 14:53:00 +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: <18925.45980.896489.919446@fireball.kivinen.iki.fi> Date: Tue, 21 Apr 2009 14:53:00 +0300 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 47 min X-Total-Time: 64 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:51:57 -0000 Narayanan, Vidya writes: > Hi Yaron, > We are going back to revisiting consensus here and re-explaining the > use cases and I'd certainly like to keep this to as minimum a > revisit as possible. The use cases go back to what has been > documented in the problem statement we published a while back - > draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you > should be still able to get to the draft. >From the ipsecme charter: Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Thus failover from one gateway to another is outside the scope of this document. If I remember right most of the use cases in draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not resumption use cases. > As a key point, I'll note that the situation where resumption is > used here is a handoff case for a particular client and does not > involve all clients connecting at once, where DH could be a problem. > And, in these cases, there is no user interaction involved - the > mobile devices are doing everything they can to make handoffs > seamless and work with no user or even application involvement. > > If you are only worried about the case of simultaneous reconnection > of thousands of nodes, you can feel free to always use the 2-RT > method in your gateway implementation - I am pointing out that it is > not the universally applicable use case. >From the abstract of the resumption document: To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. So at least it was seen as important use case, and is thats why included in the abstract (and the ipsecme charter text). > And, in most cellular deployments, IPsec is used for untrusted > access networks (e.g., WLAN), while the DHCP servers and AAA servers > are accessible from other access networks as well. And, a handoff > from cellular to WLAN needs to be seamless - you can envision an > IPsec SA being set up all the time, but only resumed and actively > used after you handoff to WLAN. Hmm.. This is again something completely different what I tought for what the resumption protocol is supposed for. For example for this use it would be useful to have have some way to force deletion of the state from the server, i.e. say that this IKE SA is now going to go to sleep, so you can remove the state, and there is no need to do dead peer detection on it. The current protocol do not have anything like that, and if you delete IKE SA you also delete the ticket, so that mechanism cannot be used for that. I still do not think making the 1 RT protocol to 2 RT protocol in that case would really cause any noticeable effect to the actual handover. Especially as you still most likely have the cellular network there to be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the WLAN, thus only thing that is affected is that traffic moves 100ms later from cellular to WLAN. On the other hand security problems are big issue, as you most likely try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, thus you effectively broadcast your tickets to attackers at will, so attackers can simply take those tickets and sent them to server and get your session resumed, but not forward any other traffic. Also any firewall allowing port 500 packets out but not in, will cause similar effect, as you will not get reply back, but server will consume your ticket. That case also brings out completely new issue which has not been discussed before, i.e. whether the IKE_SESSION_RESUME must come from the same IP-address than what was used before for the IKE SA, i.e. can the IP-addresses change during the IKE_SESSION_RESUME. If that is allowed, then what about NATs, i.e. is it allowed that even when there was no NAT between hosts before, there is new NAT found during the IKE_SESSION_RESUME? Those are not covered by the current document, and at least something MUST be said about those issues. After this example use scenario, I am even more convinced that 2 RT protocol is better and needed, especially if we do allow IP-addresses change, and might need to do NAT-T detection on the IKE_SESSION_RESUME exchange too. Allowing IP-addresses change means that the network where the packets can come in, are different, meaning they might have misconfigured firewalls or similars there, and killing your resumption ticket by just trying to connect through broken firewall is bad idea. -- kivinen@iki.fi From kagarigi@cisco.com Tue Apr 21 04:59:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF47A28C1E1 for ; Tue, 21 Apr 2009 04:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NvTw8W7zYySn for ; Tue, 21 Apr 2009 04:59:40 -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 00AA328C1D7 for ; Tue, 21 Apr 2009 04:59:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,224,1238976000"; d="scan'208";a="289992606" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2009 12:00: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 n3LC0un6004928 for ; Tue, 21 Apr 2009 05:00:56 -0700 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3LC0WQe009816 for ; Tue, 21 Apr 2009 12:00:56 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 17:30:47 +0530 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, 21 Apr 2009 17:30:46 +0530 Message-ID: <12CEFA6955F85042B5462C204F68519509280AAC@xmb-blr-415.apac.cisco.com> In-Reply-To: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple payloads of same type Thread-Index: AcnBhwTRvkh1NpfSQCycoj5PKph9SQA8KkpA References: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> From: "Kalyani Garigipati (kagarigi)" To: X-OriginalArrivalTime: 21 Apr 2009 12:00:47.0260 (UTC) FILETIME=[CE77EDC0:01C9C278] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=361; t=1240315256; x=1241179256; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kagarigi@cisco.com; z=From:=20=22Kalyani=20Garigipati=20(kagarigi)=22=20 |Subject:=20Multiple=20payloads=20of=20same=20type |Sender:=20; bh=svdBF5OvJAzexqx8os086gjbJGfhDGPcivP43f41bUk=; b=c/6EJzu745Fnzv81ValCTwo95PjS3xozHRLWvGuRbpKU6EVuOFXsYUjbY6 1BnFwp11k8UTrlj2KmMB+E0yn9/XxQ8bO9YgCoDvwDQdP3T1/SwcpfJPMSWK R2llH6bAiCfwNXpUH6aTSMOpI3ue8K4BFiKUWEEwhlyS6UGQoo0YU=; Authentication-Results: sj-dkim-1; header.From=kagarigi@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [IPsec] Multiple payloads of same type X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:59:40 -0000 Hi, Please validate if the following is true. Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM, TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE, DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads. Like if we get packet as HDR, SA1, SA1, KE, N We should reject it ? Regards, kalyani From yaronf@checkpoint.com Tue Apr 21 05:45:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FAD3A702C for ; Tue, 21 Apr 2009 05:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 Y-Dq9HiH-v3h for ; Tue, 21 Apr 2009 05:45:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A80823A6BAE for ; Tue, 21 Apr 2009 05:45:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DCFE030C006; Tue, 21 Apr 2009 15:46:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 781E42CC002; Tue, 21 Apr 2009 15:46:34 +0300 (IDT) X-CheckPoint: {49EDBC6D-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 n3LCkBqS019468; Tue, 21 Apr 2009 15:46:34 +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; Tue, 21 Apr 2009 15:46:31 +0300 From: Yaron Sheffer To: Tero Kivinen , "Narayanan, Vidya" Date: Tue, 21 Apr 2009 15:46:29 +0300 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnCd7yDTTTbyJwNThS9WWD9GZWUFgABmwLA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4E60@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> In-Reply-To: <18925.45980.896489.919446@fireball.kivinen.iki.fi> 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_0140_01C9C298.55E9C110" MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:45:22 -0000 ------=_NextPart_000_0140_01C9C298.55E9C110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, To answer the last part of your mail, we always intended address change (and presumably, NAT detection status change) to be supported. This should be clarified in the document, and I have opened Issue #100 for this. However, given that normal NAT detection happens during IKE_SA_INIT, can you clarify why this would work better if we had a 2 RT protocol? Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, April 21, 2009 14:53 > To: Narayanan, Vidya > Cc: Yaron Sheffer; Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > Narayanan, Vidya writes: > > Hi Yaron, > > We are going back to revisiting consensus here and re-explaining the > > use cases and I'd certainly like to keep this to as minimum a > > revisit as possible. The use cases go back to what has been > > documented in the problem statement we published a while back - > > draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you > > should be still able to get to the draft. > > From the ipsecme charter: > > Failover from one gateway to another, mechanisms for detecting > when a session should be resumed, and specifying communication > mechanisms between gateways are beyond the scope of this work > item. > > Thus failover from one gateway to another is outside the scope of this > document. If I remember right most of the use cases in > draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not > resumption use cases. > > > As a key point, I'll note that the situation where resumption is > > used here is a handoff case for a particular client and does not > > involve all clients connecting at once, where DH could be a problem. > > And, in these cases, there is no user interaction involved - the > > mobile devices are doing everything they can to make handoffs > > seamless and work with no user or even application involvement. > > > > If you are only worried about the case of simultaneous reconnection > > of thousands of nodes, you can feel free to always use the 2-RT > > method in your gateway implementation - I am pointing out that it is > > not the universally applicable use case. > > From the abstract of the resumption document: > > To re-establish security associations (SAs) upon a failure recovery > condition is time consuming especially when an IPsec peer (such as a > VPN gateway) needs to re-establish a large number of SAs with various > end points. A high number of concurrent sessions might cause > additional problems for an IPsec peer during SA re-establishment. > > So at least it was seen as important use case, and is thats why > included in the abstract (and the ipsecme charter text). > > > And, in most cellular deployments, IPsec is used for untrusted > > access networks (e.g., WLAN), while the DHCP servers and AAA servers > > are accessible from other access networks as well. And, a handoff > > from cellular to WLAN needs to be seamless - you can envision an > > IPsec SA being set up all the time, but only resumed and actively > > used after you handoff to WLAN. > > Hmm.. This is again something completely different what I tought for > what the resumption protocol is supposed for. For example for this use > it would be useful to have have some way to force deletion of the > state from the server, i.e. say that this IKE SA is now going to go to > sleep, so you can remove the state, and there is no need to do dead > peer detection on it. The current protocol do not have anything like > that, and if you delete IKE SA you also delete the ticket, so that > mechanism cannot be used for that. > > I still do not think making the 1 RT protocol to 2 RT protocol in that > case would really cause any noticeable effect to the actual handover. > Especially as you still most likely have the cellular network there to > be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the > WLAN, thus only thing that is affected is that traffic moves 100ms > later from cellular to WLAN. > > On the other hand security problems are big issue, as you most likely > try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, > thus you effectively broadcast your tickets to attackers at will, so > attackers can simply take those tickets and sent them to server and > get your session resumed, but not forward any other traffic. Also any > firewall allowing port 500 packets out but not in, will cause similar > effect, as you will not get reply back, but server will consume your > ticket. > > That case also brings out completely new issue which has not been > discussed before, i.e. whether the IKE_SESSION_RESUME must come from > the same IP-address than what was used before for the IKE SA, i.e. can > the IP-addresses change during the IKE_SESSION_RESUME. If that is > allowed, then what about NATs, i.e. is it allowed that even when there > was no NAT between hosts before, there is new NAT found during the > IKE_SESSION_RESUME? > > Those are not covered by the current document, and at least something > MUST be said about those issues. > > After this example use scenario, I am even more convinced that 2 RT > protocol is better and needed, especially if we do allow IP-addresses > change, and might need to do NAT-T detection on the IKE_SESSION_RESUME > exchange too. Allowing IP-addresses change means that the network > where the packets can come in, are different, meaning they might have > misconfigured firewalls or similars there, and killing your resumption > ticket by just trying to connect through broken firewall is bad idea. > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0140_01C9C298.55E9C110 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMTEyNDYyOFowIwYJKoZIhvcNAQkEMRYEFKxp5ydbDmpC hAmCsPQF5WHE3egLMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA TN66mAo6vy97N/J6GsgmWynrSRpIpV6A9yw3kzh87t80eeJRXMylceQ1HHCEFA5/xKj//j5ZExv6 aOOjII8FaQcx2TwkgxIjZxu8Vsu+bbfMUoPlNouZKVKTJ5IysUKXdPHyqzwBeEs1yY2eLfKX2bEM eWqayMd7ys9hUkfUVDV6RxdlmHmN/jS6JYFxhZ2TrXUpesS+oBoHVuIHjOJV/JpqNWbEi38+nU1L aHrtSRDgDKttJHrJlTH7bjND3rcB7LDQyFgL9hUVEG0FawfYU31LS6D8PC3SGtPffE5z0+6pY00Q jeN87Ja24KPt/SqTJ8K2h27+HcHy7n9ZlnxbSwAAAAAAAA== ------=_NextPart_000_0140_01C9C298.55E9C110-- From kivinen@iki.fi Tue Apr 21 05:46:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338443A702B for ; Tue, 21 Apr 2009 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 BxxI-tVA+3ae for ; Tue, 21 Apr 2009 05:46:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 19AD73A69C6 for ; Tue, 21 Apr 2009 05:46:17 -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 n3LClWI6008737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Apr 2009 15:47:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3LClVJp013374; Tue, 21 Apr 2009 15:47:31 +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: <18925.49251.957936.352132@fireball.kivinen.iki.fi> Date: Tue, 21 Apr 2009 15:47:31 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 45 min X-Total-Time: 54 min Subject: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:46:35 -0000 During the other discussion I read the draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more generic comments to it: --- In Section 3 we present 2 use cases, and then after figure 1 start talking about "In this scenario..." and I think that refers to first use scenario described in second paragraph of section 3, not the second use scenario described just above that in third paragraph. It would be useful to change the "In this scenario..." to explicitly mention which one of those two scenarios it is talking about. As far as I can understand the second use scenario is not talked in detail anywhere, i.e. only reference to it is 3rd paragraph of section 3. --- In Section 4.3, it might be good idea to clarify that reuse of the ticket is when you successfully use it, not just when you try to use the ticket, i.e. client can try to send IKE_SESSION_RESUME exchanges every now and then to the server and ticket is only really used when it gets reply from server. --- Also the text "The client SHOULD NOT use this exchange type unless it knows that the gateway supports it." is bit pointless, as at least from my understanding is that when server presents ticket to client it indicates the gateway supports this, thus if client has ticket it can use this exchange. If client does not have ticket it cannot use this exchange anyways, as ticket is required for this exchange. --- I would also like to rename TICKET_OPAQUE' to something else, perhaps use TICKET_REQUEST, TICKET_REPLY, TICKET_PRESENT or similar names instead (main reason for that is that I like to define those names to actual defines in C-code or similar, and then I need to rename TICKET_OPAQUE' to something like TICKET_OPAUQE_DOT or so). --- Why is the IDr there? I know I asked this before, but I do not sill understand why it is there. Gateway cannot have multiple identities having different session resumption caches, as IDr is encrypted, meaning gateway needs to parse presented ticket first, and that ticket must have information of which identity the connection is connecting so it can select suitable session resumption cache. Section 4.7 says that IDr is obtained from the new exchange, so that seems to indicate it is used, but IDi, and IDr is used to check PAD, which is then used to check SPD entries etc, and I do not think we want to redo policy lookups at this point. Also in normal IKE we do not directly use the IDr that client sent, we use that as hint when selecting one of the our own allowed IDr for this connection. The text in 4.7 would indicate that we directly use the IDr client sent us as is. The IDi was already removed, but is there any reason to keep the IDr there? Even if it is kept, the section 4.7 will most likely need text saying that IDr is selected as normally, i.e. the IDr from exchange is only used as hint. Also note that the gateway does not tell back to the client which IDr it finally decided to use... --- Also still in section 4.3 when talking about the response packet, the text about what is filled in the SPI fields is wrong. For the response packet the SPIi value is of course copied from the request, and SPIr is filled with random number allocated by the responder (gateway). --- Section 4.3 also needs to clarify what is going to be message IDs of the exchanges. Especially with the 2 RT version there is two options, i.e. it could be that the cookie exchange has message ID of 0, and actual exchange has message ID of 1. When the cookie exchange was optional, then it was quite clear that all of the IKE_SESSION_RESUME exchange messages have message ID of 0. --- In section 4.7 it says "The sequence numbers are reset to 0.". I was trying to search that earlier, but didn't find it because I searched using "Message ID" text... Unfortunately IKEv2 document uses both "sequence number" and "Messsage ID". It uses "Message ID" bit more, and good thing with "Message ID" term is that it cannot be confused with the sequence numbers of the ESP/AH packets. I would recommend changing that text to "The Message ID counters are reset to 0.". --- Section 5.2 says that "The lifetime of the ticket carried in the N(TICKET_OPAQUE) notification SHOULD be the minimum of the IKE SA lifetime and its re-authentication time", and also that "The gateway SHOULD set the expiration date for the ticket to a larger value than the lifetime of the IKE SA." That is bit confusing, and at first looks like it is conflicting. I assume it was supposed to say that the lifetime sent in the ticket is actually different that what is enforced by the server, i.e. server should allow ticket also after the life time sent to client? Hmm.. on the other hand client MUST NOT present ticket which is expired... Actually I am not sure what the current text is trying to say. I.e. is the ticket lifetime supposed to be same or smaller than IKE SA lifetime, or larger? (On the other hand I still think the whole lifetime concept should be removed from this document, but lets not go there here :-) --- It still does not say whether ticket is valid after IKE SA rekey. It does say it is allowed to request new ticket when doing CREATE_CHILD_SA exchange to rekey IKE SA, but it does not say whether the old ticket is valid after rekey. -- kivinen@iki.fi From yaronf@checkpoint.com Tue Apr 21 06:17:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B096E28C15D for ; Tue, 21 Apr 2009 06:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 g7iK0H1c2Hv9 for ; Tue, 21 Apr 2009 06:17:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 54F4C3A7029 for ; Tue, 21 Apr 2009 06:17:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9F5B230C002; Tue, 21 Apr 2009 16:18:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 601952CC002; Tue, 21 Apr 2009 16:18:29 +0300 (IDT) X-CheckPoint: {49EDC3E7-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 n3LDISqO000322; Tue, 21 Apr 2009 16:18:29 +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; Tue, 21 Apr 2009 16:18:28 +0300 From: Yaron Sheffer To: Tero Kivinen , "ipsec@ietf.org" Date: Tue, 21 Apr 2009 16:18:27 +0300 Thread-Topic: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt Thread-Index: AcnCf26ot8E4aZIeTXugMSd/Z7a4XQAArIgg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4E7A@il-ex01.ad.checkpoint.com> References: <18925.49251.957936.352132@fireball.kivinen.iki.fi> In-Reply-To: <18925.49251.957936.352132@fireball.kivinen.iki.fi> 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_014D_01C9C29C.CD435B00" MIME-Version: 1.0 Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:17:16 -0000 ------=_NextPart_000_014D_01C9C29C.CD435B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, I have opened Issue #101 for your comments (being too lazy to process them into multiple issues), and we will process them in batch mode. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Tuesday, April 21, 2009 15:48 > To: ipsec@ietf.org > Subject: [IPsec] Some comments to draft-ietf-ipsecme-ikev2-resumption- > 02.txt > > During the other discussion I read the > draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more > generic comments to it: > > --- > > In Section 3 we present 2 use cases, and then after figure 1 start > talking about "In this scenario..." and I think that refers to first > use scenario described in second paragraph of section 3, not the > second use scenario described just above that in third paragraph. It > would be useful to change the "In this scenario..." to explicitly > mention which one of those two scenarios it is talking about. As far > as I can understand the second use scenario is not talked in detail > anywhere, i.e. only reference to it is 3rd paragraph of section 3. > > --- > > In Section 4.3, it might be good idea to clarify that reuse of the > ticket is when you successfully use it, not just when you try to use > the ticket, i.e. client can try to send IKE_SESSION_RESUME exchanges > every now and then to the server and ticket is only really used when > it gets reply from server. > > --- > > Also the text "The client SHOULD NOT use this exchange type unless it > knows that the gateway supports it." is bit pointless, as at least > from my understanding is that when server presents ticket to client it > indicates the gateway supports this, thus if client has ticket it can > use this exchange. If client does not have ticket it cannot use this > exchange anyways, as ticket is required for this exchange. > > --- > > I would also like to rename TICKET_OPAQUE' to something else, perhaps > use TICKET_REQUEST, TICKET_REPLY, TICKET_PRESENT or similar names > instead (main reason for that is that I like to define those names to > actual defines in C-code or similar, and then I need to rename > TICKET_OPAQUE' to something like TICKET_OPAUQE_DOT or so). > > --- > > Why is the IDr there? I know I asked this before, but I do not sill > understand why it is there. Gateway cannot have multiple identities > having different session resumption caches, as IDr is encrypted, > meaning gateway needs to parse presented ticket first, and that ticket > must have information of which identity the connection is connecting > so it can select suitable session resumption cache. Section 4.7 says > that IDr is obtained from the new exchange, so that seems to indicate > it is used, but IDi, and IDr is used to check PAD, which is then used > to check SPD entries etc, and I do not think we want to redo policy > lookups at this point. > > Also in normal IKE we do not directly use the IDr that client sent, we > use that as hint when selecting one of the our own allowed IDr for > this connection. The text in 4.7 would indicate that we directly use > the IDr client sent us as is. > > The IDi was already removed, but is there any reason to keep the IDr > there? Even if it is kept, the section 4.7 will most likely need text > saying that IDr is selected as normally, i.e. the IDr from exchange is > only used as hint. Also note that the gateway does not tell back to > the client which IDr it finally decided to use... > > --- > > Also still in section 4.3 when talking about the response packet, the > text about what is filled in the SPI fields is wrong. For the response > packet the SPIi value is of course copied from the request, and SPIr > is filled with random number allocated by the responder (gateway). > > --- > > Section 4.3 also needs to clarify what is going to be message IDs of > the exchanges. Especially with the 2 RT version there is two options, > i.e. it could be that the cookie exchange has message ID of 0, and > actual exchange has message ID of 1. When the cookie exchange was > optional, then it was quite clear that all of the IKE_SESSION_RESUME > exchange messages have message ID of 0. > > --- > > In section 4.7 it says "The sequence numbers are reset to 0.". I was > trying to search that earlier, but didn't find it because I searched > using "Message ID" text... Unfortunately IKEv2 document uses both > "sequence number" and "Messsage ID". It uses "Message ID" bit more, > and good thing with "Message ID" term is that it cannot be confused > with the sequence numbers of the ESP/AH packets. I would recommend > changing that text to "The Message ID counters are reset to 0.". > > --- > > Section 5.2 says that "The lifetime of the ticket carried in the > N(TICKET_OPAQUE) notification SHOULD be the minimum of the IKE SA > lifetime and its re-authentication time", and also that "The gateway > SHOULD set the expiration date for the ticket to a larger value than > the lifetime of the IKE SA." > > That is bit confusing, and at first looks like it is conflicting. I > assume it was supposed to say that the lifetime sent in the ticket is > actually different that what is enforced by the server, i.e. server > should allow ticket also after the life time sent to client? Hmm.. on > the other hand client MUST NOT present ticket which is expired... > Actually I am not sure what the current text is trying to say. I.e. is > the ticket lifetime supposed to be same or smaller than IKE SA > lifetime, or larger? > > (On the other hand I still think the whole lifetime concept should be > removed from this document, but lets not go there here :-) > > --- > > It still does not say whether ticket is valid after IKE SA rekey. It > does say it is allowed to request new ticket when doing > CREATE_CHILD_SA exchange to rekey IKE SA, but it does not say whether > the old ticket is valid after rekey. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_014D_01C9C29C.CD435B00 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyMTEzMTgyN1owIwYJKoZIhvcNAQkEMRYEFOwh7AGJl3zW Cmc/08OFp5WHC2U/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA txfsPXDrrbFfTpL2IgfItFE0AV9buuKfpknSrPHDiwyKgtTQdSLiQelco8aPtvnKsDIolQ3MToA2 U7CdYE48sSVKJLV5QYoiQE7DyhMbGozWFWmoxLf9H8KF9k4hee2aeAmVztwtYOhrNdQ6LYrzoBSR f2VSNH/iab5PsS+pCOXaJFtq0OFQZnzfJrng4I3tpJiADSzjZ9B7uS98vwA+BCgQv3b1K0d64SB8 uGyOzf55tO0sdfxuuL5lDa9ZmcXphDdGZ+cCYCGGPIFCHoSifN9JbRJLn8GeIzey23TgvF1tYWNX D4HjeGa1uP4qonBCZ/yDVca/rtT2ADmHd2ApvgAAAAAAAA== ------=_NextPart_000_014D_01C9C29C.CD435B00-- From kivinen@iki.fi Tue Apr 21 06:48:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1643A7039 for ; Tue, 21 Apr 2009 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 4huYIF+FJsUh for ; Tue, 21 Apr 2009 06:48:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6BABB3A7034 for ; Tue, 21 Apr 2009 06:48:34 -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 n3LDnIbS010401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 16:49:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3LDnIQd008017; Tue, 21 Apr 2009 16:49:18 +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: <18925.52957.263655.220594@fireball.kivinen.iki.fi> Date: Tue, 21 Apr 2009 16:49:17 +0300 From: Tero Kivinen To: "Kalyani Garigipati (kagarigi)" In-Reply-To: <12CEFA6955F85042B5462C204F68519509280AAC@xmb-blr-415.apac.cisco.com> References: <99043b4a0904200009o7ae9e7b8wc31d4921c5a7f0b@mail.gmail.com> <12CEFA6955F85042B5462C204F68519509280AAC@xmb-blr-415.apac.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: ipsec@ietf.org Subject: [IPsec] Multiple payloads of same type X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:48:36 -0000 Kalyani Garigipati (kagarigi) writes: > Please validate if the following is true. > > Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM, > TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE, > DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads. Encrypt MUST be last packet, thus that also limits that there can be only one of such payloads in packet. For all others there is no explicit restriction that they cannot appear multiple times, but on the other hand the exchanges we now have do not ever put multiple SA, KE, IDi, IDr, AUTH, Ni/Nr (Nonce), TSi, TSr, or EAP payloads in the same packet. For CERT, CERTREQ, N (notify), D (delete), V (Vendor ID) it is clear that there CAN be multiple payloads of those types in same packet. For CP (configuration payload) it not clear whether there can be multiple or not, but I would expect most implementations expect to find only one, and will only use one. In future someone might make extensions which puts multiple CP payloads in same packet, but currently we do not have such. > Like if we get packet as HDR, SA1, SA1, KE, N > We should reject it ? Best would be to check first the exchange type, and check out that all mandatory payloads which are required for that are there. Also when parsing it should be quite ok to stop parsing immediately when you see for example 2nd encrypted payload, or 2nd SA payload (In IKEv1 we could have multiple SA payloads in one quick mode exchange, as there was option to create multiple IPsec SAs at once, but that is not allowed in IKEv2). After that parsing all optional payloads (notifies, vendor id payloads, etc). Then the question is whether there is any need to check if there is any extra payloads in the exchange, and if such is found what to do (lets say someone puts configuration payload as part of the IKE_SA_INIT instead of IKE_AUTH). For this there is no clear answer, if you want to be able to work with future extensions without breaking when seeing them, best might be just ignore them. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 21 06:52:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEA03A6906 for ; Tue, 21 Apr 2009 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 D+J6qKBcc6vM for ; Tue, 21 Apr 2009 06:52:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC6A3A6403 for ; Tue, 21 Apr 2009 06:52:11 -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 n3LDrIub025787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 16:53:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3LDrH5l022947; Tue, 21 Apr 2009 16:53:17 +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: <18925.53196.767742.233085@fireball.kivinen.iki.fi> Date: Tue, 21 Apr 2009 16:53:16 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4E60@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4E60@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 13:52:13 -0000 Yaron Sheffer writes: > However, given that normal NAT detection happens during IKE_SA_INIT, can you > clarify why this would work better if we had a 2 RT protocol? I think this should explain it: > > exchange too. Allowing IP-addresses change means that the network > > where the packets can come in, are different, meaning they might have > > misconfigured firewalls or similars there, and killing your resumption > > ticket by just trying to connect through broken firewall is bad idea. I.e if you are always assuming the network is same, you do not need to consider someone adding broken firewall in the middle. If on the other hand you just happen to try every WLAN your client sees on its way, there is most likely going to be few broken / misconfigured firewalls / NAT boxes etc on the way, and the 1 RT protocol will quite often use your ticket, without you ever noticing it, as reply packets will not reach you. I.e. it is not really change required by the protocol, but the operating environment changes to much more unreliable and untrusted, meaning the protocol should be more robust against attacks. -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Apr 21 10:55:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02043A7029 for ; Tue, 21 Apr 2009 10:55:35 -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.320, 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 NHto3x1kk67A for ; Tue, 21 Apr 2009 10:55:35 -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 D41D128C18C for ; Tue, 21 Apr 2009 10:55:34 -0700 (PDT) Received: from [10.20.30.163] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LHulkj071700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Apr 2009 10:56:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 21 Apr 2009 10:56:46 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Issue #102: What to do about {{ }} notation in ikev2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:55:36 -0000 Since its first draft, the IKEv2 bis document has had flags for where new text came from RFC 4718, such as "{{ Clarif-6.1 }}" and "{{ Clarif-4.2}}". Using a related notation, we have also marked where text that originally existed in the top-heavy listing of notifications has been moved into the body of the text that relates to the notification, such as {{ 3.10.1-17 }} and {{ 3.10.1-35 }}. Those were meant to help readers who were familiar with RFC 4306 find the changes. However, we have now made a slew of additional changes based on the WG discussions, and those changes are not marked except in the change log at the end of the document, which will disappear when the RFC is published. Can we get rid of the "{{ }}" notations in the next version of the draft? If not, how long do we want to keep them? --Paul Hoffman, Director --VPN Consortium From vidyan@qualcomm.com Tue Apr 21 14:58:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BC53A6AEB for ; Tue, 21 Apr 2009 14:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, 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 mBtuD+UN+3+5 for ; Tue, 21 Apr 2009 14:58:19 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 480A73A6A04 for ; Tue, 21 Apr 2009 14:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240351176; x=1271887176; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Tero=20Kivinen=20|CC:=20Yaron=20Sheffe r=20,=0D=0A=20=20=20=20=20=20=20 =20Paul=20Hoffman=0D=0A=09,=20IPse cme=20WG=20|Date:=20Tue,=2021=20Apr=20200 9=2014:59:32=20-0700|Subject:=20RE:=20[IPsec]=20Issue=20# 98:=201=20or=20two=20round=20trips=20for=20resumption |Thread-Topic:=20[IPsec]=20Issue=20#98:=201=20or=20two=20 round=20trips=20for=20resumption|Thread-Index:=20AcnCd9le v9B+OqPrQsWK6zkgNoop9wAULuEw|Message-ID:=20 |References:=20=0D =0A=09=0D=0A=09<7F9A6D26EB51614FBF9F81C0DA4C FEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com>=0D=0A=09=0D=0A=20<18925.45980.896489.919446@fireball.kivine n.iki.fi>|In-Reply-To:=20<18925.45980.896489.919446@fireb all.kivinen.iki.fi>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5591"=3B=20a=3D"17312879"; bh=hIC9zkmYNSV329aTaLbyJNHZ5kiwLiO6swpjMbguncs=; b=SeSLuNujAhWO9+HDHniTNMPgwbYtf7S1wHK8bT57qGinrFUDKquDQHAs +5sSvos1xAOxgMEkO86EERT6jYLjdRfjPDxWIu0BRbT1NpbK2LU7c1ze9 eR04PdtztRHZSW1GOqqFoe8QrDjy/9pkShWpRGWnjrq/ozOikXPbIcrOB I=; X-IronPort-AV: E=McAfee;i="5300,2777,5591"; a="17312879" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2009 14:59:35 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3LLxZnc002523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2009 14:59:35 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3LLxY1f007666 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Apr 2009 14:59:35 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 21 Apr 2009 14:59:34 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 21 Apr 2009 14:59:34 -0700 From: "Narayanan, Vidya" To: Tero Kivinen Date: Tue, 21 Apr 2009 14:59:32 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnCd9lev9B+OqPrQsWK6zkgNoop9wAULuEw Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> In-Reply-To: <18925.45980.896489.919446@fireball.kivinen.iki.fi> 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: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:58:20 -0000 >=20 > From the ipsecme charter: >=20 > Failover from one gateway to another, mechanisms for detecting > when a session should be resumed, and specifying communication > mechanisms between gateways are beyond the scope of this work > item. >=20 > Thus failover from one gateway to another is outside the scope of this > document. If I remember right most of the use cases in > draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not > resumption use cases. >=20 This is really just a terminology issue. Most of the use cases in that doc= ument are applicable to resumption. In fact, the current solution for resu= mption is based on what was produced as a result of that problem statement = (combined with Yaron's draft at the time), with the ability to exchange fai= lover gateway candidates removed. In other words, we are not handling anyt= hing specific to failovers, but, prior to this charter and WG, "failover" i= ncluded resumption in the work we did.=20 =20 >=20 > From the abstract of the resumption document: >=20 > To re-establish security associations (SAs) upon a failure recovery > condition is time consuming especially when an IPsec peer (such as a > VPN gateway) needs to re-establish a large number of SAs with > various > end points. A high number of concurrent sessions might cause > additional problems for an IPsec peer during SA re-establishment. >=20 > So at least it was seen as important use case, and is thats why > included in the abstract (and the ipsecme charter text). >=20 I'm not suggesting that it isn't important - just pointing out that it is n= ot the only use case for resumption. =20 > > And, in most cellular deployments, IPsec is used for untrusted > > access networks (e.g., WLAN), while the DHCP servers and AAA servers > > are accessible from other access networks as well. And, a handoff > > from cellular to WLAN needs to be seamless - you can envision an > > IPsec SA being set up all the time, but only resumed and actively > > used after you handoff to WLAN. >=20 > Hmm.. This is again something completely different what I tought for > what the resumption protocol is supposed for.=20 This has been discussed from the early days and I believe I've brought it u= p at almost every meeting, even at the last SFO session. As a contributor f= rom the mobile side, this is my primary use case for the resumption work. = =20 > For example for this use > it would be useful to have have some way to force deletion of the > state from the server, i.e. say that this IKE SA is now going to go to > sleep, so you can remove the state, and there is no need to do dead > peer detection on it.=20 Good point - it would be nice to avoid having to do DPD on it and this woul= d certainly be a useful feature if we wanted to consider it. =20 > The current protocol do not have anything like > that, and if you delete IKE SA you also delete the ticket, so that > mechanism cannot be used for that. >=20 > I still do not think making the 1 RT protocol to 2 RT protocol in that > case would really cause any noticeable effect to the actual handover. > Especially as you still most likely have the cellular network there to > be used,=20 This is conjecture and not a fact. And, I'd prefer to design for seamless,= quick handoffs, not with an assumption that you have a second interface up= .=20 > while you are doing DHCP + IKE_SESSION_RESUME etc on the > WLAN, thus only thing that is affected is that traffic moves 100ms > later from cellular to WLAN. >=20 And, btw, WLAN is only one type of untrusted network - other scenarios may = be cellular-to-cellular handoffs in roaming scenarios, cellular to WiMAX ha= ndoffs, etc. In some of these cases, there are even RF limitations if you a= re using a single radio, multi-mode chipset. I'd prefer that we keep the d= iscussion on the RF systems itself out and see what best we can do with our= protocols.=20 > On the other hand security problems are big issue, as you most likely > try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, > thus you effectively broadcast your tickets to attackers at will, so > attackers can simply take those tickets and sent them to server and > get your session resumed, but not forward any other traffic. Also any > firewall allowing port 500 packets out but not in, will cause similar > effect, as you will not get reply back, but server will consume your > ticket. >=20 Obviously, the firewalls need to be handled properly if the operator wants = this to work - so, that is not the primary issue. I don't understand what = you mean by "not forward any other traffic" in your description of the atta= ck. The attacker does not have the keys to decipher any of the actual pack= ets. The only thing the attacker can do is replay a ticket *after* it has a= lready been sent by the client - in this case, we already talked about some= limited backend state the gateway can maintain to limit the impact due to = replays. It is also important to note that the other backend entities (whi= ch was Pasi's main concern) are accessible through the so-called "trusted n= etworks" that often arguably have a reduced degree of security than the IPs= ec case. =20 > That case also brings out completely new issue which has not been > discussed before, i.e. whether the IKE_SESSION_RESUME must come from > the same IP-address than what was used before for the IKE SA, i.e. can > the IP-addresses change during the IKE_SESSION_RESUME.=20 The protocol does allow for IP address changes and also allows the client t= o request a new IP address from the gateway for its internal IP address - d= o you see a reason why this doesn't work?=20 > If that is > allowed, then what about NATs, i.e. is it allowed that even when there > was no NAT between hosts before, there is new NAT found during the > IKE_SESSION_RESUME? >=20 As Yaron indicated, NAT traversal will work here. And, designing for broken= firewalls and NATs as the primary case seems strange. =20 > Those are not covered by the current document, and at least something > MUST be said about those issues. Sure, adding text for these in a more explicit fashion would be fine. =20 > After this example use scenario, I am even more convinced that 2 RT > protocol is better and needed, especially if we do allow IP-addresses > change, and might need to do NAT-T detection on the IKE_SESSION_RESUME > exchange too. Allowing IP-addresses change means that the network > where the packets can come in, are different, meaning they might have > misconfigured firewalls or similars there, and killing your resumption > ticket by just trying to connect through broken firewall is bad idea. I don't understand why you need 2 RTs to account for IP address changes or = NAT-T. As I said, I don't want to design for broken firewalls as the prima= ry case - if there are broken firewalls, things may be slower, but, I don't= buy the argument that things should always be slower to account for possib= le broken firewalls.=20 Vidya > kivinen@iki.fi From rsjenwar@gmail.com Tue Apr 21 20:58:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BFE3A6887 for ; Tue, 21 Apr 2009 20:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.282 X-Spam-Level: X-Spam-Status: No, score=-0.282 tagged_above=-999 required=5 tests=[AWL=2.317, 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 bNs9DUnT5TM8 for ; Tue, 21 Apr 2009 20:58:50 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id DD0DC3A6A33 for ; Tue, 21 Apr 2009 20:58:49 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4282768ywh.49 for ; Tue, 21 Apr 2009 21:00:06 -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; bh=yrAMRW2IARMflDdBDjVl31hms6bDnktPU7RmTMcER8M=; b=wQ8+veNE/qAJej03BDMlpJZZd7KG8UykGgGo2qT1iz9D82oBhv26bXiu6p3GZDLsAS yalAlDtqCxZTfhPQVS5Ch5RewKvF1svwDxuwo12F64FfAfpngvzj+UP5lW/F8zCcGZgH 072zIE1S+oKR34GqZQQvdgrKK2vuwjriTb6qU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mJQLdfP3kd1+pGNgAJ8KJt6IfMjCorpGLtoo87c7W2EciwGbWTcjS9gFYO6PXUE1FK UhJTlPGEUiw1RZuyO6ZaTM+G51m0R1fc72eocvlGCNQoA1+FdfHVqrqXGOFB7570yQB0 9BXr0bQywChZezfELD1k9qFcYUMTEP3/YN6ZY= MIME-Version: 1.0 Received: by 10.100.164.20 with SMTP id m20mr1741388ane.31.1240372806322; Tue, 21 Apr 2009 21:00:06 -0700 (PDT) Date: Wed, 22 Apr 2009 09:30:06 +0530 Message-ID: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> From: raj singh To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e6434612828ad004681ccc58 Subject: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 03:59:51 -0000 --0016e6434612828ad004681ccc58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Group, What is the expected behavior if as a responder we do not receive TSi and TSr in IKE_AUTH exchange ? Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and TSr ? Or we should reject the packet ? If we reject the packet during packet validation with doing ID and AUTH payload processing, what ERROR should be send ? Thanks, Raj --0016e6434612828ad004681ccc58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Group,

What is the expected behavior if as a responder we do not receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should reject the packet ?
If we reject the packet during packet validation with doing ID and AUTH payload processing, what ERROR should be send ?

Thanks,
Raj

--0016e6434612828ad004681ccc58-- From mcins1@gmail.com Tue Apr 21 23:09:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD763A6CC0 for ; Tue, 21 Apr 2009 23:09:16 -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 zNH4iNXqLR5y for ; Tue, 21 Apr 2009 23:09:16 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id B895F3A6C5B for ; Tue, 21 Apr 2009 23:09:15 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1775349qwe.31 for ; Tue, 21 Apr 2009 23:10: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:content-type; bh=KVHc8DD5xHuqqukzGMAGZzG0R5cHFEUh7rzvkhhveZc=; b=YIwLZtb+yjCiPfkE7J8neKwMJkQ2jmMB0tdQ91YuRIRoJixTe3YPmub2JU1RyLDo0U 0eFZkZrVMt6/CcHbOgJSRc8FTpLpCspNUswcLC93K++ku+GqZcjotsyHA8TpB4zMmKPP Gqe2y/p6yCiDsDMiVvB/o0PNdBtNX2szPfSEM= 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 :content-type; b=u/YIaC8+T8eGmQlyuxTqrJejoTonnauwXzyxzNZi5q+nzX027L8/OO6CuLEwLdgq0k LRuuRqITVs/bgCPyDlNGXc+NqsqGs1rcQJcWGG5gPpCSkxEoUXhYkAD3IycdZuY/wIGg 4S5PQ7sbDrbk53FtWO2AyikLQ2jcC9OY4guvA= MIME-Version: 1.0 Received: by 10.220.98.197 with SMTP id r5mr10295935vcn.69.1240380631599; Tue, 21 Apr 2009 23:10:31 -0700 (PDT) In-Reply-To: <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> Date: Wed, 22 Apr 2009 08:10:31 +0200 Message-ID: <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> From: Matthew Cini Sarreo To: raj singh , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016e6470b68eeccb404681e9e5e Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:09:16 -0000 --0016e6470b68eeccb404681e9e5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA. It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response. Please correct me if I am wrong. Regards, Matt > 2009/4/22 raj singh > >> Hi Group, >> >> What is the expected behavior if as a responder we do not receive TSi and >> TSr in IKE_AUTH exchange ? >> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi >> and TSr ? >> Or we should reject the packet ? >> If we reject the packet during packet validation with doing ID and AUTH >> payload processing, what ERROR should be send ? >> >> Thanks, >> Raj >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --0016e6470b68eeccb404681e9e5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA.

= It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response.

Please correct me if I am wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Group,

What is the expected behavior if as a responder we do not = receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establi= sh IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should rejec= t the packet ?
If we reject the packet during packet validation with doing ID and AUTH pay= load processing, what ERROR should be send ?

Thanks,
Raj


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--0016e6470b68eeccb404681e9e5e-- From rsjenwar@gmail.com Tue Apr 21 23:27:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6173A6BD2 for ; Tue, 21 Apr 2009 23:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 bHafByCSpMJE for ; Tue, 21 Apr 2009 23:27:06 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 0B4383A69A8 for ; Tue, 21 Apr 2009 23:27:05 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so2209869ana.4 for ; Tue, 21 Apr 2009 23:28:22 -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; bh=PrzEOjgTjkTKIE9Ou0+/EfPfjK0/Y62uTU31YhZMIIg=; b=tCOz1bxroAC3vYlf+TYyPlvwSUYeXTpYCd0WLDmhmjObqY1rJ6UHgM3Nqdx1WCjS54 cB7l36iYY6WE5Vrc98e+o++n5DvttU/JkDW0Jp80UjSR7BDwiTjaaJndGD5YA9cS0I8x aC86p6jW4i2LQGqQKnrAD16PalrgblB1esCPg= 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; b=YryBN9IIo+J1jqW5YJs+SojW3YQW9p4NeM2DjcIuppUi3MTYPs2+Hw9H9vO54s+1YQ MUs8Xg7RcRiWQu66BhGPQEW4d12ZVYQRPegoczrHsHCsw9CGeNMkpsWCoEXyxl885+tI u/0b4pkOA1BL8Lay1SYkwjrVkYhgJAENjcufU= MIME-Version: 1.0 Received: by 10.100.248.16 with SMTP id v16mr10933025anh.60.1240381702470; Tue, 21 Apr 2009 23:28:22 -0700 (PDT) In-Reply-To: <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> Date: Wed, 22 Apr 2009 11:58:22 +0530 Message-ID: <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> From: raj singh To: Matthew Cini Sarreo Content-Type: multipart/alternative; boundary=0016369201d0c2fbf404681ede58 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:27:07 -0000 --0016369201d0c2fbf404681ede58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Matt, There is possibility of just IKEv2 SA gets established during IKE_AUTH and IPsec SA getting established via CREATE_CHILD_SA. The question is what behavior RFC mandate ? What you think ? Thanks for your reply. Regards, Raj On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo wrote: > In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them > from an authentication exchange message, as there would be no way for the SA > to know what traffic should be forwarded through the SA. > > It seems that the correct error message would be INVALID_SYNTAX. This would > require the message ID and the checksum to be valid. Note that this has (may > only) be sent in an encrypted response. > > Please correct me if I am wrong. > > Regards, > Matt > > >> 2009/4/22 raj singh >> >>> Hi Group, >>> >>> What is the expected behavior if as a responder we do not receive TSi and >>> TSr in IKE_AUTH exchange ? >>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi >>> and TSr ? >>> Or we should reject the packet ? >>> If we reject the packet during packet validation with doing ID and AUTH >>> payload processing, what ERROR should be send ? >>> >>> Thanks, >>> Raj >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >> > --0016369201d0c2fbf404681ede58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt,

There is possibility of just IKEv2 SA gets established duri= ng IKE_AUTH and IPsec SA getting established via CREATE_CHILD_SA.
The qu= estion is what behavior RFC mandate ? What you think ?

Thanks for yo= ur reply.

Regards,
Raj

On Wed, Apr 22, 2009 = at 11:40 AM, Matthew Cini Sarreo <mcins1@gmail.com> wrote:
In IKE_AUTH TSi and TSr are mandatory, so= it is not possible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA.

= It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response.

Please correct me if I am wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Group,

What is the expected behavior if as a responder we do not = receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establi= sh IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should rejec= t the packet ?
If we reject the packet during packet validation with doing ID and AUTH pay= load processing, what ERROR should be send ?

Thanks,
Raj


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec




--0016369201d0c2fbf404681ede58-- From mcins1@gmail.com Tue Apr 21 23:36:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA863A6CCB for ; Tue, 21 Apr 2009 23:36:50 -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 AbxO-insQo48 for ; Tue, 21 Apr 2009 23:36:50 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id BBD163A681E for ; Tue, 21 Apr 2009 23:36:49 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1783445qwe.31 for ; Tue, 21 Apr 2009 23:38:06 -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:content-type; bh=jGJoYAHGn07f4bRA6CjsdfHcX6dOw6B+cXZQ4RzQMMc=; b=n9SwjtROv/BJMMLFnhFxWWIAJ3HJ+3xSqwVj+pCMQPD9KPG4hoB3CyN3txTJAjwGDK PfOyIDyz/XD9DMHpJkFBsidg8UtziC9mbxQ9BEORPmPX301nCgHDDc2dZSi2Zl/Txazs 3Q35J3th22KZc8FftaP8vx6xWm2uVpu07qSgw= 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 :content-type; b=seyfYKQDfg/wyKcqkiJ4corK1bEiwlISMfo2D2awbiLPo7BgR5ps2BgkdAmiKRYgFw znWPrc/TXOryOLOHWe64HI5oNm8jn/L6xcWTl2rDIO2q6XQFs8rVQOg/sIn168Paj0NM FPpHWFXkYJlZv3GgcmzlQo84ZGmfc00DCmb9s= MIME-Version: 1.0 Received: by 10.220.84.78 with SMTP id i14mr6818517vcl.25.1240382284205; Tue, 21 Apr 2009 23:38:04 -0700 (PDT) In-Reply-To: <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> Date: Wed, 22 Apr 2009 08:38:04 +0200 Message-ID: <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> From: Matthew Cini Sarreo To: raj singh , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016364ee54c70a89d04681f0197 Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:36:51 -0000 --0016364ee54c70a89d04681f0197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Raj, According to Appendix C, for IKE_AUTH: error in Child SA <-- IDr, [CERT+], creation AUTH, N(error), [V+] So sending an authenticated and encrypted INVALID_SYNTAX notification over the IKE_SA that has just been authenticated seems to be correct. Regards, Matt > > 2009/4/22 raj singh > >> Hi Matt, >> >> There is possibility of just IKEv2 SA gets established during IKE_AUTH and >> IPsec SA getting established via CREATE_CHILD_SA. >> The question is what behavior RFC mandate ? What you think ? >> >> Thanks for your reply. >> >> Regards, >> Raj >> >> >> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo wrote: >> >>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them >>> from an authentication exchange message, as there would be no way for the SA >>> to know what traffic should be forwarded through the SA. >>> >>> It seems that the correct error message would be INVALID_SYNTAX. This >>> would require the message ID and the checksum to be valid. Note that this >>> has (may only) be sent in an encrypted response. >>> >>> Please correct me if I am wrong. >>> >>> Regards, >>> Matt >>> >>> >>>> 2009/4/22 raj singh >>>> >>>>> Hi Group, >>>>> >>>>> What is the expected behavior if as a responder we do not receive TSi >>>>> and TSr in IKE_AUTH exchange ? >>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out >>>>> TSi and TSr ? >>>>> Or we should reject the packet ? >>>>> If we reject the packet during packet validation with doing ID and AUTH >>>>> payload processing, what ERROR should be send ? >>>>> >>>>> Thanks, >>>>> Raj >>>>> >>>>> >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>>> >>>> >>> >> > --0016364ee54c70a89d04681f0197 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Raj,

According to Appendix C, = for IKE_AUTH:

=A0=A0 error in Child SA=A0 <--=A0 IDr, [CERT+],=A0=A0 creation=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AUTH,
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0 =A0 N(error),
=A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX notification over the IKE_SA that has just been authenticated seems to be correct.

Regards,
Matt
=A0

2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Matt,

T= here is possibility of just IKEv2 SA gets established during IKE_AUTH and I= Psec SA getting established via CREATE_CHILD_SA.
The question is what behavior RFC mandate ? What you think ?

Thanks = for your reply.

Regards,
Raj

=
On Wed, Apr 22, 2009 at 11:40 AM, Matthew Ci= ni Sarreo <mcins1@gmail.com> wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not po= ssible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA.

= It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response.

Please correct me if I am wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Group,

What is the expected behavior if as a responder we do not = receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establi= sh IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should rejec= t the packet ?
If we reject the packet during packet validation with doing ID and AUTH pay= load processing, what ERROR should be send ?

Thanks,
Raj


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec






--0016364ee54c70a89d04681f0197-- From ldondeti@qualcomm.com Tue Apr 21 23:47:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0973A6A48 for ; Tue, 21 Apr 2009 23:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 Zw-0UtwqqIdm for ; Tue, 21 Apr 2009 23:47:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id DB1963A6A0B for ; Tue, 21 Apr 2009 23:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240382943; x=1271918943; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49EEBDD3.2070706@qualcomm.com>|Date:=20We d,=2022=20Apr=202009=2012:18:51=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Tero=20Kivinen=20|CC:=20"Narayanan,=20Vidya"=20 ,=20IPsecme=20WG=20,=0D=0A=20=20=20=20=20 =20=20=20Paul=20Hoffman=20 |Subject:=20Re:=20[IPsec]=20Issue=20#98:=201=20or=20two =20round=20trips=20for=20resumption|References:=20=09=09<7F9A6D 26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoin t.com>=09=20<18925.45980.896489.919446@fireb all.kivinen.iki.fi>|In-Reply-To:=20<18925.45980.896489.91 9446@fireball.kivinen.iki.fi>|Content-Type:=20text/plain =3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5591"=3B=20a=3D"17336453"; bh=qBoS9GlJTRqq0eulhm0eCp1kFQKwpET9wv22xdAOqKs=; b=apqmNfXM0Tem0GklRokmWSJhOtPkoseooU441O3TQwjCz77SYE1CNKBl AFzEVdanViq4d5nE0ToKbDFr/JcMA5z5lKRaN1lzeVp5NOIyPDEEmJrcz iNBmuEHrq5b5ElIkhvmCBHChIytJgk8p3jXrA6h1BHHpumbyQPXAJeJeX s=; X-IronPort-AV: E=McAfee;i="5300,2777,5591"; a="17336453" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2009 23:49:02 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3M6n2Ho016261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2009 23:49:02 -0700 Received: from [10.44.81.72] (ldondetixp2.ap.qualcomm.com [10.44.81.72]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3M6mqr8022749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Apr 2009 23:48:56 -0700 Message-ID: <49EEBDD3.2070706@qualcomm.com> Date: Wed, 22 Apr 2009 12:18:51 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tero Kivinen References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> In-Reply-To: <18925.45980.896489.919446@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:47:47 -0000 On 4/21/2009 5:23 PM, Tero Kivinen wrote: > > I still do not think making the 1 RT protocol to 2 RT protocol in that > case would really cause any noticeable effect to the actual handover. > Hi Tero, How do you know this? I ask because, I would like to use those arguments to tell people who are experts in handovers that multiple RTs don't matter. > Especially as you still most likely have the cellular network there to > be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the > WLAN, thus only thing that is affected is that traffic moves 100ms > later from cellular to WLAN. > > On the other hand security problems are big issue, as you most likely > How do we know that they are a "big" issue? Do we expect these systems to be under attack most of their operational life? > try to IKE_SESSION_RESUME exchange over any WLAN you happen to see, > thus you effectively broadcast your tickets to attackers at will, so > attackers can simply take those tickets and sent them to server and > get your session resumed, but not forward any other traffic. Also any > firewall allowing port 500 packets out but not in, will cause similar > effect, as you will not get reply back, but server will consume your > ticket. > Even if this happens, the payoff for the attacker is very little since the legitimate parties can always establish another connection. The quality of experience would be bad because another session needs to be established when under attack, but at the cost the attacker has to pay, one might even say that this is not even a serious threat. I really would liked to be convinced that I am wrong here, but I see this to be a quite moderate or low risk attack. thanks, Lakshminath > That case also brings out completely new issue which has not been > discussed before, i.e. whether the IKE_SESSION_RESUME must come from > the same IP-address than what was used before for the IKE SA, i.e. can > the IP-addresses change during the IKE_SESSION_RESUME. If that is > allowed, then what about NATs, i.e. is it allowed that even when there > was no NAT between hosts before, there is new NAT found during the > IKE_SESSION_RESUME? > > Those are not covered by the current document, and at least something > MUST be said about those issues. > > After this example use scenario, I am even more convinced that 2 RT > protocol is better and needed, especially if we do allow IP-addresses > change, and might need to do NAT-T detection on the IKE_SESSION_RESUME > exchange too. Allowing IP-addresses change means that the network > where the packets can come in, are different, meaning they might have > misconfigured firewalls or similars there, and killing your resumption > ticket by just trying to connect through broken firewall is bad idea. > From rsjenwar@gmail.com Tue Apr 21 23:50:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93E93A6A62 for ; Tue, 21 Apr 2009 23:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=1.158, 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 39Iz9KEUjv-j for ; Tue, 21 Apr 2009 23:50:03 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 95AB43A6A0B for ; Tue, 21 Apr 2009 23:50:03 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4357232ywh.49 for ; Tue, 21 Apr 2009 23:51:20 -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; bh=enJt++pEZ89izPCviewQUO3KzK6t8OAtBblcMRTEXcI=; b=TRrXVHdX/fXb7PMbixuuZIOG6RMrzu22C8QRK2bdaV7m9/Hyy0UzI/A+sbXUtPT1TX x0di9fCr8ztAhOV6KbaZ/xvRMpSF/tEKcl33gxzTpdxrlW/1yiN7UDBrmPjiinOEqG09 hr08DG/sN9IVE9/yxosyoFVeGF+NJX1USdOpY= 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; b=OAyvN5JBZ1XktvAZaLXvnZuDrU+MlqrDjpprDfxi+u1HIqNwV6Ic1ATEc9pJD9TIjr kO5jjm45kbC1KP2r1WdzbByrwmAJA0QcsmN4nXwa/SbWAQfdfapXCzetWjVDCxZJ4teO hTUMZ3U6U9hliXJXXJgIam1XjimW+RJ3w4Gck= MIME-Version: 1.0 Received: by 10.100.189.10 with SMTP id m10mr4922686anf.47.1240383080352; Tue, 21 Apr 2009 23:51:20 -0700 (PDT) In-Reply-To: <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> Date: Wed, 22 Apr 2009 12:21:20 +0530 Message-ID: <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> From: raj singh To: Matthew Cini Sarreo Content-Type: multipart/alternative; boundary=0016e64355e4e3ccef04681f3077 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:50:04 -0000 --0016e64355e4e3ccef04681f3077 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Matt, Let me re-phrase my questions: 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process IKE_AUTH payloads or not ? 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into picture if we process the packet. If we go ahead and process the packet, according to appendix C, we SHOULD/MUST establish the IKE SA ? Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and TSr, we can establish the IKEv2 SA. I request more experts to comment. Thanks for your reply. Regards, Raj On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote: > Hello Raj, > > According to Appendix C, for IKE_AUTH: > > error in Child SA <-- IDr, [CERT+], > creation AUTH, > N(error), > [V+] > > So sending an authenticated and encrypted INVALID_SYNTAX notification over > the IKE_SA that has just been authenticated seems to be correct. > > Regards, > Matt > > >> >> 2009/4/22 raj singh >> >>> Hi Matt, >>> >>> There is possibility of just IKEv2 SA gets established during IKE_AUTH >>> and IPsec SA getting established via CREATE_CHILD_SA. >>> The question is what behavior RFC mandate ? What you think ? >>> >>> Thanks for your reply. >>> >>> Regards, >>> Raj >>> >>> >>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo wrote: >>> >>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit >>>> them from an authentication exchange message, as there would be no way for >>>> the SA to know what traffic should be forwarded through the SA. >>>> >>>> It seems that the correct error message would be INVALID_SYNTAX. This >>>> would require the message ID and the checksum to be valid. Note that this >>>> has (may only) be sent in an encrypted response. >>>> >>>> Please correct me if I am wrong. >>>> >>>> Regards, >>>> Matt >>>> >>>> >>>>> 2009/4/22 raj singh >>>>> >>>>>> Hi Group, >>>>>> >>>>>> What is the expected behavior if as a responder we do not receive TSi >>>>>> and TSr in IKE_AUTH exchange ? >>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out >>>>>> TSi and TSr ? >>>>>> Or we should reject the packet ? >>>>>> If we reject the packet during packet validation with doing ID and >>>>>> AUTH payload processing, what ERROR should be send ? >>>>>> >>>>>> Thanks, >>>>>> Raj >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IPsec mailing list >>>>>> IPsec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>> >>>>>> >>>>> >>>> >>> >> > --0016e64355e4e3ccef04681f3077 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt,

Let me re-phrase my questions:
1. If there is no TSi and= TSr payload in IKE_AUTH exchange, whether we go ahead and process IKE_AUTH= payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA creation. = It will come into picture if we process the packet.
=C2=A0=C2=A0=C2=A0 If we go ahead and process the packet, according to appe= ndix C, we SHOULD/MUST establish the IKE SA ?
=C2=A0=C2=A0=C2=A0 Looks l= ike, if we go ahead to process the IKE_AUTH packet with no TSi and TSr, we = can establish the IKEv2 SA.

I request more experts to comment.

Thanks for your reply.
Regards,
Raj

On Wed, Apr 22, 2009 at = 12:08 PM, Matthew Cini Sarreo <mcins1@gmail.com> wrote:
<= div class=3D"h5">
Hello Raj,

Accordin= g to Appendix C, for IKE_AUTH:

=C2=A0=C2=A0 error in Child SA=C2=A0 <--=C2=A0 IDr, [CERT+],
=C2= =A0=C2=A0 creation=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AUTH,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 N(error),
= =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX notification over the IKE_SA that has just been authenticated seems to be correct.

Regards,
Matt
=C2=A0

2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Matt,

T= here is possibility of just IKEv2 SA gets established during IKE_AUTH and I= Psec SA getting established via CREATE_CHILD_SA.
The question is what behavior RFC mandate ? What you think ?

Thanks = for your reply.

Regards,
Raj

=
On Wed, Apr 22, 2009 at 11:40 AM, Matthew Ci= ni Sarreo <mcins1@gmail.com> wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not po= ssible to omit them from an authentication exchange message, as there would be no way for the SA to know what traffic should be forwarded through the SA.

= It seems that the correct error message would be INVALID_SYNTAX. This would require the message ID and the checksum to be valid. Note that this has (may only) be sent in an encrypted response.

Please correct me if I am wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Group,

What is the expected behavior if as a responder we do not = receive TSi and TSr in IKE_AUTH exchange ?
Shall we go ahead and establi= sh IKEv2 SA ? If yes, shall we send out TSi and TSr ?
Or we should rejec= t the packet ?
If we reject the packet during packet validation with doing ID and AUTH pay= load processing, what ERROR should be send ?

Thanks,
Raj


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec







--0016e64355e4e3ccef04681f3077-- From ynir@checkpoint.com Wed Apr 22 00:38:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF2E28C1BD for ; Wed, 22 Apr 2009 00:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014, 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 dquHV5phTfGA for ; Wed, 22 Apr 2009 00:38:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 524C528C428 for ; Wed, 22 Apr 2009 00:38:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 78AAA30C002; Wed, 22 Apr 2009 10:39:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2B8862CC003; Wed, 22 Apr 2009 10:39:32 +0300 (IDT) X-CheckPoint: {49EEC5E8-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 n3M7dVqO012182; Wed, 22 Apr 2009 10:39:31 +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; Wed, 22 Apr 2009 10:39:31 +0300 From: Yoav Nir To: raj singh , Matthew Cini Sarreo Date: Wed, 22 Apr 2009 10:41:31 +0300 Thread-Topic: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr Thread-Index: AcnDFsK67pRcoM+3TEKEBTLNdA9B+AABhfJQ Message-ID: <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> In-Reply-To: <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361338597890ilex01adcheck_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 07:38:18 -0000 --_000_9FB7C7CE79B84449B52622B506C780361338597890ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and= then wait for traffic to establish the child SAs. While we do establish an IKE SA if the piggy-backed child SA failed for wha= tever reason (bad selectors, no proposal chosen), we don't allow for an IKE= _AUTH exchange that is missing the child payloads. An IKE_AUTH request without the TSi and TSr payloads is considered malforme= d, and so MUST NOT be processed. Instead, you should reply with INVALID_SYN= TAX As to question 2, the text refers to a child SA creation that failed, not t= o one that was never attempted. Of course it is possible to generate that effect - propose non-existant cry= ptographic algorithms, or IPv7 addresses in the selectors, but that IMO is = a misuse of the protocol. Yoav Raj Singh wrote: Hi Matt, Let me re-phrase my questions: 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go a= head and process IKE_AUTH payloads or not ? 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into pict= ure if we process the packet. If we go ahead and process the packet, according to appendix C, we SHOU= LD/MUST establish the IKE SA ? Looks like, if we go ahead to process the IKE_AUTH packet with no TSi a= nd TSr, we can establish the IKEv2 SA. I request more experts to comment. Thanks for your reply. Regards, Raj On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo > wrote: Hello Raj, According to Appendix C, for IKE_AUTH: error in Child SA <-- IDr, [CERT+], creation AUTH, N(error), [V+] So sending an authenticated and encrypted INVALID_SYNTAX notification over = the IKE_SA that has just been authenticated seems to be correct. Regards, Matt 2009/4/22 raj singh > Hi Matt, There is possibility of just IKEv2 SA gets established during IKE_AUTH and = IPsec SA getting established via CREATE_CHILD_SA. The question is what behavior RFC mandate ? What you think ? Thanks for your reply. Regards, Raj On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo > wrote: In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them f= rom an authentication exchange message, as there would be no way for the SA= to know what traffic should be forwarded through the SA. It seems that the correct error message would be INVALID_SYNTAX. This would= require the message ID and the checksum to be valid. Note that this has (m= ay only) be sent in an encrypted response. Please correct me if I am wrong. Regards, Matt 2009/4/22 raj singh > Hi Group, What is the expected behavior if as a responder we do not receive TSi and T= Sr in IKE_AUTH exchange ? Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi an= d TSr ? Or we should reject the packet ? If we reject the packet during packet validation with doing ID and AUTH pay= load processing, what ERROR should be send ? Thanks, Raj _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361338597890ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Raj
 <= /DIV>
Matt is correct. There is no way in IKEv2 to do a pha= se1-only=20 exchange, and then wait for traffic to establish the child=20 SAs.  
 <= /DIV>
While we do establish an IKE SA if the piggy-bac= ked child=20 SA failed for whatever reason (bad selectors, no proposal chosen), we = don't=20 allow for an IKE_AUTH exchange that is missing the child=20 payloads.
 <= /DIV>
An IKE_AUTH request without the TSi and TSr payloads = is=20 considered malformed, and so MUST NOT be processed. Instead,= you=20 should reply with INVALID_SYNTAX
 <= /DIV>
As to question 2, the text refers to a child SA creat= ion that=20 failed, not to one that was never attempted.
 <= /DIV>
Of course it is possible to generate that effect - pr= opose=20 non-existant cryptographic algorithms, or IPv7 addresses in the selectors, = but=20 that IMO is a misuse of the protocol.
 <= /DIV>
Yoav 
 <= BR>Raj = Singh=20 wrote:
Hi Matt,

Let me re-phrase my questions:
1. If there = is no=20 TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process= =20 IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA= =20 creation. It will come into picture if we process the=20 packet.
    If we go ahead and process the packet, acco= rding=20 to appendix C, we SHOULD/MUST establish the IKE SA ?
   = ;=20 Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and= TSr,=20 we can establish the IKEv2 SA.

I request more experts to=20 comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini S= arreo=20 <mcins1@gmail.com> wrote:
Hello Raj,

According to Appendix C, for=20 IKE_AUTH:

   error in Child SA  <--  IDr,= =20 [CERT+],
  =20 creation          &nb= sp;    =20 AUTH,
          &n= bsp;            = ;  =20     N(error),
   =20             = ;            &n= bsp;=20 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX=20 notification over the IKE_SA that has just been authenticated seems to = be=20 correct.

Regards,
Matt
 

2009/4/22 raj singh <rsjenwar@gmail.com><= BR> Hi Matt,

There is possibility of just IKEv= 2 SA=20 gets established during IKE_AUTH and IPsec SA getting established v= ia=20 CREATE_CHILD_SA.
The question is what behavior RFC mandate ? Wha= t you=20 think ?

Thanks for your reply.

Regards,
Raj


On Wed, Apr 22, 2009 at 11:40 AM, Matthew = Cini=20 Sarreo <mcins1@gmail.com>=20 wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not possible= to=20 omit them from an authentication exchange message, as there would= be=20 no way for the SA to know what traffic should be forwarded throug= h the=20 SA.

It seems that the correct error message would be=20 INVALID_SYNTAX. This would require the message ID and the checksu= m to=20 be valid. Note that this has (may only) be sent in an encrypted=20 response.

Please correct me if I am=20 wrong.

Regards,
Matt


2009/4/22 raj singh &l= t;rsjenwar@gmail.com>
Hi Group,

What is the expected behavior if as a=20 responder we do not receive TSi and TSr in IKE_AUTH exchange= =20 ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall= we=20 send out TSi and TSr ?
Or we should reject the packet ? If=20 we reject the packet during packet validation with doing ID a= nd=20 AUTH payload processing, what ERROR should be send=20 ?

Thanks,
Raj


___________= ____________________________________
IPsec=20 mailing list
IPsec@ietf.org
https://= www.ietf.org/mailman/listinfo/ipsec








= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361338597890ilex01adcheck_-- From kivinen@iki.fi Wed Apr 22 01:59:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2EC3A6C5E for ; Wed, 22 Apr 2009 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Y28Mx-VqVeBg for ; Wed, 22 Apr 2009 01:59:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A314F3A6A84 for ; Wed, 22 Apr 2009 01:59:23 -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 n3M90XOS024610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 12:00:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3M90WNI018839; Wed, 22 Apr 2009 12:00:32 +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: <18926.56496.714752.17942@fireball.kivinen.iki.fi> Date: Wed, 22 Apr 2009 12:00:32 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG Subject: [IPsec] Issue #102: What to do about {{ }} notation in ikev2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 08:59:25 -0000 Paul Hoffman writes: > Since its first draft, the IKEv2 bis document has had flags for > where new text came from RFC 4718, such as "{{ Clarif-6.1 }}" and > "{{ Clarif-4.2}}". Using a related notation, we have also marked > where text that originally existed in the top-heavy listing of > notifications has been moved into the body of the text that relates > to the notification, such as {{ 3.10.1-17 }} and {{ 3.10.1-35 }}. Those have been helpful few times. > Can we get rid of the "{{ }}" notations in the next version of the > draft? If not, how long do we want to keep them? I think we can get rid of those {{ }} marks now, as I think all changes from the clarifications rfc are already in. If someone still needs to find where the change came from, he can get this -02 version and check the markings from there. -- kivinen@iki.fi From rsjenwar@gmail.com Wed Apr 22 02:06:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11AD83A70FB for ; Wed, 22 Apr 2009 02:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.772, 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 MHHyNWtgzIqR for ; Wed, 22 Apr 2009 02:06:15 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 808593A70FD for ; Wed, 22 Apr 2009 02:05:57 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4411884ywh.49 for ; Wed, 22 Apr 2009 02:07:14 -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; bh=qILs8G4RMxX/y9L1Irxb71makA8I+ae3HaOtsTnT49s=; b=jeumLSIh30v8JFJn+WfkIsiEwXiiCsC0q8DtoaoA+/mq1S7YLCAqMLp+NYWoa1iNgB mhCC4PiwBGgReRHiG+zw26KMy70+3LMfwL8KXgHyqTmGDcjhXjYzquVtPPLECgZetD0T rr/GbW9TjBS95BiOvR4mmxo1u3+Ji+FnMOlVc= 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; b=FJopk9o+7hR+rnJX03aLP5b96FLV2rtOspK/obcWy2HYyrb4VCG4swsIF+dxhz/KDC Xv1VSIIo6uF3zJhslmknT94CwDFzxXbNCU3VP39KmYJtvVszIbw/YrF7MiK5qgbbgA6W PlGgaK3plBhGi9g1ZQ7bjoZSHLysKRoy5XNK8= MIME-Version: 1.0 Received: by 10.100.120.15 with SMTP id s15mr25801anc.3.1240391234264; Wed, 22 Apr 2009 02:07:14 -0700 (PDT) In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> Date: Wed, 22 Apr 2009 14:37:14 +0530 Message-ID: <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> From: raj singh To: Yoav Nir Content-Type: multipart/alternative; boundary=0016e644cc68e6ae0004682116ac Cc: "ipsec@ietf.org" , Matthew Cini Sarreo Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 09:06:17 -0000 --0016e644cc68e6ae0004682116ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Matt/Youv, Thanks for your reply. I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST NOT process IKE_AUTH packet without TSi and TSr and we should reply with INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads. Regards, Raj On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir wrote: > Hi Raj > > Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and > then wait for traffic to establish the child SAs. > > While we do establish an IKE SA if the piggy-backed child SA failed for > whatever reason (bad selectors, no proposal chosen), we don't allow for an > IKE_AUTH exchange that is missing the child payloads. > > An IKE_AUTH request without the TSi and TSr payloads is > considered malformed, and so MUST NOT be processed. Instead, you should > reply with INVALID_SYNTAX > > As to question 2, the text refers to a child SA creation that failed, not > to one that was never attempted. > > Of course it is possible to generate that effect - propose non-existant > cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO > is a misuse of the protocol. > > Yoav > > Raj Singh wrote: > > Hi Matt, > > Let me re-phrase my questions: > 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go > ahead and process IKE_AUTH payloads or not ? > 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into > picture if we process the packet. > If we go ahead and process the packet, according to appendix C, we > SHOULD/MUST establish the IKE SA ? > Looks like, if we go ahead to process the IKE_AUTH packet with no TSi > and TSr, we can establish the IKEv2 SA. > > I request more experts to comment. > > Thanks for your reply. > > Regards, > Raj > > On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote: > >> Hello Raj, >> >> According to Appendix C, for IKE_AUTH: >> >> error in Child SA <-- IDr, [CERT+], >> creation AUTH, >> N(error), >> [V+] >> >> So sending an authenticated and encrypted INVALID_SYNTAX notification over >> the IKE_SA that has just been authenticated seems to be correct. >> >> Regards, >> Matt >> >> >>> >>> 2009/4/22 raj singh >>> >>>> Hi Matt, >>>> >>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH >>>> and IPsec SA getting established via CREATE_CHILD_SA. >>>> The question is what behavior RFC mandate ? What you think ? >>>> >>>> Thanks for your reply. >>>> >>>> Regards, >>>> Raj >>>> >>>> >>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo >>> > wrote: >>>> >>>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit >>>>> them from an authentication exchange message, as there would be no way for >>>>> the SA to know what traffic should be forwarded through the SA. >>>>> >>>>> It seems that the correct error message would be INVALID_SYNTAX. This >>>>> would require the message ID and the checksum to be valid. Note that this >>>>> has (may only) be sent in an encrypted response. >>>>> >>>>> Please correct me if I am wrong. >>>>> >>>>> Regards, >>>>> Matt >>>>> >>>>> >>>>>> 2009/4/22 raj singh >>>>>> >>>>>>> Hi Group, >>>>>>> >>>>>>> What is the expected behavior if as a responder we do not receive TSi >>>>>>> and TSr in IKE_AUTH exchange ? >>>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out >>>>>>> TSi and TSr ? >>>>>>> Or we should reject the packet ? >>>>>>> If we reject the packet during packet validation with doing ID and >>>>>>> AUTH payload processing, what ERROR should be send ? >>>>>>> >>>>>>> Thanks, >>>>>>> Raj >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> IPsec mailing list >>>>>>> IPsec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > Email secured by Check Point > > --0016e644cc68e6ae0004682116ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt/Youv,

Thanks for your reply.
I will conclude as IKE_AUTH = exchange MUST have TSi and TSr payload. We MUST NOT process IKE_AUTH packet= without TSi and TSr and we should reply with INVALID_SYNTAX notification w= ithout IDr, AUTH, TSi and TSr payloads.

Regards,
Raj

On Wed, Apr 22, 2009 = at 1:11 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Raj
=C2=A0
Matt is correct. There is no way in IKEv2 to do a phase1-only= =20 exchange, and then wait for=C2=A0traffic to=C2=A0establish the child=20 SAs.=C2=A0=C2=A0
=C2=A0
While we=C2=A0do establish an IKE SA if the piggy-backed child= =20 SA=C2=A0failed for whatever reason (bad selectors, no proposal chosen), we = don't=20 allow for an IKE_AUTH exchange that is missing the child=20 payloads.
=C2=A0
An IKE_AUTH request without the TSi and TSr payloads is=20 considered=C2=A0malformed, and=C2=A0so=C2=A0MUST NOT be processed. Instead,= you=20 should reply with INVALID_SYNTAX
=C2=A0
As to question 2, the text refers to a child SA creation that= =20 failed, not to one that was never attempted.
=C2=A0
Of course it is possible to generate that effect - propose=20 non-existant cryptographic algorithms, or IPv7 addresses in the selectors, = but=20 that IMO is a misuse of the protocol.
=C2=A0
Yoav=C2=A0
=C2=A0
Raj Singh=20 wrote:
Hi Matt,

Let me re-phrase my questions:
1. If there = is no=20 TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process= =20 IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA= =20 creation. It will come into picture if we process the=20 packet.
=C2=A0=C2=A0=C2=A0 If we go ahead and process the packet, acco= rding=20 to appendix C, we SHOULD/MUST establish the IKE SA ?
=C2=A0=C2=A0=C2= =A0=20 Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and= TSr,=20 we can establish the IKEv2 SA.

I request more experts to=20 comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini= Sarreo=20 <mcins1@gmail.com> wrote:
Hello Raj,

According to Appendix C, for=20 IKE_AUTH:

=C2=A0=C2=A0 error in Child SA=C2=A0 <--=C2=A0 IDr,= =20 [CERT+],
=C2=A0=C2=A0=20 creation=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=20 AUTH,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=20 =C2=A0 =C2=A0 N(error),
=C2=A0 =C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX=20 notification over the IKE_SA that has just been authenticated seems to = be=20 correct.

Regards,
Matt
=C2=A0

2009/4/22 raj singh <= rsjenwar@gmail.com<= /a>>
Hi Matt,
There is possibility of just IKEv2 SA=20 gets established during IKE_AUTH and IPsec SA getting established v= ia=20 CREATE_CHILD_SA.
The question is what behavior RFC mandate ? Wha= t you=20 think ?

Thanks for your reply.

Regards,
Raj


On Wed, Apr 22, 2009 at 11:40 AM, Matthe= w Cini=20 Sarreo <mcins1@gmail.com>=20 wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not possible= to=20 omit them from an authentication exchange message, as there would= be=20 no way for the SA to know what traffic should be forwarded throug= h the=20 SA.

It seems that the correct error message would be=20 INVALID_SYNTAX. This would require the message ID and the checksu= m to=20 be valid. Note that this has (may only) be sent in an encrypted= =20 response.

Please correct me if I am=20 wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmai= l.com>
Hi Group,

What is the expected behavior if as a= =20 responder we do not receive TSi and TSr in IKE_AUTH exchange= =20 ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall= we=20 send out TSi and TSr ?
Or we should reject the packet ? If=20 we reject the packet during packet validation with doing ID a= nd=20 AUTH payload processing, what ERROR should be send=20 ?

Thanks,
Raj


_______________________________________________
IPsec= =20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec=



=






Email secured by Check Point


--0016e644cc68e6ae0004682116ac-- From mcins1@gmail.com Wed Apr 22 02:17:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847B028C48E for ; Wed, 22 Apr 2009 02:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.417, 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 LKA7+rSpmV5P for ; Wed, 22 Apr 2009 02:17:36 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 9517828C457 for ; Wed, 22 Apr 2009 02:17:32 -0700 (PDT) Received: by qyk42 with SMTP id 42so4166177qyk.29 for ; Wed, 22 Apr 2009 02:18:47 -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:content-type; bh=Okq4N9hV8elLASuIAra8gzc9Nb5k8WtnouctZKFKnt4=; b=OBcPtyQeUrwIjJq4MlNAc4A+hrP/9mXVVFANuKC4rp6WHinZSyCfO29HOLzEaKKR92 s8qnh8W5qutfIdQ94+PE8x9OjBAxoM+xQ5Cm9RMqbDrNmDCmxX2t/iyXjR8EkNNOub6f sNu1+uKZmPuUKnW/5jp7ZjbyIeLbj2f3eSNqI= 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 :content-type; b=VSdEBgONOfJM5rHdmXhDAgoW2Tz20Hp/A3sA/CJ0sNmfD7+WOm5EN1zLMGg6benXgB IPI4J7xF5ZPOORPofp26zRe7rxWW+0Wn+j3klFZ0ENCPoUhZmBGhhBFiQ+KH6u+2ZWLK k6r0RhTG+sbconNiInNYP1hqxH9Q1vq/xoriY= MIME-Version: 1.0 Received: by 10.220.76.21 with SMTP id a21mr10226675vck.95.1240391927252; Wed, 22 Apr 2009 02:18:47 -0700 (PDT) In-Reply-To: <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> Date: Wed, 22 Apr 2009 11:18:47 +0200 Message-ID: <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> From: Matthew Cini Sarreo To: raj singh , Yoav Nir , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016e647ee5e34c72f04682140ef Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 09:17:37 -0000 --0016e647ee5e34c72f04682140ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Raj, You still need the IDr and AUTH payloads in the reply. This is needed as INVALID_SYNTAX is authenticated and encrypted. Regards, Matt 2009/4/22 raj singh > Hi Matt/Youv, > > Thanks for your reply. > I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST > NOT process IKE_AUTH packet without TSi and TSr and we should reply with > INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads. > > Regards, > Raj > > > On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir wrote: > >> Hi Raj >> >> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, >> and then wait for traffic to establish the child SAs. >> >> While we do establish an IKE SA if the piggy-backed child SA failed for >> whatever reason (bad selectors, no proposal chosen), we don't allow for an >> IKE_AUTH exchange that is missing the child payloads. >> >> An IKE_AUTH request without the TSi and TSr payloads is >> considered malformed, and so MUST NOT be processed. Instead, you should >> reply with INVALID_SYNTAX >> >> As to question 2, the text refers to a child SA creation that failed, not >> to one that was never attempted. >> >> Of course it is possible to generate that effect - propose non-existant >> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO >> is a misuse of the protocol. >> >> Yoav >> >> Raj Singh wrote: >> >> Hi Matt, >> >> Let me re-phrase my questions: >> 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go >> ahead and process IKE_AUTH payloads or not ? >> 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into >> picture if we process the packet. >> If we go ahead and process the packet, according to appendix C, we >> SHOULD/MUST establish the IKE SA ? >> Looks like, if we go ahead to process the IKE_AUTH packet with no TSi >> and TSr, we can establish the IKEv2 SA. >> >> I request more experts to comment. >> >> Thanks for your reply. >> >> Regards, >> Raj >> >> On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote: >> >>> Hello Raj, >>> >>> According to Appendix C, for IKE_AUTH: >>> >>> error in Child SA <-- IDr, [CERT+], >>> creation AUTH, >>> N(error), >>> [V+] >>> >>> So sending an authenticated and encrypted INVALID_SYNTAX notification >>> over the IKE_SA that has just been authenticated seems to be correct. >>> >>> Regards, >>> Matt >>> >>> >>>> >>>> 2009/4/22 raj singh >>>> >>>>> Hi Matt, >>>>> >>>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH >>>>> and IPsec SA getting established via CREATE_CHILD_SA. >>>>> The question is what behavior RFC mandate ? What you think ? >>>>> >>>>> Thanks for your reply. >>>>> >>>>> Regards, >>>>> Raj >>>>> >>>>> >>>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo < >>>>> mcins1@gmail.com> wrote: >>>>> >>>>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit >>>>>> them from an authentication exchange message, as there would be no way for >>>>>> the SA to know what traffic should be forwarded through the SA. >>>>>> >>>>>> It seems that the correct error message would be INVALID_SYNTAX. This >>>>>> would require the message ID and the checksum to be valid. Note that this >>>>>> has (may only) be sent in an encrypted response. >>>>>> >>>>>> Please correct me if I am wrong. >>>>>> >>>>>> Regards, >>>>>> Matt >>>>>> >>>>>> >>>>>>> 2009/4/22 raj singh >>>>>>> >>>>>>>> Hi Group, >>>>>>>> >>>>>>>> What is the expected behavior if as a responder we do not receive >>>>>>>> TSi and TSr in IKE_AUTH exchange ? >>>>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out >>>>>>>> TSi and TSr ? >>>>>>>> Or we should reject the packet ? >>>>>>>> If we reject the packet during packet validation with doing ID and >>>>>>>> AUTH payload processing, what ERROR should be send ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Raj >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> IPsec mailing list >>>>>>>> IPsec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> Email secured by Check Point >> >> > --0016e647ee5e34c72f04682140ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Raj,

You still need the IDr and AUTH payloads in the reply. Th= is is needed as INVALID_SYNTAX is authenticated and encrypted.

Regar= ds,
Matt

2009/4/22 raj singh <rsjenwar@gmail.com&g= t;
Hi Matt/Youv,
=
Thanks for your reply.
I will conclude as IKE_AUTH exchange MUST hav= e TSi and TSr payload. We MUST NOT process IKE_AUTH packet without TSi and = TSr and we should reply with INVALID_SYNTAX notification without IDr, AUTH,= TSi and TSr payloads.

Regards,
Raj


On Wed, Apr 22, 2009 at 1:11 PM= , Yoav Nir <ynir@checkpoint.com> wrote:
Hi Raj
=A0
Matt is correct. There is no way in IKEv2 to do a phase1-only= =20 exchange, and then wait for=A0traffic to=A0establish the child=20 SAs.=A0=A0
=A0
While we=A0do establish an IKE SA if the piggy-backed child=20 SA=A0failed for whatever reason (bad selectors, no proposal chosen), we don= 't=20 allow for an IKE_AUTH exchange that is missing the child=20 payloads.
=A0
An IKE_AUTH request without the TSi and TSr payloads is=20 considered=A0malformed, and=A0so=A0MUST NOT be processed. Instead, you=20 should reply with INVALID_SYNTAX
=A0
As to question 2, the text refers to a child SA creation that= =20 failed, not to one that was never attempted.
=A0
Of course it is possible to generate that effect - propose=20 non-existant cryptographic algorithms, or IPv7 addresses in the selectors, = but=20 that IMO is a misuse of the protocol.
=A0
Yoav=A0
=A0
Raj Singh=20 wrote:
Hi Matt,

Let me re-phrase my questions:
1. If there = is no=20 TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process= =20 IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA= =20 creation. It will come into picture if we process the=20 packet.
=A0=A0=A0 If we go ahead and process the packet, according=20 to appendix C, we SHOULD/MUST establish the IKE SA ?
=A0=A0=A0=20 Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and= TSr,=20 we can establish the IKEv2 SA.

I request more experts to=20 comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini= Sarreo=20 <mcins1@gmail.com> wrote:
Hello Raj,

According to Appendix C, for=20 IKE_AUTH:

=A0=A0 error in Child SA=A0 <--=A0 IDr,=20 [CERT+],
=A0=A0=20 creation=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 AUTH,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 =A0 =A0 N(error),
=A0 =A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=20 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX=20 notification over the IKE_SA that has just been authenticated seems to = be=20 correct.

Regards,
Matt
=A0

2009/4/22 raj singh <= rsjenwar@gmail.com<= /a>>
Hi Matt,
There is possibility of just IKEv2 SA=20 gets established during IKE_AUTH and IPsec SA getting established v= ia=20 CREATE_CHILD_SA.
The question is what behavior RFC mandate ? Wha= t you=20 think ?

Thanks for your reply.

Regards,
Raj


On Wed, Apr 22, 2009 at 11:40 AM, Matthe= w Cini=20 Sarreo <mcins1@gmail.com>=20 wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not possible= to=20 omit them from an authentication exchange message, as there would= be=20 no way for the SA to know what traffic should be forwarded throug= h the=20 SA.

It seems that the correct error message would be=20 INVALID_SYNTAX. This would require the message ID and the checksu= m to=20 be valid. Note that this has (may only) be sent in an encrypted= =20 response.

Please correct me if I am=20 wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmai= l.com>
Hi Group,

What is the expected behavior if as a= =20 responder we do not receive TSi and TSr in IKE_AUTH exchange= =20 ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall= we=20 send out TSi and TSr ?
Or we should reject the packet ? If=20 we reject the packet during packet validation with doing ID a= nd=20 AUTH payload processing, what ERROR should be send=20 ?

Thanks,
Raj


_______________________________________________
IPsec= =20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec=



=






Email secured by Check Point



--0016e647ee5e34c72f04682140ef-- From rsjenwar@gmail.com Wed Apr 22 02:24:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EAA3A6BCF for ; Wed, 22 Apr 2009 02:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.579, 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 lFKjy1MeRsTG for ; Wed, 22 Apr 2009 02:24:23 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id DE4B33A6B7A for ; Wed, 22 Apr 2009 02:24:22 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so4419447ywh.49 for ; Wed, 22 Apr 2009 02:25:39 -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; bh=jcyNv5fsSiA/w1HvoMG+yhy9hCPbBpD4Jadylk9JPlw=; b=nxiBcbTupf00jCBwIUzM/WPSIU8oWcIikGsQP9J3k7ni3uG/MGOBB+mIO22kfddim4 gPA7JutR/YaWWZMWYMGY1uxQDHjhoVcno5JFduVGH5SVH0jkeciVS2h1JMNw3QlZvApf lyCJk+5XEPUXHmLlbCvtYSMt9Yx8BCPX2rpJU= 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; b=uesh/UxRJexQAl20PVUhyDCMuOQBo4aeYMQ5Kw7dFszAY2iyE9PkaMt12p6dZEmg8M bPN8BMrMuKWzQDuSmH5RvFRLEsSAz5kKVhZUFLJv01PmVCnZ8mz0ySLJlkfPuvT66HJQ 0LG+WnC7rtxzAcKIJBkg/3Z+jKa9DUVU9Yj8Y= MIME-Version: 1.0 Received: by 10.100.189.8 with SMTP id m8mr11159378anf.87.1240392339608; Wed, 22 Apr 2009 02:25:39 -0700 (PDT) In-Reply-To: <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> Date: Wed, 22 Apr 2009 14:55:39 +0530 Message-ID: <7ccecf670904220225l43bf702ftfee5ce5aef348ac4@mail.gmail.com> From: raj singh To: Matthew Cini Sarreo Content-Type: multipart/alternative; boundary=0016e644c76cc8d730046821587f Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 09:24:24 -0000 --0016e644c76cc8d730046821587f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Matt, Buy as per Youv, we should not process the request. Is that means, that we will not process the request but send IDr and AUTH payloads ? Thanks, Raj On Wed, Apr 22, 2009 at 2:48 PM, Matthew Cini Sarreo wrote: > Hello Raj, > > You still need the IDr and AUTH payloads in the reply. This is needed as > INVALID_SYNTAX is authenticated and encrypted. > > > Regards, > Matt > > 2009/4/22 raj singh > >> Hi Matt/Youv, >> >> Thanks for your reply. >> I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We >> MUST NOT process IKE_AUTH packet without TSi and TSr and we should reply >> with INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads. >> >> Regards, >> Raj >> >> >> On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir wrote: >> >>> Hi Raj >>> >>> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, >>> and then wait for traffic to establish the child SAs. >>> >>> While we do establish an IKE SA if the piggy-backed child SA failed for >>> whatever reason (bad selectors, no proposal chosen), we don't allow for an >>> IKE_AUTH exchange that is missing the child payloads. >>> >>> An IKE_AUTH request without the TSi and TSr payloads is >>> considered malformed, and so MUST NOT be processed. Instead, you should >>> reply with INVALID_SYNTAX >>> >>> As to question 2, the text refers to a child SA creation that failed, not >>> to one that was never attempted. >>> >>> Of course it is possible to generate that effect - propose non-existant >>> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO >>> is a misuse of the protocol. >>> >>> Yoav >>> >>> Raj Singh wrote: >>> >>> Hi Matt, >>> >>> Let me re-phrase my questions: >>> 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go >>> ahead and process IKE_AUTH payloads or not ? >>> 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into >>> picture if we process the packet. >>> If we go ahead and process the packet, according to appendix C, we >>> SHOULD/MUST establish the IKE SA ? >>> Looks like, if we go ahead to process the IKE_AUTH packet with no TSi >>> and TSr, we can establish the IKEv2 SA. >>> >>> I request more experts to comment. >>> >>> Thanks for your reply. >>> >>> Regards, >>> Raj >>> >>> On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote: >>> >>>> Hello Raj, >>>> >>>> According to Appendix C, for IKE_AUTH: >>>> >>>> error in Child SA <-- IDr, [CERT+], >>>> creation AUTH, >>>> N(error), >>>> [V+] >>>> >>>> So sending an authenticated and encrypted INVALID_SYNTAX notification >>>> over the IKE_SA that has just been authenticated seems to be correct. >>>> >>>> Regards, >>>> Matt >>>> >>>> >>>>> >>>>> 2009/4/22 raj singh >>>>> >>>>>> Hi Matt, >>>>>> >>>>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH >>>>>> and IPsec SA getting established via CREATE_CHILD_SA. >>>>>> The question is what behavior RFC mandate ? What you think ? >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> Regards, >>>>>> Raj >>>>>> >>>>>> >>>>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo < >>>>>> mcins1@gmail.com> wrote: >>>>>> >>>>>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to >>>>>>> omit them from an authentication exchange message, as there would be no way >>>>>>> for the SA to know what traffic should be forwarded through the SA. >>>>>>> >>>>>>> It seems that the correct error message would be INVALID_SYNTAX. This >>>>>>> would require the message ID and the checksum to be valid. Note that this >>>>>>> has (may only) be sent in an encrypted response. >>>>>>> >>>>>>> Please correct me if I am wrong. >>>>>>> >>>>>>> Regards, >>>>>>> Matt >>>>>>> >>>>>>> >>>>>>>> 2009/4/22 raj singh >>>>>>>> >>>>>>>>> Hi Group, >>>>>>>>> >>>>>>>>> What is the expected behavior if as a responder we do not receive >>>>>>>>> TSi and TSr in IKE_AUTH exchange ? >>>>>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send >>>>>>>>> out TSi and TSr ? >>>>>>>>> Or we should reject the packet ? >>>>>>>>> If we reject the packet during packet validation with doing ID and >>>>>>>>> AUTH payload processing, what ERROR should be send ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Raj >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> IPsec mailing list >>>>>>>>> IPsec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> Email secured by Check Point >>> >>> >> > --0016e644c76cc8d730046821587f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt,

Buy as per Youv, we should not process the request.
Is = that means, that we will not process the request but send IDr and AUTH payl= oads ?

Thanks,
Raj

On Wed, Apr = 22, 2009 at 2:48 PM, Matthew Cini Sarreo <mcins1@gmail.com> wrote:
Hello Raj,
You still need the IDr and AUTH payloads in the reply. This is needed as I= NVALID_SYNTAX is authenticated and encrypted.


Regards,
Matt

2009/4/22 raj singh <rsjenwar@gmail.com>
Hi Matt/Youv,
=
Thanks for your reply.
I will conclude as IKE_AUTH exchange MUST hav= e TSi and TSr payload. We MUST NOT process IKE_AUTH packet without TSi and = TSr and we should reply with INVALID_SYNTAX notification without IDr, AUTH,= TSi and TSr payloads.

Regards,
Raj

=
On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Raj
=C2=A0
Matt is correct. There is no way in IKEv2 to do a phase1-only= =20 exchange, and then wait for=C2=A0traffic to=C2=A0establish the child=20 SAs.=C2=A0=C2=A0
=C2=A0
While we=C2=A0do establish an IKE SA if the piggy-backed child= =20 SA=C2=A0failed for whatever reason (bad selectors, no proposal chosen), we = don't=20 allow for an IKE_AUTH exchange that is missing the child=20 payloads.
=C2=A0
An IKE_AUTH request without the TSi and TSr payloads is=20 considered=C2=A0malformed, and=C2=A0so=C2=A0MUST NOT be processed. Instead,= you=20 should reply with INVALID_SYNTAX
=C2=A0
As to question 2, the text refers to a child SA creation that= =20 failed, not to one that was never attempted.
=C2=A0
Of course it is possible to generate that effect - propose=20 non-existant cryptographic algorithms, or IPv7 addresses in the selectors, = but=20 that IMO is a misuse of the protocol.
=C2=A0
Yoav=C2=A0
=C2=A0
Raj Singh=20 wrote:
Hi Matt,

Let me re-phrase my questions:
1. If there = is no=20 TSi and TSr payload in IKE_AUTH exchange, whether we go ahead and process= =20 IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA= =20 creation. It will come into picture if we process the=20 packet.
=C2=A0=C2=A0=C2=A0 If we go ahead and process the packet, acco= rding=20 to appendix C, we SHOULD/MUST establish the IKE SA ?
=C2=A0=C2=A0=C2= =A0=20 Looks like, if we go ahead to process the IKE_AUTH packet with no TSi and= TSr,=20 we can establish the IKEv2 SA.

I request more experts to=20 comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini= Sarreo=20 <mcins1@gmail.com> wrote:
Hello Raj,

According to Appendix C, for=20 IKE_AUTH:

=C2=A0=C2=A0 error in Child SA=C2=A0 <--=C2=A0 IDr,= =20 [CERT+],
=C2=A0=C2=A0=20 creation=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=20 AUTH,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=20 =C2=A0 =C2=A0 N(error),
=C2=A0 =C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 [V+]

So sending an authenticated and encrypted INVALID_SYNTAX=20 notification over the IKE_SA that has just been authenticated seems to = be=20 correct.

Regards,
Matt
=C2=A0

2009/4/22 raj singh <= rsjenwar@gmail.com<= /a>>
Hi Matt,
There is possibility of just IKEv2 SA=20 gets established during IKE_AUTH and IPsec SA getting established v= ia=20 CREATE_CHILD_SA.
The question is what behavior RFC mandate ? Wha= t you=20 think ?

Thanks for your reply.

Regards,
Raj


On Wed, Apr 22, 2009 at 11:40 AM, Matthe= w Cini=20 Sarreo <mcins1@gmail.com>=20 wrote:
In IKE_AUTH TSi and TSr are mandatory, so it is not possible= to=20 omit them from an authentication exchange message, as there would= be=20 no way for the SA to know what traffic should be forwarded throug= h the=20 SA.

It seems that the correct error message would be=20 INVALID_SYNTAX. This would require the message ID and the checksu= m to=20 be valid. Note that this has (may only) be sent in an encrypted= =20 response.

Please correct me if I am=20 wrong.

Regards,
Matt


2009/4/22 raj singh <rsjenwar@gmai= l.com>
Hi Group,

What is the expected behavior if as a= =20 responder we do not receive TSi and TSr in IKE_AUTH exchange= =20 ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall= we=20 send out TSi and TSr ?
Or we should reject the packet ? If=20 we reject the packet during packet validation with doing ID a= nd=20 AUTH payload processing, what ERROR should be send=20 ?

Thanks,
Raj


_______________________________________________
IPsec= =20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec=



=






Email secured by Check Point




--0016e644c76cc8d730046821587f-- From kivinen@iki.fi Wed Apr 22 02:27:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E963A6CB3 for ; Wed, 22 Apr 2009 02:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 X-40Y9BfMKag for ; Wed, 22 Apr 2009 02:27:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 178F53A680D for ; Wed, 22 Apr 2009 02:27:17 -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 n3M9NRtg023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 12:23:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3M9NQXu007444; Wed, 22 Apr 2009 12:23:26 +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: <18926.57870.113005.436353@fireball.kivinen.iki.fi> Date: Wed, 22 Apr 2009 12:23:26 +0300 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 20 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 09:27:19 -0000 Narayanan, Vidya writes: > This is really just a terminology issue. Most of the use cases in > that document are applicable to resumption. In fact, the current > solution for resumption is based on what was produced as a result of > that problem statement (combined with Yaron's draft at the time), > with the ability to exchange failover gateway candidates removed. > In other words, we are not handling anything specific to failovers, > but, prior to this charter and WG, "failover" included resumption in > the work we did. Main thing between resumption and failover is that resumption assumes you reconnect back to same host, as in failover you can reconnect to another host. I myself consider resumption as subset of the failover cases, i.e. failover cover more things than what resumption itself covers. Note, that charter explictly mentions that the resumption can also be to the cluster of closely cooperating gateways, but cooperating protocols inside that cluster are not part of the our scope. > > while you are doing DHCP + IKE_SESSION_RESUME etc on the > > WLAN, thus only thing that is affected is that traffic moves 100ms > > later from cellular to WLAN. > > And, btw, WLAN is only one type of untrusted network - other > scenarios may be cellular-to-cellular handoffs in roaming scenarios, > cellular to WiMAX handoffs, etc. In some of these cases, there are > even RF limitations if you are using a single radio, multi-mode > chipset. I'd prefer that we keep the discussion on the RF systems > itself out and see what best we can do with our protocols. With WLAN and so on I do not think the problem is the RF part, I think it is the DHCP and so on part. For example in IETF it usually takes me about 10 seconds to just to get DHCP address when I first time connect to the network (for some reason it seems the servers always answer only after 2-3 retries). I have not really seen WLAN networks that offer anywhere near the subsecond connection times you seem to assume here. It might be true in the cellular-to-cellular handoffs, but do you really use IPsec and resumption on such environments. I would expect mobike would be much better used there, as if you need IPsec for one cellular network, you might as well do it always. > Obviously, the firewalls need to be handled properly if the operator > wants this to work - so, that is not the primary issue. If you start to talk about WLANs, then you are not talking about operators, you are talking about random basestations someone has set up somewhere. I can assume network operators to configure their boxes properly, I cannot really assume random home user for setting their WLAN basestation properly. > I don't understand what you mean by "not forward any other traffic" > in your description of the attack. The attacker does not have the > keys to decipher any of the actual packets. The thing that makes replay attacks harder is that attacker does not get the ticket he could replay. If you walk around on the street and see some random WLAN named "open wifi" and your phone decides to see if it works, and gets DHCP address, and after that tries resumption to gateway, you just sent that ticket to attacker. Attacker will then take that packet from the air, or from the basestation, and use it to attack, i.e. after he takes that packet and sends it to gataway (for example with fake source IP, so return packets never reach you), then your ticket is killed, and your accounts billing started going. > The only thing the attacker can do is replay a ticket *after* it has > already been sent by the client - in this case, we already talked > about some limited backend state the gateway can maintain to limit > the impact due to replays. Yes, after client sent the ticket, but that does not mean server ever got that ticket from client. I.e if the "fake" WLAN is set up so it will drop all UDP port 500/4500 packets, you never get any IPsec resumption on that network, but you still assume your ticket is valid as for your point of view it was never used. The attacker can see that ticket, and can then mount the attack. Or it could be that the WLAN is set up to allow any UDP packets out, but only "known" UDP packets in (dns and nothing else). In this case you yourself make the attack, i.e. you kill your ticket by sending it to the server, but server's reply never reaches you, so you still think you have not used the ticket, but server has done that. > The protocol does allow for IP address changes and also allows the > client to request a new IP address from the gateway for its internal > IP address - do you see a reason why this doesn't work? Other than the fact that draft does not mention it, no. As an implementor, I would add checks that IP address must be same, as there is no mention that IP-addresses could change. Also I would not send NAT detection payloads, as they are not mentioned in the draft. If such feature is wanted, it MUST be specified in the document too. Do not assume implementors guess correctly. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 22 03:40:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732D928C4A5 for ; Wed, 22 Apr 2009 03:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 RPNtqrSdSmXV for ; Wed, 22 Apr 2009 03:40:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2D728C48C for ; Wed, 22 Apr 2009 03:40:18 -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 n3MAfWaU014074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 13:41:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3MAfUM3009247; Wed, 22 Apr 2009 13:41:30 +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: <18926.62554.713509.846039@fireball.kivinen.iki.fi> Date: Wed, 22 Apr 2009 13:41:30 +0300 From: Tero Kivinen To: Lakshminath Dondeti In-Reply-To: <49EEBDD3.2070706@qualcomm.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:40:20 -0000 Lakshminath Dondeti writes: > > I still do not think making the 1 RT protocol to 2 RT protocol in that > > case would really cause any noticeable effect to the actual handover. > > How do you know this? Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as DHCP delays on WLAN networks. And there is already way to do that in 1 RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of the network or IP-address in 1 RT. Resumption should not really be used for that. Resumption means that something caused the IKEv2 SA in the client to removed, without telling that to the server, and thats why client decided to use resumption instead of just continuing using the IKEv2 SA it has up and running. If we take the network outage example from the charter, the duration of network outage is usually MUCH, MUCH longer than the 2 RTs required to reconnect to the server. > I ask because, I would like to use those arguments to tell people > who are experts in handovers that multiple RTs don't matter. Tell them to use correct protocol on correct places. If they want subsecond recovery from the handover from one network to another, they should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even with MOBIKE it usually takes several seconds for the nodes to actually react that they have lost connectivity, and needs to start corrective actions, but if we assume subsecond recovery is required, then we can also assume the network can immediately tell when recovery actions are required). > Even if this happens, the payoff for the attacker is very little since > the legitimate parties can always establish another connection. No, he does not, as if he was trying to do handover from cellular to WLAN, he would simply continue using cellular in that point, but the accounting for example would be enabled for both (i.e. for servers point of view he is using WLAN and cellular simulatenously, from clients point of view he using only cellular). Again then when he finally gets WLAN which works, he suddenly have 3 RT protocol to use (trying resumption, failing that, and falling back to full IKE) with user authentication, and possibly even user interaction. > The quality of experience would be bad because another session needs > to be established when under attack, but at the cost the attacker > has to pay, one might even say that this is not even a serious > threat. Making the user to do user interaction by simply sniffing one packet from the air, and forwarding it to the right server is very cheap way to annoy people... For users point of view it does not even look he is under attack, he just sees that this crappy network again requires him to reauthenticate at random times. Note, that he does not blame the attacker's network, as he didn't detect anything there. The attack can have happened hours before, and then when he finally comes to the home WLAN network, or some other network which actually works, he sees that he needs to reauthenticate. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 22 04:12:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D904B28C416 for ; Wed, 22 Apr 2009 04:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Z-6UtCpKeUyy for ; Wed, 22 Apr 2009 04:12:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7C90A28C436 for ; Wed, 22 Apr 2009 04:12:25 -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 n3MBDW2v019381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 14:13:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3MBDUxo013394; Wed, 22 Apr 2009 14:13:30 +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: <18926.64473.850663.906637@fireball.kivinen.iki.fi> Date: Wed, 22 Apr 2009 14:13:29 +0300 From: Tero Kivinen To: Matthew Cini Sarreo In-Reply-To: <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310q1f0b1a2em7aed8b5114791f45@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Yoav Nir , raj singh Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 11:12:26 -0000 Matthew Cini Sarreo writes: > You still need the IDr and AUTH payloads in the reply. This is needed as > INVALID_SYNTAX is authenticated and encrypted. INVALID_SYNTAX is fatal error meaning that other end didn't follow the protocol specification, and the IKE SA is going to be removed anyways, and there is not really point of putting AUTH payload there (it can be there, but there is no need). If the other end is not following protocol specification (i.e. is non-complient), there is not really point of trying to be nice. This is something that cannot be seen by normal customers ever, it should only be seen by the implementors when they are testing against broken implementations. So better just send error message back as it is easiest for your implementation (i.e. if it is easy to include AUTH etc to the error message, then do so, if not, then leave them out). -- kivinen@iki.fi From rsjenwar@gmail.com Wed Apr 22 06:26:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455223A7141 for ; Wed, 22 Apr 2009 06:26:36 -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.057, 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 nu-eFkaSbXDO for ; Wed, 22 Apr 2009 06:26:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 1D4243A6CA9 for ; Wed, 22 Apr 2009 06:26:31 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1503814rvb.49 for ; Wed, 22 Apr 2009 06:27:48 -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; bh=YHs6hlGHiqcJLxG+3jQdHuO2F6cn/55/OWAZ15/bf+I=; b=veiT0+9rFeV+GL3i6Z2HfXli+bgxU3Uf+fJHwk/emIovN0GdIugYZBpih98H8vAei2 6B/fJTmkWEyYdQHQCMzLZMWTo9c+srI7v77FWHoDakF8B+l3iQg32EmrIvkSHMMxQKES ZcNU4DA3jy2XOYycfO8fhh5RVIJNr/+PdQ0Bc= 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; b=vKVpl7ocpKGHW3x8BoSBQjhevb6Yl7yOG3GAowVqp8zfYN2z0yIPT91RThAMR7yVkr qNLTIsupE1sydffbWeVZFDt5nEf3EwSX3XfvGW59wfi2ZFF2aHNcmGDRmenX6BhbxcBK 7yIx6WT2Ovih0BPqbHmb7XEnbiX5l4IzSDoeU= MIME-Version: 1.0 Received: by 10.115.91.11 with SMTP id t11mr4596909wal.117.1240406868212; Wed, 22 Apr 2009 06:27:48 -0700 (PDT) In-Reply-To: <18926.64473.850663.906637@fireball.kivinen.iki.fi> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212310y4572a41dy32c4da6b63580f52@mail.gmail.com> <7ccecf670904212328u67fd961cj33dd1d0b4bb0be6a@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <7ccecf670904220207u7c046313had9b4cd876860f41@mail.gmail.com> <99043b4a0904220218j1c662430kae0ead1cd393a847@mail.gmail.com> <18926.64473.850663.906637@fireball.kivinen.iki.fi> Date: Wed, 22 Apr 2009 18:57:48 +0530 Message-ID: <7ccecf670904220627m39d20b46nc89d48864b2fb13e@mail.gmail.com> From: raj singh To: Tero Kivinen Content-Type: multipart/alternative; boundary=00163646d50cc1be24046824ba1e Cc: "ipsec@ietf.org" , Matthew Cini Sarreo , Yoav Nir Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:26:36 -0000 --00163646d50cc1be24046824ba1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Tero, It make sense. The same point i want to make, if we as a responder are not going to process the packet, there is NO need to add IDr and AUTH with INVALID_SYNTAX during IKE_AUTH. Regards, Raj On Wed, Apr 22, 2009 at 4:43 PM, Tero Kivinen wrote: > Matthew Cini Sarreo writes: > > You still need the IDr and AUTH payloads in the reply. This is needed as > > INVALID_SYNTAX is authenticated and encrypted. > > INVALID_SYNTAX is fatal error meaning that other end didn't follow the > protocol specification, and the IKE SA is going to be removed anyways, > and there is not really point of putting AUTH payload there (it can be > there, but there is no need). > > If the other end is not following protocol specification (i.e. is > non-complient), there is not really point of trying to be nice. This > is something that cannot be seen by normal customers ever, it should > only be seen by the implementors when they are testing against broken > implementations. > > So better just send error message back as it is easiest for your > implementation (i.e. if it is easy to include AUTH etc to the error > message, then do so, if not, then leave them out). > -- > kivinen@iki.fi > --00163646d50cc1be24046824ba1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tero,

It make sense.
The same point i want to make, if we as a= responder are not going to process the packet,
there is NO need to add= IDr and AUTH with INVALID_SYNTAX during IKE_AUTH.

Regards,
Raj
On Wed, Apr 22, 2009 at 4:43 PM, Tero Kivine= n <kivinen@iki.fi> wrote:
Matthew Cini Sarreo writes:
> You still need the IDr and AUTH payloads in the reply. This is needed = as
> INVALID_SYNTAX is authenticated and encrypted.

INVALID_SYNTAX is fatal error meaning that other end didn't follo= w the
protocol specification, and the IKE SA is going to be removed anyways,
and there is not really point of putting AUTH payload there (it can be
there, but there is no need).

If the other end is not following protocol specification (i.e. is
non-complient), there is not really point of trying to be nice. This
is something that cannot be seen by normal customers ever, it should
only be seen by the implementors when they are testing against broken
implementations.

So better just send error message back as it is easiest for your
implementation (i.e. if it is easy to include AUTH etc to the error
message, then do so, if not, then leave them out).
--
kivinen@iki.fi

--00163646d50cc1be24046824ba1e-- From mcins1@gmail.com Wed Apr 22 07:37:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0884D3A6D4B for ; Wed, 22 Apr 2009 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.347, 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 QzpItNct4Tc8 for ; Wed, 22 Apr 2009 07:37:06 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 1963F3A6CB7 for ; Wed, 22 Apr 2009 07:37:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so332958wff.31 for ; Wed, 22 Apr 2009 07:38:23 -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; bh=5kpPPo1OVs75RoLoANaDH2C5I56HLj4FsJxynxV570k=; b=nN+5O1M8j+az4jo0VFdWMU5IScuLcKA6U2hWi7ZBOt67JGGD++3Sp0yTsvv4I3qHmU Sj6ahGRrDmPH/KWTmQ6BdxpoxeugWU0Pnvi1DvKyJLeyx73loXpISz5LFBMXDfy0vmgC L0h3EnuPTvSZbrFgpUwR40tVW/JSTD37QP3Xk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IKdoFEUpSp1AuWfyW5x++9XcL/pk9D2wBFokldywW27XMtIyseB0XF97nSdfHA0ZKz YSP37MYTFQkLok8xUl5i+ZXKvnknrwweLNlG081tkv7u0dCKQ8hGADe4NVCETeGp4o8q LQOOVidD8N5zybGvDOUww6go9oSUtP2a5dWKk= MIME-Version: 1.0 Received: by 10.220.87.1 with SMTP id u1mr11145848vcl.2.1240411102904; Wed, 22 Apr 2009 07:38:22 -0700 (PDT) Date: Wed, 22 Apr 2009 16:38:22 +0200 Message-ID: <99043b4a0904220738p1b2506am1d4bd268c35385a1@mail.gmail.com> From: Matthew Cini Sarreo To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016e6469c042a1f62046825b76d Subject: [IPsec] [IKEv2] Error in Child SA creation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:37:07 -0000 --0016e6469c042a1f62046825b76d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all, As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester that there was an error in creating a Child SA using the IKE_AUTH exchange is: error in Child SA <-- IDr, [CERT+], creation AUTH, N(error), [V+] A point came up about this in a previous thread today (IKE_AUTH without TSi, TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed that a general agreement was to send an INVALID_SYNTAX message without the IDr and AUTH payloads. As it was put: >INVALID_SYNTAX is fatal error meaning that other end didn't follow the >protocol specification, and the IKE SA is going to be removed anyways, >and there is not really point of putting AUTH payload there (it can be > there, but there is no need). > If the other end is not following protocol specification (i.e. is > non-complient), there is not really point of trying to be nice. This > is something that cannot be seen by normal customers ever, it should > only be seen by the implementors when they are testing against broken > implementations. >So better just send error message back as it is easiest for your > implementation (i.e. if it is easy to include AUTH etc to the error > message, then do so, if not, then leave them out). The above seems reasonable to me. What would be the reasoning for adding IDr, [CERT+], AUTH in this scenario? Would it be possible/acceptable to some better text covering INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would be sent, no other payloads are needed, and what would happen to the SA. Would the SA be interrupted (removed from memory instantly without any confirmation by the party sending the notification), an Informational exchange to delete the SA be initiated or would the party sending INVALID_SYNTAX allow the other endpoint to take some action when receiving this error (maybe the initiator would give up and start an Informational Exchange to delete the SA)? Regards, Matt --0016e6469c042a1f62046825b76d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

As IKEv2bis-02 defines in Appendix C, the proper way to n= otify a requester that there was an error in creating a Child SA using the = IKE_AUTH exchange is:

error in Child SA=A0 <--=A0 IDr, [CERT+], creation=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AUTH,
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 N(error)= ,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 [V+]

A point came up about this in a previous thread today= (IKE_AUTH without TSi, TSr), where an initator would send IKE_AUTH without= TSi, TSr. It seemed that a general agreement was to send an INVALID_SYNTAX= message without the IDr and AUTH payloads. As it was put:

>INVALID_SYNTAX is fatal error meaning that other end didn't fol= low the
>protocol specification, and the IKE SA is going to be remove= d anyways,
>and there is not really point of putting AUTH payload there (it can be<= br>> there, but there is no need).

> If the other end is not following protocol specification (i.e. is
> non-complient), there is not really point of trying to be nice. This
>= ; is something that cannot be seen by normal customers ever, it should
>= ; only be seen by the implementors when they are testing against broken
&g= t; implementations.

>So better just send error message back as it is easiest for your
>= ; implementation (i.e. if it is easy to include AUTH etc to the error
> message, then do so, if not, then leave them out).

The above seems r= easonable to me.

What would be the reasoning for adding IDr, [CERT+= ], AUTH in this scenario? Would it be possible/acceptable to some better te= xt covering INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX= would be sent, no other payloads are needed, and what would happen to the = SA. Would the SA be interrupted (removed from memory instantly without any = confirmation by the party sending the notification), an Informational excha= nge to delete the SA be initiated or would the party sending INVALID_SYNTAX= allow the other endpoint to take some action when receiving this error (ma= ybe the initiator would give up and start an Informational Exchange to dele= te the SA)?

Regards,
Matt
--0016e6469c042a1f62046825b76d-- From jsun2501@gmail.com Wed Apr 22 13:33:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF343A679C for ; Wed, 22 Apr 2009 13:33: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 rwbvINJSA63h for ; Wed, 22 Apr 2009 13:33:46 -0700 (PDT) Received: from ins2.sd.spawar.navy.mil (ins2.sd.spawar.navy.mil [IPv6:2001:480:10:4::3]) by core3.amsl.com (Postfix) with ESMTP id ACEE03A6864 for ; Wed, 22 Apr 2009 13:33:45 -0700 (PDT) Received: from pescado.nosc.mil (pescado.nosc.mil [128.49.4.90]) by ins2.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id n3MKYwYh019894 for ; Wed, 22 Apr 2009 13:35:00 -0700 Received: from [128.49.163.29] (sunjeff.sd.spawar.navy.mil [128.49.163.29]) by pescado.nosc.mil (Netscape Messaging Server 4.15) with ESMTP id KIIRU900.VGI; Wed, 22 Apr 2009 13:34:57 -0700 Message-ID: <49EF7F71.8050703@gmail.com> Date: Wed, 22 Apr 2009 13:34:57 -0700 From: "J. Sun" User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Matthew Cini Sarreo References: <99043b4a0904220738p1b2506am1d4bd268c35385a1@mail.gmail.com> In-Reply-To: <99043b4a0904220738p1b2506am1d4bd268c35385a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IKEv2] Error in Child SA creation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:33:47 -0000 Matt, In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr, [CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED, TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify ERROR TYPES that would generally still include the IDr, [CERT+] & AUTH payload in the response. In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really up to the implementation to decide what to do next in respect to receiving a malformed IKE_AUTH Request. One option is suggested by Tero - sending an IKE_AUTH Response with an INVALID_SYNTAX and no other payloads. Another option is to simply drop the malformed IKE_AUTH Request and not even send a reply. The point is, there's not much you can really do when a device sends you a malformed request/response message - it's not like it's gonna figure out what's wrong and fix it. Whichever option that you go with, you'll have to eventually locally delete the unauthenticated IKE_SA - I would not continue operating as if the IKE_SA is authenticated by initializing a INFORMATIONAL Request with Delete Payloads. RFC 4306 does not define what to do in such cases, and essentially leaves it up to implementations to decide on how to handle it - in other words, there isn't a specified way to handle every oddball case out there. - Jeff Sun Matthew Cini Sarreo wrote: > Hello all, > > As IKEv2bis-02 defines in Appendix C, the proper way to notify a > requester that there was an error in creating a Child SA using the > IKE_AUTH exchange is: > > error in Child SA <-- IDr, [CERT+], > creation AUTH, > N(error), > [V+] > > A point came up about this in a previous thread today (IKE_AUTH > without TSi, TSr), where an initator would send IKE_AUTH without TSi, > TSr. It seemed that a general agreement was to send an INVALID_SYNTAX > message without the IDr and AUTH payloads. As it was put: > > >INVALID_SYNTAX is fatal error meaning that other end didn't follow the > >protocol specification, and the IKE SA is going to be removed anyways, > >and there is not really point of putting AUTH payload there (it can be > > there, but there is no need). > > > If the other end is not following protocol specification (i.e. is > > non-complient), there is not really point of trying to be nice. This > > is something that cannot be seen by normal customers ever, it should > > only be seen by the implementors when they are testing against broken > > implementations. > > >So better just send error message back as it is easiest for your > > implementation (i.e. if it is easy to include AUTH etc to the error > > message, then do so, if not, then leave them out). > > The above seems reasonable to me. > > What would be the reasoning for adding IDr, [CERT+], AUTH in this > scenario? Would it be possible/acceptable to some better text covering > INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would > be sent, no other payloads are needed, and what would happen to the > SA. Would the SA be interrupted (removed from memory instantly without > any confirmation by the party sending the notification), an > Informational exchange to delete the SA be initiated or would the > party sending INVALID_SYNTAX allow the other endpoint to take some > action when receiving this error (maybe the initiator would give up > and start an Informational Exchange to delete the SA)? > > Regards, > Matt > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From rsjenwar@gmail.com Wed Apr 22 19:50:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2E73A6D63 for ; Wed, 22 Apr 2009 19:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.463, 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 4+yQMbcNhbTz for ; Wed, 22 Apr 2009 19:50:14 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id E67443A6CF0 for ; Wed, 22 Apr 2009 19:50:13 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so413360yxb.49 for ; Wed, 22 Apr 2009 19:51: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; bh=yBSzrg6EKVtdON2Zu1sBUZKKrDpLkpv+CdDTqRnYEVo=; b=a4ciHPHMoLSU3i5tmiiGgKfhmm3AkGLh+I4CDgJagC/TRrM4xIZAtiXRLq9uE4jRhH AXJDwempXms3DMgyh5qlXBkU2U5iq6f6GGfgmVYxmWPl/Y6o8qFG1L7j5eWBGgrDM4Ny vjROEyQzsMqUNNvyM8s/Ua4hJGsvcm2JLfmmI= 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; b=FLHZ130nlk3uCyQtFXQUctgKlraRoLLc3EXqMPktN3wCN3eDiJ/21obSHNJrUhSi9A KJDDtc6frrxhoYLsTWU2PGx9h6yl3M9fKrvAriebuOD5/4tm9ersg3TNAFLvs0xh0AgN bx6bHYd5nakSWneNc/sTzmx2WvKeKZgWRAmwk= MIME-Version: 1.0 Received: by 10.100.111.11 with SMTP id j11mr741887anc.19.1240455091065; Wed, 22 Apr 2009 19:51:31 -0700 (PDT) In-Reply-To: <49EF7F71.8050703@gmail.com> References: <99043b4a0904220738p1b2506am1d4bd268c35385a1@mail.gmail.com> <49EF7F71.8050703@gmail.com> Date: Thu, 23 Apr 2009 08:21:31 +0530 Message-ID: <7ccecf670904221951m523ec2dco5ed32e5adc1fe302@mail.gmail.com> From: raj singh To: "J. Sun" Content-Type: multipart/alternative; boundary=0016e644cf5a1014bd04682ff553 Cc: "ipsec@ietf.org" , Matthew Cini Sarreo Subject: Re: [IPsec] [IKEv2] Error in Child SA creation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 02:50:15 -0000 --0016e644cf5a1014bd04682ff553 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Matt, I agree with Jeff. Sending INVALID_SYNTAX notify with no payload and immediately delete IKEv2 SA will be good idea in case of malformed IKE_AUTH request. As SA is still unauthenticated, sending DELETE notify will cause another problems. Thanks, Raj On Thu, Apr 23, 2009 at 2:04 AM, J. Sun wrote: > Matt, > In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr, > [CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED, > TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify ERROR TYPES that would > generally still include the IDr, [CERT+] & AUTH payload in the response. > In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really up > to the implementation to decide what to do next in respect to receiving a > malformed IKE_AUTH Request. One option is suggested by Tero - sending an > IKE_AUTH Response with an INVALID_SYNTAX and no other payloads. Another > option is to simply drop the malformed IKE_AUTH Request and not even send a > reply. The point is, there's not much you can really do when a device sends > you a malformed request/response message - it's not like it's gonna figure > out what's wrong and fix it. Whichever option that you go with, you'll have > to eventually locally delete the unauthenticated IKE_SA - I would not > continue operating as if the IKE_SA is authenticated by initializing a > INFORMATIONAL Request with Delete Payloads. RFC 4306 does not define what > to do in such cases, and essentially leaves it up to implementations to > decide on how to handle it - in other words, there isn't a specified way to > handle every oddball case out there. > > - Jeff Sun > > Matthew Cini Sarreo wrote: > >> Hello all, >> >> As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester >> that there was an error in creating a Child SA using the IKE_AUTH exchange >> is: >> >> error in Child SA <-- IDr, [CERT+], >> creation AUTH, >> N(error), >> [V+] >> >> A point came up about this in a previous thread today (IKE_AUTH without >> TSi, TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed >> that a general agreement was to send an INVALID_SYNTAX message without the >> IDr and AUTH payloads. As it was put: >> >> >INVALID_SYNTAX is fatal error meaning that other end didn't follow the >> >protocol specification, and the IKE SA is going to be removed anyways, >> >and there is not really point of putting AUTH payload there (it can be >> > there, but there is no need). >> >> > If the other end is not following protocol specification (i.e. is >> > non-complient), there is not really point of trying to be nice. This >> > is something that cannot be seen by normal customers ever, it should >> > only be seen by the implementors when they are testing against broken >> > implementations. >> >> >So better just send error message back as it is easiest for your >> > implementation (i.e. if it is easy to include AUTH etc to the error >> > message, then do so, if not, then leave them out). >> >> The above seems reasonable to me. >> >> What would be the reasoning for adding IDr, [CERT+], AUTH in this >> scenario? Would it be possible/acceptable to some better text covering >> INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would be >> sent, no other payloads are needed, and what would happen to the SA. Would >> the SA be interrupted (removed from memory instantly without any >> confirmation by the party sending the notification), an Informational >> exchange to delete the SA be initiated or would the party sending >> INVALID_SYNTAX allow the other endpoint to take some action when receiving >> this error (maybe the initiator would give up and start an Informational >> Exchange to delete the SA)? >> >> Regards, >> Matt >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e644cf5a1014bd04682ff553 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt,

I agree with Jeff.
Sending INVALID_SYNTAX notify with no= payload and immediately delete IKEv2 SA=C2=A0 will be good idea in case of= malformed IKE_AUTH=C2=A0 request.
As SA is still unauthenticated, sendi= ng DELETE notify will cause another problems.

Thanks,
Raj

On Thu, Apr 23, 2009 a= t 2:04 AM, J. Sun <jsun2501@gmail.com> wrote:
Matt,
=C2=A0In respect to a Notify ERROR TYPES & the IKE_AUTH response with I= Dr, [CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, SINGLE_PAIR_R= EQUIRED, =C2=A0TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify ERROR TYPES= that would generally still include the IDr, [CERT+] & AUTH payload in = the response.
=C2=A0In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it'= s really up to the implementation to decide what to do next in respect to r= eceiving a malformed IKE_AUTH Request. =C2=A0One option is suggested by Ter= o - sending an IKE_AUTH Response with an INVALID_SYNTAX and no other payloa= ds. =C2=A0Another option is to simply drop the malformed IKE_AUTH Request a= nd not even send a reply. =C2=A0The point is, there's not much you can = really do when a device sends you a malformed request/response message - it= 's not like it's gonna figure out what's wrong and fix it. =C2= =A0Whichever option that you go with, you'll have to eventually locally= delete the unauthenticated IKE_SA - I would not continue operating as if t= he IKE_SA is authenticated by initializing a INFORMATIONAL Request with Del= ete Payloads. =C2=A0RFC 4306 does not define what to do in such cases, and = essentially leaves it up to implementations to decide on how to handle it -= in other words, there isn't a specified way to handle every oddball ca= se out there.

- Jeff Sun

Matthew Cini Sarreo wrote:
<= div class=3D"h5"> Hello all,

As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester = that there was an error in creating a Child SA using the IKE_AUTH exchange = is:

error in Child SA =C2=A0<-- =C2=A0IDr, [CERT+],
creation =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AUTH,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 N(error),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [V+]

A point came up about this in a previous thread today (IKE_AUTH without TSi= , TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed t= hat a general agreement was to send an INVALID_SYNTAX message without the I= Dr and AUTH payloads. As it was put:

>INVALID_SYNTAX is fatal error meaning that other end didn't follow = the
>protocol specification, and the IKE SA is going to be removed anyways,<= br> >and there is not really point of putting AUTH payload there (it can be<= br> > there, but there is no need).

> If the other end is not following protocol specification (i.e. is
> non-complient), there is not really point of trying to be nice. This > is something that cannot be seen by normal customers ever, it should > only be seen by the implementors when they are testing against broken<= br> > implementations.

>So better just send error message back as it is easiest for your
> implementation (i.e. if it is easy to include AUTH etc to the error > message, then do so, if not, then leave them out).

The above seems reasonable to me.

What would be the reasoning for adding IDr, [CERT+], AUTH in this scenario?= Would it be possible/acceptable to some better text covering INVALID_SYNTA= X? Maybe it would specify that when INVALID_SYNTAX would be sent, no other = payloads are needed, and what would happen to the SA. Would the SA be inter= rupted (removed from memory instantly without any confirmation by the party= sending the notification), an Informational exchange to delete the SA be i= nitiated or would the party sending INVALID_SYNTAX allow the other endpoint= to take some action when receiving this error (maybe the initiator would g= ive up and start an Informational Exchange to delete the SA)?

Regards,
Matt
------------------------------------------------------------------------
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec
=C2=A0

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016e644cf5a1014bd04682ff553-- From ldondeti@qualcomm.com Wed Apr 22 23:59:02 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1CF3A71B6 for ; Wed, 22 Apr 2009 23:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 CPbJz3wF4F+b for ; Wed, 22 Apr 2009 23:59:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8626B3A6D9E for ; Wed, 22 Apr 2009 23:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240470019; x=1272006019; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49F011FE.4070206@qualcomm.com>|Date:=20Th u,=2023=20Apr=202009=2012:30:14=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Tero=20Kivinen=20|CC:=20IPsecme=20WG=20,=20Paul=20Ho ffman=20|Subject:=20Re:=20[IPsec] =20Issue=20#98:=201=20or=20two=20round=20trips=20for=20re sumption|References:=20=09=09<7F9A6D26EB51614FBF9F81C0DA4CFEC8D 9ACEC4D5B@il-ex01.ad.checkpoint.com>=09=09<1 8925.45980.896489.919446@fireball.kivinen.iki.fi>=09<49EE BDD3.2070706@qualcomm.com>=20<18926.62554.713509.846039@f ireball.kivinen.iki.fi>|In-Reply-To:=20<18926.62554.71350 9.846039@fireball.kivinen.iki.fi>|Content-Type:=20text/pl ain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5593"=3B=20a=3D"17364684"; bh=zmSf2Qz3NIXYpZpagLmJSxwpohiV4GWHlFZsDWrimJk=; b=SxqI0Ha81AOcOutm4gRp3aaAow5H6VQPUbTvh7hqbt1qkfllnIbvfn0K mppKA7L6iomqzm6qZvfTQmK0juu4u6E4ItFDJzEwqb2ipSLq7M27nA45S Ror8azSkXp+Q1pRXG1E6KYG70gBVovt0gS9rT4Ctn98OftRr3Pble/6hF o=; X-IronPort-AV: E=McAfee;i="5300,2777,5593"; a="17364684" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2009 00:00:19 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3N70IPX015064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2009 00:00:19 -0700 Received: from [10.44.81.72] (ldondetixp2.ap.qualcomm.com [10.44.81.72]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3N70ESR005374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Apr 2009 00:00:17 -0700 (PDT) Message-ID: <49F011FE.4070206@qualcomm.com> Date: Thu, 23 Apr 2009 12:30:14 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tero Kivinen References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> In-Reply-To: <18926.62554.713509.846039@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 06:59:02 -0000 On 4/22/2009 4:11 PM, Tero Kivinen wrote: > Lakshminath Dondeti writes: > >>> I still do not think making the 1 RT protocol to 2 RT protocol in that >>> case would really cause any noticeable effect to the actual handover. >>> >> How do you know this? >> > > Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as > DHCP delays on WLAN networks. And there is already way to do that in 1 > RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of > the network or IP-address in 1 RT. > The 10seconds are not a barometer. So, 1 RT will be closer to the 10ms than the 2 RT, which is better, so I am not sure how you figure it is not noticeable. If someone is in a call, the 2 RT adds to the latency. > Resumption should not really be used for that. > > Resumption means that something caused the IKEv2 SA in the client to > removed, without telling that to the server, and thats why client > decided to use resumption instead of just continuing using the IKEv2 > SA it has up and running. > > If we take the network outage example from the charter, the duration > of network outage is usually MUCH, MUCH longer than the 2 RTs required > to reconnect to the server. > > >> I ask because, I would like to use those arguments to tell people >> who are experts in handovers that multiple RTs don't matter. >> > > Tell them to use correct protocol on correct places. If they want > subsecond recovery from the handover from one network to another, they > should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even > with MOBIKE it usually takes several seconds for the nodes to actually > react that they have lost connectivity, and needs to start corrective > actions, but if we assume subsecond recovery is required, then we can > also assume the network can immediately tell when recovery actions are > required). > > When did MOBIKE come into picture? What are you saying Tero, that IPsec session resumption is an alternative to MOBIKE and a slow one at that? >> Even if this happens, the payoff for the attacker is very little since >> the legitimate parties can always establish another connection. >> > > No, he does not, as if he was trying to do handover from cellular to > WLAN, he would simply continue using cellular in that point, but the > accounting for example would be enabled for both (i.e. for servers > point of view he is using WLAN and cellular simulatenously, from > clients point of view he using only cellular). > > Again then when he finally gets WLAN which works, he suddenly have 3 > RT protocol to use (trying resumption, failing that, and falling back > to full IKE) with user authentication, and possibly even user > interaction. > > >> The quality of experience would be bad because another session needs >> to be established when under attack, but at the cost the attacker >> has to pay, one might even say that this is not even a serious >> threat. >> > > Making the user to do user interaction by simply sniffing one packet > from the air, and forwarding it to the right server is very cheap way > to annoy people... > "Annoy" being the keyword. I am now more convinced that we are really making the protocol inefficient because some kid might try to annoy some people some time. To counter such potential annoyances which may not happen at any frequency that matters, we are going to sacrifice the user experience all the time? I fail to understand this line of reasoning. What am I missing? thanks, Lakshminath > For users point of view it does not even look he is under attack, he > just sees that this crappy network again requires him to > reauthenticate at random times. Note, that he does not blame the > attacker's network, as he didn't detect anything there. The attack can > have happened hours before, and then when he finally comes to the home > WLAN network, or some other network which actually works, he sees that > he needs to reauthenticate. > From kivinen@iki.fi Thu Apr 23 03:26:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058A828C0E4 for ; Thu, 23 Apr 2009 03:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 8YdEREaKIZnm for ; Thu, 23 Apr 2009 03:26:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BA2553A6925 for ; Thu, 23 Apr 2009 03:26:37 -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 n3NARoB3021767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 13:27:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3NARmDW005271; Thu, 23 Apr 2009 13:27:48 +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: <18928.17060.932652.535677@fireball.kivinen.iki.fi> Date: Thu, 23 Apr 2009 13:27:48 +0300 From: Tero Kivinen To: Lakshminath Dondeti In-Reply-To: <49F011FE.4070206@qualcomm.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 10:26:41 -0000 Lakshminath Dondeti writes: > When did MOBIKE come into picture? What are you saying Tero, that IPsec > session resumption is an alternative to MOBIKE and a slow one at that? Yes. Both solve the same problem that IKE SA recovers from the IP-address change, or switching from one network to another (i.e. from cellular to WLAN). I do not really see any fundamental reason why the IKE SA needs to be taken down when in cellular. I can see reasons why it might not be needed, but the IKE SA could still be kept up and running, and if done that way, then MOBIKE will offer solution how to move the IKE SA to the new network, and it will mostly do it in 1 RT. > "Annoy" being the keyword. I am now more convinced that we are really > making the protocol inefficient because some kid might try to annoy some > people some time. To counter such potential annoyances which may not > happen at any frequency that matters, we are going to sacrifice the user > experience all the time? I am saying we are not sacrificing the user experience in any noticeable way even if we do 2 RT protocol. I expect that 99.999% users will never notice whether the 1 RT or 2 RT protocol was used if there is no attack. On the other hand, 100% users will notice the attacks if 1 RT protocol is used, and 0% of users will notice the attacks if 2 RT protocol is used. -- kivinen@iki.fi From ldondeti@qualcomm.com Thu Apr 23 04:09:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D08B3A724E for ; Thu, 23 Apr 2009 04:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.456 X-Spam-Level: X-Spam-Status: No, score=-105.456 tagged_above=-999 required=5 tests=[AWL=1.143, 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 NCyxGEMdBSLZ for ; Thu, 23 Apr 2009 04:09:10 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2C2AB3A722C for ; Thu, 23 Apr 2009 04:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240485028; x=1272021028; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49F04C9A.6080400@qualcomm.com>|Date:=20Th u,=2023=20Apr=202009=2016:40:18=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Tero=20Kivinen=20|CC:=20IPsecme=20WG=20,=20Paul=20Ho ffman=20|Subject:=20Re:=20[IPsec] =20Issue=20#98:=201=20or=20two=20round=20trips=20for=20re sumption|References:=20=09=09<7F9A6D26EB51614FBF9F81C0DA4CFEC8D 9ACEC4D5B@il-ex01.ad.checkpoint.com>=09=09<1 8925.45980.896489.919446@fireball.kivinen.iki.fi>=09<49EE BDD3.2070706@qualcomm.com>=09<18926.62554.713509.846039@f ireball.kivinen.iki.fi>=09<49F011FE.4070206@qualcomm.com> =20<18928.17060.932652.535677@fireball.kivinen.iki.fi> |In-Reply-To:=20<18928.17060.932652.535677@fireball.kivin en.iki.fi>|Content-Type:=20text/plain=3B=20charset=3DISO- 8859-15=3B=20format=3Dflowed|Content-Transfer-Encoding: =207bit|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5593 "=3B=20a=3D"17379581"; bh=hE1ODlCoy0tWCaElTZ3yxujl0INUMlLqXOgOIoyeeyk=; b=nqSeJPQUm2gFK83KNl+FkH9KvDsNmCfJLjvUZvGRcS8O31LZxcBrM9a6 MvKp+HNGgQrAawrRQ3Cf7gkVLgwH1BGDaT+zkTVW118B12qDUX6OFyqUE +WnlQjSVx+Tukd57mA4MAyPG0IC/S/yCPysplopy200OXBcesJL2NfZx+ U=; X-IronPort-AV: E=McAfee;i="5300,2777,5593"; a="17379581" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2009 04:10:25 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3NBAPSh020520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Apr 2009 04:10:25 -0700 Received: from [10.44.81.72] (ldondetixp2.ap.qualcomm.com [10.44.81.72]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3NBAJ3I011260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Apr 2009 04:10:23 -0700 Message-ID: <49F04C9A.6080400@qualcomm.com> Date: Thu, 23 Apr 2009 16:40:18 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tero Kivinen References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> In-Reply-To: <18928.17060.932652.535677@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:09:11 -0000 On 4/23/2009 3:57 PM, Tero Kivinen wrote: > Lakshminath Dondeti writes: > >> When did MOBIKE come into picture? What are you saying Tero, that IPsec >> session resumption is an alternative to MOBIKE and a slow one at that? >> > > Yes. > > Both solve the same problem that IKE SA recovers from the IP-address > change, or switching from one network to another (i.e. from cellular > to WLAN). > > I do not really see any fundamental reason why the IKE SA needs to be > taken down when in cellular. I can see reasons why it might not be > needed, but the IKE SA could still be kept up and running, and if done > that way, then MOBIKE will offer solution how to move the IKE SA to > the new network, and it will mostly do it in 1 RT. > > MOBIKE assumes that the other side has state, correct? Session resumption has to do with providing that state. How are they the same? >> "Annoy" being the keyword. I am now more convinced that we are really >> making the protocol inefficient because some kid might try to annoy some >> people some time. To counter such potential annoyances which may not >> happen at any frequency that matters, we are going to sacrifice the user >> experience all the time? >> > > I am saying we are not sacrificing the user experience in any > noticeable way even if we do 2 RT protocol. I expect that 99.999% > users will never notice whether the 1 RT or 2 RT protocol was used if > there is no attack. On the other hand, 100% users will notice the > attacks if 1 RT protocol is used, and 0% of users will notice the > attacks if 2 RT protocol is used. > Under attack, the protocol stretches to 3 RTs. So, you are saying that there is no noticeable difference between 1 and 2 RTs, but there is between 2 and 3? Is your point that the DH computation will be noticed? My point is that we'd beyond the real-time budgets after 1 RT anyway. Now of course, to prove any of this (as opposed to your word against mine), we have to workout test scenarios and the like and measure user perception (we can throw in 5 9's all we want, but people spend millions on real perception testing). All I am asking for is for the group to realize that there are cases where the budgets are low and therefore allow the 1 RT exchange. regards, Lakshminath From kivinen@iki.fi Thu Apr 23 06:48:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5AE3A6903 for ; Thu, 23 Apr 2009 06:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 GgBAHRprpcQ8 for ; Thu, 23 Apr 2009 06:48:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E70E93A67F8 for ; Thu, 23 Apr 2009 06:48:20 -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 n3NDnYOC001630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 16:49:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3NDnXVK016280; Thu, 23 Apr 2009 16:49:33 +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: <18928.29165.128628.119901@fireball.kivinen.iki.fi> Date: Thu, 23 Apr 2009 16:49:33 +0300 From: Tero Kivinen To: Lakshminath Dondeti In-Reply-To: <49F04C9A.6080400@qualcomm.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:48:22 -0000 Lakshminath Dondeti writes: > MOBIKE assumes that the other side has state, correct? Yes. > Session resumption has to do with providing that state. How are they > the same? In this example given (handover from cellular to wlan, without breaking existing phone call), I do not really see any point why the IKE SA state needs to be removed from the server side, and as such I think the much better solution is to use MOBIKE and keep IKE SA up all the time. As I do not have any idea where people want to use the resumption, I have VERY HARD time to justify the different protocol options. But anyways one of the things required is that it "shall not have negative impact on IKEv2 security features", and I think 1 RT protocol will have negative impact to security features. > Under attack, the protocol stretches to 3 RTs. 3 RT + Diffie-Hellman + public key operation + user interaction to type in password or securid token etc. > So, you are saying that there is no noticeable difference between 1 > and 2 RTs, but there is between 2 and 3? Is your point that the DH > computation will be noticed? With group 18: yes... With typing in the passphase to do reauthentication with RSA token card : yes. With digging out your securid card and typing in pin, and typing in the next token to the prompt: yes. > My point is that we'd beyond the real-time budgets after 1 RT > anyway. You should not really do break-before-make style of transitions on real-time environments, and if you keep the old connection while making the new one, then this whole issue is non-issue. -- kivinen@iki.fi From vidyan@qualcomm.com Fri Apr 24 00:12:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C2728C72F for ; Fri, 24 Apr 2009 00:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.169 X-Spam-Level: X-Spam-Status: No, score=-105.169 tagged_above=-999 required=5 tests=[AWL=1.430, 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 qZkIwCCwNonc for ; Fri, 24 Apr 2009 00:12:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E9BDB3A6FD6 for ; Fri, 24 Apr 2009 00:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1240557156; x=1272093156; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Tero=20Kivinen=20,=0D=0A=20=20=20=20 =20=20=20=20"Dondeti,=20Lakshminath"=0D=0A=09|CC:=20IPsecme=20WG=20,=20Paul =20Hoffman=20|Date:=20Fri,=2024=20 Apr=202009=2000:12:25=20-0700|Subject:=20RE:=20[IPsec]=20 Issue=20#98:=201=20or=20two=20round=20trips=20for=20resum ption|Thread-Topic:=20[IPsec]=20Issue=20#98:=201=20or=20t wo=20round=20trips=20for=20resumption|Thread-Index:=20Acn EGmzM9FBwBWfQSfazNZe7T8gU3wAjnKOQ|Message-ID:=20|References:=20 =0D=0A=09=0D=0A=09<7F9A6D26EB51614FBF9F81C0D A4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com>=0D=0A=09=0D=0A=09<18925.45980.896489.919446@fireball.kiv inen.iki.fi>=0D=0A=09<49EEBDD3.2070706@qualcomm.com>=0D =0A=09<18926.62554.713509.846039@fireball.kivinen.iki.fi> =0D=0A=09<49F011FE.4070206@qualcomm.com>=0D=0A=09<18928.1 7060.932652.535677@fireball.kivinen.iki.fi>=0D=0A=09<49F0 4C9A.6080400@qualcomm.com>=0D=0A=20<18928.29165.128628.11 9901@fireball.kivinen.iki.fi>|In-Reply-To:=20<18928.29165 .128628.119901@fireball.kivinen.iki.fi>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5594"=3B=20a=3D"17415270"; bh=C2G9EN1eL1bGRVV3UicpAQ5Z5LXZi61QOYrluCDQDeA=; b=qRea0872dkGKQMwPyTF9pwfUiYxvHieVP/HPYKMxQmMsO+dwSAEdk4N1 x6t4x8ZAaajhbeV17L6MBnGORiOfUiC0vx3oZoC3GwKcQ/ZePMNuc7vWH x09RkBMLO0JIGQp+SDB149efbouAgQAQ9N6pShXuNlrwWrvAOxmIt3qcQ U=; X-IronPort-AV: E=McAfee;i="5300,2777,5594"; a="17415270" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2009 00:12:36 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3O7CZW3012935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2009 00:12:35 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3O7CRne001210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Apr 2009 00:12:30 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 24 Apr 2009 00:12:28 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 24 Apr 2009 00:12:26 -0700 From: "Narayanan, Vidya" To: Tero Kivinen , "Dondeti, Lakshminath" Date: Fri, 24 Apr 2009 00:12:25 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnEGmzM9FBwBWfQSfazNZe7T8gU3wAjnKOQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> In-Reply-To: <18928.29165.128628.119901@fireball.kivinen.iki.fi> 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: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 07:12:29 -0000 Somehow, we in the IETF think that we can make decisions for other standard= s bodies, especially ones that do real deployments. I don't know how we ca= n say things like they should always use the IKE SA whether they need it or= not - there can be several reasons not to use it when they don't need it, = including how some VPN vendors may charge. Also, mobility may need to be h= andled by MIP6 and we know that it doesn't co-exist with MOBIKE. =20 I'm also further intrigued by this attack we are so passionately discussing= - the motivation for the attacker here is to annoy other users? Surely, = the attacker gets nothing meaningful in return - I simply can't see how the= risk of such an attack can be anywhere close to even medium - it is barely= low in my view. The reward for the attacker in return for the work is non= -existent - if someone can steal spectrum or otherwise get Internet access = for free or get access to other users' credentials, etc., it is worth discu= ssing and protecting against. In this case, I'd say that we've already spe= nt more time discussing it than it is worth it. =20 Vidya > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Tero Kivinen > Sent: Thursday, April 23, 2009 6:50 AM > To: Dondeti, Lakshminath > Cc: IPsecme WG; Paul Hoffman > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > Lakshminath Dondeti writes: > > MOBIKE assumes that the other side has state, correct? >=20 > Yes. >=20 > > Session resumption has to do with providing that state. How are they > > the same? >=20 > In this example given (handover from cellular to wlan, without > breaking existing phone call), I do not really see any point why the > IKE SA state needs to be removed from the server side, and as such I > think the much better solution is to use MOBIKE and keep IKE SA up all > the time. >=20 > As I do not have any idea where people want to use the resumption, I > have VERY HARD time to justify the different protocol options. But > anyways one of the things required is that it "shall not have negative > impact on IKEv2 security features", and I think 1 RT protocol will > have negative impact to security features. >=20 > > Under attack, the protocol stretches to 3 RTs. >=20 > 3 RT + Diffie-Hellman + public key operation + user interaction to > type in password or securid token etc. >=20 > > So, you are saying that there is no noticeable difference between 1 > > and 2 RTs, but there is between 2 and 3? Is your point that the DH > > computation will be noticed? >=20 > With group 18: yes... With typing in the passphase to do > reauthentication with RSA token card : yes. With digging out your > securid card and typing in pin, and typing in the next token to the > prompt: yes. >=20 > > My point is that we'd beyond the real-time budgets after 1 RT > > anyway. >=20 > You should not really do break-before-make style of transitions on > real-time environments, and if you keep the old connection while > making the new one, then this whole issue is non-issue. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ldondeti@qualcomm.com Fri Apr 24 02:44:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1448F3A6AA2 for ; Fri, 24 Apr 2009 02:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 j1HTmwZWwDii for ; Fri, 24 Apr 2009 02:44:57 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E42073A6838 for ; Fri, 24 Apr 2009 02:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1240566375; x=1272102375; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<49F18A61.3010400@qualcomm.com>|Date:=20Fr i,=2024=20Apr=202009=2015:16:09=20+0530|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Mozi lla/5.0=20(Windows=3B=20U=3B=20Windows=20NT=205.1=3B=20en -US=3B=20rv:1.9.1b3pre)=20Gecko/20090223=20Thunderbird/3. 0b2|MIME-Version:=201.0|To:=20Tero=20Kivinen=20|CC:=20IPsecme=20WG=20,=20Paul=20Ho ffman=20|Subject:=20Re:=20[IPsec] =20Issue=20#98:=201=20or=20two=20round=20trips=20for=20re sumption|References:=20=09=09<7F9A6D26EB51614FBF9F81C0DA4CFEC8D 9ACEC4D5B@il-ex01.ad.checkpoint.com>=09=09<1 8925.45980.896489.919446@fireball.kivinen.iki.fi>=09<49EE BDD3.2070706@qualcomm.com>=09<18926.62554.713509.846039@f ireball.kivinen.iki.fi>=09<49F011FE.4070206@qualcomm.com> =09<18928.17060.932652.535677@fireball.kivinen.iki.fi>=09 <49F04C9A.6080400@qualcomm.com>=20<18928.29165.128628.119 901@fireball.kivinen.iki.fi>|In-Reply-To:=20<18928.29165. 128628.119901@fireball.kivinen.iki.fi>|Content-Type:=20te xt/plain=3B=20charset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5594"=3B=20a=3D"17419063"; bh=qZ2LAEsAIcsN++k9mIJgqir+JKfbb6F6H0tuexeVqJk=; b=rbKRukNq/6r9r0x5iFaI/q4fc4ybvB+j3Dv1qkl8awUHWy1yINU6Lasm v9y1PeTTexG3ypzNhBs+GIjS4D8xJzcLr67HyZcg4HTi0lDiI1TcKllIo +LBsMv1saLiotRetGJ/Ps2g1DTsSGynFie9Ii8EZkb2kseiocEwzyIoMG I=; X-IronPort-AV: E=McAfee;i="5300,2777,5594"; a="17419063" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2009 02:46:15 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3O9kFTF007518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Apr 2009 02:46:15 -0700 Received: from [10.44.81.72] (ldondetixp2.ap.qualcomm.com [10.44.81.72]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3O9k9ER008488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2009 02:46:13 -0700 Message-ID: <49F18A61.3010400@qualcomm.com> Date: Fri, 24 Apr 2009 15:16:09 +0530 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tero Kivinen References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> In-Reply-To: <18928.29165.128628.119901@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 09:44:58 -0000 On 4/23/2009 7:19 PM, Tero Kivinen wrote: > Lakshminath Dondeti writes: > >> MOBIKE assumes that the other side has state, correct? >> > > Yes. > > >> Session resumption has to do with providing that state. How are they >> the same? >> > > In this example given (handover from cellular to wlan, without > breaking existing phone call), I do not really see any point why the > IKE SA state needs to be removed from the server side, and as such I > think the much better solution is to use MOBIKE and keep IKE SA up all > the time. > > As I do not have any idea where people want to use the resumption, I > have VERY HARD time to justify the different protocol options. But > anyways one of the things required is that it "shall not have negative > impact on IKEv2 security features", and I think 1 RT protocol will > have negative impact to security features. > I fail to understand the "security" issue though in that the attack has already been identified as mere annoyance and does not result in any compromise. > >> Under attack, the protocol stretches to 3 RTs. >> > > 3 RT + Diffie-Hellman + public key operation + user interaction to > type in password or securid token etc. > > Depends. Some VPN clients do better than others and some require little to no user interaction. >> So, you are saying that there is no noticeable difference between 1 >> and 2 RTs, but there is between 2 and 3? Is your point that the DH >> computation will be noticed? >> > > With group 18: yes... With typing in the passphase to do > reauthentication with RSA token card : yes. With digging out your > securid card and typing in pin, and typing in the next token to the > prompt: yes. > > Same as above. But the real point here is that under the attack scenario, the user has bad experience. As long as the attack is categorized as low risk, we don't have to worry about this, do we? >> My point is that we'd beyond the real-time budgets after 1 RT >> anyway. >> > > You should not really do break-before-make style of transitions on > real-time environments, and if you keep the old connection while > making the new one, then this whole issue is non-issue. > Good advice, but that consensus process is from elsewhere. Not every device has multiple interfaces, not every architecture implements the idea of multiple simultaneous associations with base stations, and so on. If our goal is to design for multiple different scenarios and if the attack is really not serious, I really don't see why we would rule out 1 RT exchange. regards, Lakshminath From paul.hoffman@vpnc.org Fri Apr 24 08:18:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9320B28C20C for ; Fri, 24 Apr 2009 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72M9R+x9D7Mv for ; Fri, 24 Apr 2009 08:18:41 -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 A44113A6DE9 for ; Fri, 24 Apr 2009 08:16:47 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3OFI2H9073978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Apr 2009 08:18:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 24 Apr 2009 08:18:01 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Reopening issue #12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:18:42 -0000 Greetings again. During discussion with the other authors of IKEv2bis, we discovered some problems with the proposed resolution to issue #12 about traffic selectors when rekeying. The text I proposed to put in the document was this: ----- 2.9.2 Traffic Selectors in Rekeying Rekeying is used to replace an existing Child SA with another. If the new SA were allowed to have a narrower set of selectors than the original, traffic that was allowed on the old SA would be dropped in the new SA, thus violating the idea of "replacing". Thus, the new SA MUST NOT have narrower selectors than the original. If the rekeyed SA would ever need to have narrower scope than currently used SA, that would mean that the policy was changed in a way that the currently used SAs are against the policy. In that case, the SA should have been already deleted after the policy change took effect. When the initiator attemepts to rekey the Child SA, the proposed traffic selectors SHOULD be either the same as, or a superset of, the traffic selectors used in the old Child SA. That is, they would be the same as, or a superset of, the currently active (decorrelated) policy. The responder MUST NOT narrow down the traffic selectors narrower than the scope currently in use. Because a rekeyed SA can never have narrower scope than the one currently in use, there is no need for the selectors from the packet, so those selectors SHOULD NOT be sent. ----- It was pointed out that (a) this is a new MUST and (b) this also assumes that the encryption algorithm and so on will be the same. So, how does the WG want to proceed here? --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Fri Apr 24 14:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 451E93A6EE6; Fri, 24 Apr 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090424213002.451E93A6EE6@core3.amsl.com> Date: Fri, 24 Apr 2009 14:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al. Filename : draft-ietf-ipsecme-ikev2bis-03.txt Pages : 141 Date : 2009-04-24 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-24142056.I-D@ietf.org> --NextPart-- From night@nist.gov Fri Apr 24 14:04:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C079C3A6BD3; Fri, 24 Apr 2009 14:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[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 nlpUvHonQke2; Fri, 24 Apr 2009 14:04:03 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 91E4E3A6A56; Fri, 24 Apr 2009 14:04:03 -0700 (PDT) Received: from [127.0.0.1] (81-140.antd.nist.gov [129.6.140.81]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n3OL41aF011689; Fri, 24 Apr 2009 17:04:16 -0400 Message-ID: <49F22940.8000109@nist.gov> Date: Fri, 24 Apr 2009 17:04:00 -0400 From: Stephen Nightingale User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sp500-273-comments@antd.nist.gov Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: night@nist.gov X-Mailman-Approved-At: Sat, 25 Apr 2009 13:40:47 -0700 Subject: [IPsec] Announcing a USGv6 Testing meeting on May 27th X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:07:30 -0000 To all IPv6 aficionados, Please find attached the calling notice for a public meeting to be held at NIST on May 27th 2009, for the USGv6 Testing Program. Feel free to forward this notice and the attached documents to any persons or groups who may be interested but note that the room can hold a maximum of 60 persons, and priority is given to Accreditors, prospective USGv6 test laboratories and IPv6 test developers. Regards, Stephen Nightingale USGv6 Testing Program ============================================================ *Announcing a public meeting at NIST to discuss the rollout of the USGv6 Testing Program.* NIST invites interested parties including laboratory accreditors, testing laboratories and test equipment suppliers to attend a meeting regarding the USGv6 testing program. The purpose of the meeting is to resolve comments on the guidance document, NIST SP 500-273 and on the test specifications for the USG profile, and to launch the testing program. DATE OF THE MEETING: May 27th 2009 from 9am till 5pm. LOCATION: NIST, 100 Bureau Drive, Gaithersburg, MD 20899, Building 101, Lecture Room A. Directions can be found on the main NIST website at: http://www.nist.gov/public_affairs/maps/nistmaps.html PROVISIONAL AGENDA: 1. USG IPv6 testing program elements. 2. Test Laboratory Accreditation Issues a. Quality issues – by ISO 17025. b. Technical Methods – by NIST SP 500-273. c. Test specifications. d. Gaps – Overlaps – Fit. e. Interlaboratory comparisons considering multiple accreditors. 3. Supplier’s Declaration of Conformity a. Test laboratories separately encouraged to list products passed. 4. Test program management issues. 5. Discussion. FOR FURTHER INFORMATION CONTACT: Stephen Nightingale, sp500-273-comments@antd.nist.gov. ADDITIONAL INFORMATION: • The USGv6 testing website will be updated soon, and well before the meeting. URL is: http://www.antd.nist.gov/usgv6/testing.html. • The guidance document (NIST SP 500-273) has been the subject of a separate announcement. • All intending participants must register in advance to gain access to the campus. There is a limit of 60 participants constrained by the size of the room. Precedence will be given to the first 2 representatives of each Accreditation body, IPv6 testing laboratory, and IPv6 test equipment supplier. For the balance, we may need to limit participation to 1 representative per organization, and on a first come first served basis. Please indicate your organization’s potential role, designate your primary representative and register early in case we need to make this selection. Access to the NIST campus and the room cannot be guaranteed for unregistered participants. From jsun2501@gmail.com Sun Apr 26 12:02:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F263A6B09 for ; Sun, 26 Apr 2009 12:02: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 qDu9ojwWU6TT for ; Sun, 26 Apr 2009 12:02:08 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 0F15A3A6821 for ; Sun, 26 Apr 2009 12:02:07 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so2652404yxb.49 for ; Sun, 26 Apr 2009 12:03:28 -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; bh=4D3YQhQ8bDz1zNx/4oOcaYHPWHHwCKrtJoa4wDamOq8=; b=vqoze0ZeaR9miJRd/d83FSd4EshS3C6XlpD2sUtgnANo15WRhMlDPIEY4dHbUa7lkk 8raJRAwFhqvvvb5Kg3c6333n+wtXdXmzMUq9cZ4PEAQsuLF49Zmn8Fp+h159+C0X1E1U DmvmC8ypjRtScBo6DodJ7aYel/+ji9+gcIL0I= 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; b=QM7ByrcgZfMRinUq6k0kCZJIE3t9wKaI9lBQS+W4HoH9IpJDFDaXxAR3DNw90RoaDN M+TkaMxY4jXyVjGQJMuH6kSoCgJLQz+5Qj0voAThTPCikcr4qtHLIBrUItz9xpiqAovd 81btjXcIQ9rZ+wxeiNvZfbXKpFU0PBDb1fEj0= MIME-Version: 1.0 Received: by 10.231.19.8 with SMTP id y8mr1448990iba.50.1240772607843; Sun, 26 Apr 2009 12:03:27 -0700 (PDT) In-Reply-To: <7d660a970904261157q5164379eobc07a3c7d3f70789@mail.gmail.com> References: <7d660a970904261120q3259cccay97d0f8269cddf2a1@mail.gmail.com> <7d660a970904261126t6800331g7387bc760efccf4f@mail.gmail.com> <7d660a970904261133q2044e1d6ybd50963afbab0009@mail.gmail.com> <7d660a970904261140u5e97ceaew44c49356b44fff9a@mail.gmail.com> <7d660a970904261142u641a9d27k8e8048c0b0e56627@mail.gmail.com> <7d660a970904261144h6402718dse8cb7dc1d36de6ae@mail.gmail.com> <7d660a970904261148kbc228c5x8845ca624d999c85@mail.gmail.com> <7d660a970904261153w65dd2931tf86b10c594636a7c@mail.gmail.com> <7d660a970904261157q5164379eobc07a3c7d3f70789@mail.gmail.com> Date: Sun, 26 Apr 2009 12:03:27 -0700 Message-ID: <7d660a970904261203k6c96bfebs345976f0c22119c5@mail.gmail.com> From: Jeff Sun To: Paul Hoffman Content-Type: multipart/alternative; boundary=002215048103899eba046879e213 Cc: IPsecme WG Subject: Re: [IPsec] Reopening issue #12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 19:02:09 -0000 --002215048103899eba046879e213 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, I'm not sure my opinion counts since Paul called for WG input. In any event, it seems to me that rekeying a CHILD_SA the way its currently done seems more like creating a new CHILD_SA, especially since the SA, TSi, TSr, and the optional N(TRANSPORT_MODE) Payloads are included. Rekeying a CHILD_SA shouldn't require all these payloads - it should only include some form of notification, the Nonce Payload, and the optional KE Payload. Any new traffic flow that is not covered by existing CHILD_SAs would trigger a new CREATE_CHILD_SA exchange - this seems more straight forward than mandating rekeying proceessing to create wider scoped CHILD_SAs that may never utilize these wider selectors and may not even be changed due to responder narrowing and responder policy changes. In any event, I do not think the new responder MUST hurts anything. And unless I'm missing something, any new negotiated transform types changes incurred ought to be fine since they were both acceptable by both polcies. - Jeff Sun On Apr 24, 2009 8:20 AM, "Paul Hoffman" wrote: Greetings again. During discussion with the other authors of IKEv2bis, we discovered some problems with the proposed resolution to issue #12 about traffic selectors when rekeying. The text I proposed to put in the document was this: ----- 2.9.2 Traffic Selectors in Rekeying Rekeying is used to replace an existing Child SA with another. If the new SA were allowed to have a narrower set of selectors than the original, traffic that was allowed on the old SA would be dropped in the new SA, thus violating the idea of "replacing". Thus, the new SA MUST NOT have narrower selectors than the original. If the rekeyed SA would ever need to have narrower scope than currently used SA, that would mean that the policy was changed in a way that the currently used SAs are against the policy. In that case, the SA should have been already deleted after the policy change took effect. When the initiator attemepts to rekey the Child SA, the proposed traffic selectors SHOULD be either the same as, or a superset of, the traffic selectors used in the old Child SA. That is, they would be the same as, or a superset of, the currently active (decorrelated) policy. The responder MUST NOT narrow down the traffic selectors narrower than the scope currently in use. Because a rekeyed SA can never have narrower scope than the one currently in use, there is no need for the selectors from the packet, so those selectors SHOULD NOT be sent. ----- It was pointed out that (a) this is a new MUST and (b) this also assumes that the encryption algorithm and so on will be the same. So, how does the WG want to proceed here? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --002215048103899eba046879e213 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

All,
I'm not sure my opinion counts since Paul called for WG input.=A0 In an= y event, it seems to me that rekeying a CHILD_SA the way its currently done= seems more like creating a new CHILD_SA, especially since the SA, TSi, TSr= , and the optional N(TRANSPORT_MODE) Payloads are included.=A0

Rekeying a CHILD_SA shouldn't require all these payloads - it should= only include some form of notification, the Nonce Payload, and the optiona= l KE Payload.=A0 Any new traffic flow that is not covered by existing CHILD= _SAs would trigger a new CREATE_CHILD_SA exchange - this seems more straigh= t forward than mandating rekeying proceessing to create wider scoped CHILD_= SAs that may never utilize=A0 these wider selectors and may not even be cha= nged due to responder narrowing and responder policy changes.

In any event, I do not think the new responder MUST hurts anything.=A0 A= nd unless I'm missing something, any new negotiated transform types cha= nges incurred ought to be fine since they were both acceptable by both polc= ies.

- Jeff Sun

On Apr 24, 2009 8:20 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
=
Greetings again. During discussion with the other authors of IKEv2bis, = we discovered some problems with the proposed resolution to issue #12 about= traffic selectors when rekeying. The text I proposed to put in the documen= t was this:
-----
2.9.2 Traffic Selectors in Rekeying

Rekeying is used to replace an existing Child SA with another. If the new S= A were allowed to have a narrower set of selectors than the original, traff= ic that was allowed on the old SA would be dropped in the new SA, thus viol= ating the idea of "replacing". Thus, the new SA MUST NOT have nar= rower selectors than the original. If the rekeyed SA would ever need to hav= e narrower scope than currently used SA, that would mean that the policy wa= s changed in a way that the currently used SAs are against the policy. In t= hat case, the SA should have been already deleted after the policy change t= ook effect.

When the initiator attemepts to rekey the Child SA, the proposed traffic se= lectors SHOULD be either the same as, or a superset of, the traffic selecto= rs used in the old Child SA. That is, they would be the same as, or a super= set of, the currently active (decorrelated) policy. The responder MUST NOT = narrow down the traffic selectors narrower than the scope currently in use.=

Because a rekeyed SA can never have narrower scope than the one currently i= n use, there is no need for the selectors from the packet, so those selecto= rs SHOULD NOT be sent.
-----

It was pointed out that (a) this is a new MUST and (b) this also assumes th= at the encryption algorithm and so on will be the same.

So, how does the WG want to proceed here?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--002215048103899eba046879e213-- From kivinen@iki.fi Mon Apr 27 04:57:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDED3A68FD for ; Mon, 27 Apr 2009 04:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 S6RT7OuuAajU for ; Mon, 27 Apr 2009 04:57:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4A33A6870 for ; Mon, 27 Apr 2009 04:57:33 -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 n3RBworO018185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 14:58:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3RBwmSE017622; Mon, 27 Apr 2009 14:58:48 +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: <18933.40440.788476.6666@fireball.kivinen.iki.fi> Date: Mon, 27 Apr 2009 14:58:48 +0300 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 23 min Cc: IPsecme WG , "Dondeti, Lakshminath" , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:57:35 -0000 Narayanan, Vidya writes: > Somehow, we in the IETF think that we can make decisions for other > standards bodies, especially ones that do real deployments. I don't > know how we can say things like they should always use the IKE SA > whether they need it or not - there can be several reasons not to > use it when they don't need it, including how some VPN vendors may > charge. It is impossible for IETF to think about those other standard bodies, as we do not know what they plan to do. I have several times tried to get people to explain me the use case for which this protocol has been aimed for, so I could think whether some specific attack or optimization is suitable or not, but as only reply I have received is, that it is outside the scope of this discussion, then there is really no point of blaming people for making decisions for other standard bodies. What else can we do? Nobody has still explained me why the 1 RT protocol is required for those other standard bodies, and why should the security of this protocol be weaker because of the requirements from those other unknown standard bodies. > Also, mobility may need to be handled by MIP6 and we know that it > doesn't co-exist with MOBIKE. That is news for me. One of the reasons MOBIKE was created was to allow it to be used as building block for Mobile IP. So why does not MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could be used by Mobile IP, and there were Mobile IP people taking part in the specification process back then. So what is the exact problem there? I am thinking it might not be worth of standardizing the resumption at all, if we for that again hear 3 years after we finished the work that it cannot be used because of some unspecified reason. > I'm also further intrigued by this attack we are so passionately > discussing - the motivation for the attacker here is to annoy other > users? Almost all DoS attacks are only there to annoy the users. If someone uses DoS attack to bring some web server or dns-name server or similar down for few hours, that is just annoying users. Everything will work again when the attacks stops, and might even work during the attack but access might be much slower than normally. > Surely, the attacker gets nothing meaningful in return - I > simply can't see how the risk of such an attack can be anywhere > close to even medium - it is barely low in my view. Most of the DoS attackers are not wanting to get something meaningful in return. I still think we need to design protocols so they are secure against such attacks. And it is not only against protecting against the attacks, this is also against normal working of the protocol. I.e. if sending one packet whose response packets gets lost, can destroy state from the server, in such way that client cannot detect that, and needs to start IKE SA creation from the beginning, I consider even that a big problem. When we were specifying the MOBIKE we made sure it works also in cases where some of the network connections are one-way, i.e. no return packets get back. It consideres such links broken, and does not use them. This was considered important to get it right, because in that environment it was seen that quite often the links it might see might have such unidirectional properties, and the whole protocol cannot be broken because of one such link. With resumption the whole protocol breaks down if such unidirectional link is ever tried to be used. -- kivinen@iki.fi From kivinen@iki.fi Mon Apr 27 05:02:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1453A6B29 for ; Mon, 27 Apr 2009 05:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUSE142T07qz for ; Mon, 27 Apr 2009 05:02:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9235628C0EF for ; Mon, 27 Apr 2009 05:02:11 -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 n3RC3UV2005263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 15:03:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3RC3UBo002997; Mon, 27 Apr 2009 15:03:30 +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: <18933.40722.38074.594516@fireball.kivinen.iki.fi> Date: Mon, 27 Apr 2009 15:03:30 +0300 From: Tero Kivinen To: Lakshminath Dondeti In-Reply-To: <49F18A61.3010400@qualcomm.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> <49F18A61.3010400@qualcomm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:02:12 -0000 Lakshminath Dondeti writes: > > You should not really do break-before-make style of transitions on > > real-time environments, and if you keep the old connection while > > making the new one, then this whole issue is non-issue. > Good advice, but that consensus process is from elsewhere. Not every > device has multiple interfaces, not every architecture implements the > idea of multiple simultaneous associations with base stations, and so on. We were discussing moving traffic from "secure" cellular network (which do not require IPsec protection, and IKE SA was suspended because of that) to "unsecure" WLAN network (which now requires IPsec protection because it is unsecure). Do you really say some device which can talk to both WLAN and cellular network cannot talk to both of them simultaneously? Even with if they cannot be used simultaneously they can still bring the IKE SA up while using the cellular network, and then use MOBIKE to move the already up and resumed IKE SA from cellular to WLAN. It seems there is again some scenarios you are refering to that I do not know about, as I do not really think you are now talking about the same use case anymore. -- kivinen@iki.fi From kivinen@iki.fi Mon Apr 27 05:18:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604EA28C127 for ; Mon, 27 Apr 2009 05:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQEV1rfEM+un for ; Mon, 27 Apr 2009 05:18:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4299A28C0E1 for ; Mon, 27 Apr 2009 05:18:41 -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 n3RCK0k1021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 15:20:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3RCK0Pm007087; Mon, 27 Apr 2009 15:20:00 +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: <18933.41712.378159.694316@fireball.kivinen.iki.fi> Date: Mon, 27 Apr 2009 15:20:00 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 15 min Cc: IPsecme WG Subject: [IPsec] Reopening issue #12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:18:43 -0000 Paul Hoffman writes: > It was pointed out that (a) this is a new MUST and Yes, but it can mostly be already deducted from the requirement that end node cannot violate its own policy, meaning it needs to delete Child SA which are not following his policy. If that is already done, there is no point for the new SA having narrower scope than old SA had, and making this MUST makes it simplier for implementations (i.e. they do not need to think what to do for the traffic which do not fit the rekeyed SA, and we do not need to add the traffic selectors from the packet parts). > (b) this also > assumes that the encryption algorithm and so on will be the same. No it does not. I do not see any text there saying anything about encryption algorithms. Those are negotiated as normally and again if policy has been changed so that the original algorithms are not valid anymore, then the child SA should have been deleted already. There are cases where intiator can only propose subset of algorithms it itself finds acceptable, but that will simply result in NO_PROPOSAL_CHOSEN failure, if other end does not accept any of the algorithms initiator offered. > So, how does the WG want to proceed here? I do not think we need to do anything more than what is already done here. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Apr 27 12:14:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA2628C1A6 for ; Mon, 27 Apr 2009 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 POIJBxFgfDlr for ; Mon, 27 Apr 2009 12:14:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4E17428C196 for ; Mon, 27 Apr 2009 12:14:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 891B030C002; Mon, 27 Apr 2009 22:16:07 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 42E162CC001 for ; Mon, 27 Apr 2009 22:16:07 +0300 (IDT) X-CheckPoint: {49F60047-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 n3RJG6qO000479 for ; Mon, 27 Apr 2009 22:16:06 +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; Mon, 27 Apr 2009 22:16:06 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:16:03 +0300 Thread-Topic: Preparing for the virtual interim meeting next week Thread-Index: AcnHbJsg5LJq9SHXTGm3s08LTRs0nQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC559B@il-ex01.ad.checkpoint.com> 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_01C9C785.C0961990" MIME-Version: 1.0 Subject: [IPsec] Preparing for the virtual interim meeting next week X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:14:52 -0000 ------=_NextPart_000_0149_01C9C785.C0961990 Content-Type: multipart/alternative; boundary="----=_NextPart_001_014A_01C9C785.C0961990" ------=_NextPart_001_014A_01C9C785.C0961990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here's to remind you of the meeting we are holding next Tuesday, May 5. Please visit the ipsecme WG wiki (http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki) for exact details on the meeting. Make sure you download the conferencing client and try to connect to the host in advance of the call (you might want to do it with a friend, to check that audio works for you). The last call period for the Redirect draft (http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08) is up in 3 days. So if you want to send comments before it goes to our AD for review, or if you just want to voice your support of the draft, this is the time. I will shortly publish a new round of issues to discuss before and during the meeting. Please help to resolve them so that we don't have the poor authors flip coins instead. Please post your comments *this week*, so that we are aware of hot issues before the meeting. BTW, an updated status page of all WG documents is also linked from the wiki page. Thanks, Yaron ------=_NextPart_001_014A_01C9C785.C0961990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Here’s to remind you of the meeting we are = holding next Tuesday, May 5. Please visit the ipsecme WG wiki = (http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki) for exact details on the meeting. Make sure you download the = conferencing client and try to connect to the host in advance of the call (you might = want to do it with a friend, to check that audio works for = you).

 

The last call period for the Redirect draft = (http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-= 08) is up in 3 days. So if you want to send comments before it goes to our AD for = review, or if you just want to voice your support of the draft, this is the = time.

 

I will shortly publish a new round of issues to = discuss before and during the meeting. Please help to resolve them so that we = don’t have the poor authors flip coins instead. Please post your comments = *this week*, so that we are aware = of hot issues before the meeting.

 

BTW, an updated status page of all WG documents is = also linked from the wiki page.

 

Thanks,

         =    Yaron

------=_NextPart_001_014A_01C9C785.C0961990-- ------=_NextPart_000_0149_01C9C785.C0961990 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5MTYwM1owIwYJKoZIhvcNAQkEMRYEFP2jKU9YA7p2 q3JxmDmHQtv7hrWdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA N5fZIoW4vQ7cdVtTUuhUMhlSVtPIHm1M6pFipXfNZdNXy7gDfB/TtmdsR7Zz82XAUXkZEa3VAb64 IIxyCR5btOn3Il2sbLjpIX1tw9mYXKmQYCzpfjGfhHtsVTOqqx/XJHvhVntB6kEfzwATTbZBIRXI z9D3genFcC23kNsXspB9Ju62hHVfEdUf75hxb23aVAo6+PHY9VxKhEth5sYYlj8ho/yltSd6OhWD u0cp1beQ2Cj2svjfSmgblp62PhDtBxx3/saNGrs72r85WNO+VzhzfmMlg/8ejWTFoz8AszmMSuMS 5qkuHhb8dALk9lGWV1/5XyAXzUExVYrXU9I6tAAAAAAAAA== ------=_NextPart_000_0149_01C9C785.C0961990-- From yaronf@checkpoint.com Mon Apr 27 12:19:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4882E28C1C8 for ; Mon, 27 Apr 2009 12:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 C4k+a3V2A4IG for ; Mon, 27 Apr 2009 12:19:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0A06128C1C5 for ; Mon, 27 Apr 2009 12:19:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 85CE530C002; Mon, 27 Apr 2009 22:21:00 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3898A2CC001 for ; Mon, 27 Apr 2009 22:21:00 +0300 (IDT) X-CheckPoint: {49F6016C-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 n3RJKxqO001661 for ; Mon, 27 Apr 2009 22:20:59 +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; Mon, 27 Apr 2009 22:20:59 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:20:56 +0300 Thread-Topic: Issue #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Thread-Index: AcnHbUneeIL6eKXxSgqeANR5ZDuINw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC559C@il-ex01.ad.checkpoint.com> 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_0151_01C9C786.6F381020" MIME-Version: 1.0 Subject: [IPsec] Issue #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:19:44 -0000 ------=_NextPart_000_0151_01C9C786.6F381020 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0152_01C9C786.6F381020" ------=_NextPart_001_0152_01C9C786.6F381020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > o Implementations MUST process received UDP-encapsulated ESP packets > even when no NAT was detected. > > o The original source and destination IP address required for the > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > are obtained from the Traffic Selectors associated with the > exchange. In the case of NAT traversal, the Traffic Selectors > MUST contain exactly one IP address, which is then used as the > original IP address. Tero: Getting original source and destination IP address from the traffic selectors do not really work currently. Especially when combined with the selectors from the packet and when responder is behind nat or similar problems. Paul: Not done. Specify replacement text and discuss on the mailing list. See also Tero's mail with proposed text here: http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html ------=_NextPart_001_0152_01C9C786.6F381020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>     o  Implementations = MUST process received UDP-encapsulated ESP packets

>        even = when no NAT was detected.

> 

>     o  The original = source and destination IP address required for the

>        = transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])

>        are = obtained from the Traffic Selectors associated with the

>        = exchange.  In the case of NAT traversal, the Traffic Selectors

>        MUST = contain exactly one IP address, which is then used as the

>        = original IP address.

 

Tero:

Getting original source and destination IP address = from the traffic

selectors do not really work currently. Especially = when combined with

the selectors from the packet and when responder is = behind nat or

similar problems.

 

Paul: Not done. Specify replacement text and discuss = on the mailing list.

 

See also Tero’s mail with proposed text here: = http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html

 

------=_NextPart_001_0152_01C9C786.6F381020-- ------=_NextPart_000_0151_01C9C786.6F381020 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5MjA1NlowIwYJKoZIhvcNAQkEMRYEFJpTdeoI2eZJ JaAqQg5MAm6MSrOEMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA W2XzmjrntlR8j/uI4QQjzKlASNxtcaQ7bg++wdcFT0iZPhuO+hG3ZMH8IEYfUkxb+O1S0scDqKwI 4zt766JMG/kVjjAeGteU0sKXra5Sx6DoY/Y9PAXYKqbFB+AJTEln8tYUfZRpowiDzYYtH6eTPVRo ift2kqgWLHb5j99ggScSD3r7wxgCeEyF0keKqC/YaXCbHDIK2hyb/azG/JV9GzigjtUWjb9DO/DK ryWJccW5EfQL8VBdq+XBsK1s4zqKm2aLzmL6a2+7zKQ+giKqh8D8v8KNBO1k1kQKt0gvKa7BblIJ y/vA6vX37oJtGfslARhhXZFXUJauktlzp0szcgAAAAAAAA== ------=_NextPart_000_0151_01C9C786.6F381020-- From yaronf@checkpoint.com Mon Apr 27 12:31:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8880228C1FC for ; Mon, 27 Apr 2009 12:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 6xxJ0VOhmUyc for ; Mon, 27 Apr 2009 12:31:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 675683A7012 for ; Mon, 27 Apr 2009 12:31:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DDEEE30C001; Mon, 27 Apr 2009 22:32:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8FADB2CC001 for ; Mon, 27 Apr 2009 22:32:32 +0300 (IDT) X-CheckPoint: {49F60420-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 n3RJWQqP004120 for ; Mon, 27 Apr 2009 22:32:32 +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; Mon, 27 Apr 2009 22:32:28 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:32:26 +0300 Thread-Topic: Issue #13: INVALID_MAJOR_VESION similar to other notifies being discussed Thread-Index: AcnHbuU5YgBif/TrQzKH597dqnlBoA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC559D@il-ex01.ad.checkpoint.com> 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_0159_01C9C788.0A8E56F0" MIME-Version: 1.0 Subject: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies being discussed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:31:55 -0000 ------=_NextPart_000_0159_01C9C788.0A8E56F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_015A_01C9C788.0A8E56F0" ------=_NextPart_001_015A_01C9C788.0A8E56F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > {{ Clarif-7.7 }} There are two cases when such a one-way notification > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > sent outside of an IKE_SA. Note that such notifications are > explicitly not Informational exchanges; these are one-way messages > that must not be responded to. In case of INVALID_IKE_SPI, the > message sent is a response message, and thus it is sent to the IP > address and port from whence it came with the same IKE SPIs and the > Message ID copied. In case of INVALID_SPI, however, there are no IKE > SPI values that would be meaningful to the recipient of such a > notification. Using zero values or random values are both > acceptable. Tero: In a sense INVALID_MAJOR_VERSION is also this kind of notification which is sent outside of an IKE_SA, although it is sent as a response to the incoming IKE SA creation. Perhaps we should note this fact here? Paul: Not done. This is interesting, but should be discussed on the list. ------=_NextPart_001_015A_01C9C788.0A8E56F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>     {{ Clarif-7.7 }} There = are two cases when such a one-way notification

>     is sent: INVALID_IKE_SPI = and INVALID_SPI.  These notifications are

>     sent outside of an = IKE_SA.  Note that such notifications are

>     explicitly not = Informational exchanges; these are one-way messages

>     that must not be = responded to.  In case of INVALID_IKE_SPI, the

>     message sent is a = response message, and thus it is sent to the IP

>     address and port from = whence it came with the same IKE SPIs and the

>     Message ID copied.  = In case of INVALID_SPI, however, there are no IKE

>     SPI values that would be = meaningful to the recipient of such a

>     notification.  = Using zero values or random values are both

>     = acceptable.

 

Tero:

 

In a sense INVALID_MAJOR_VERSION is also this kind of notification

which is sent outside of an IKE_SA, although it is = sent as a response

to the incoming IKE SA creation. Perhaps we should = note this fact

here?

 

Paul: Not done. This is interesting, but should be = discussed on the list.

------=_NextPart_001_015A_01C9C788.0A8E56F0-- ------=_NextPart_000_0159_01C9C788.0A8E56F0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5MzIyNlowIwYJKoZIhvcNAQkEMRYEFDqxPbmibnG8 BJDVvLfYBlmPT2RTMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA bi+1HSSxE/gxJaxHC+3mhGzmIdP9xkjt+TDFJD+0NW5yxx+zmBTIGbiSleWAVT1Aj6KAx9pVduvF cS5/sCEze7cvJYVCbbNH7q0Mqz6cmoeVa9+uvxy2x20+4IE9I2Bz4iE6ssioH5tVy9HIBGhUvgO5 3MToZnrbzjSEIOi+jOil/SKe1ucNpjCos8QdoygQFCZLR1HNEc8hKfQv2DYC/E1bFDvvLrqvNggy hIw508tgVVCO7kBXFgwNkF89GYJnNdyGfh2eFA0pI/0iE/Ipd8X+VhWE7FGCrEjQY5csaqTKPZ+G jt8+BD5gXhedO2yYWuJjLbowez4CY58EsasaAAAAAAAAAA== ------=_NextPart_000_0159_01C9C788.0A8E56F0-- From yaronf@checkpoint.com Mon Apr 27 12:47:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4B03A69CB for ; Mon, 27 Apr 2009 12:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 ySTyb0VuQntK for ; Mon, 27 Apr 2009 12:47:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 886823A692F for ; Mon, 27 Apr 2009 12:47:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BF1BD30C001; Mon, 27 Apr 2009 22:48:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6A71D2CC001 for ; Mon, 27 Apr 2009 22:48:22 +0300 (IDT) X-CheckPoint: {49F607D6-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 n3RJmLqO007522 for ; Mon, 27 Apr 2009 22:48:21 +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; Mon, 27 Apr 2009 22:48:21 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:48:17 +0300 Thread-Topic: Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies Thread-Index: AcnHcRwVjcvd2ms4ReuFk0TNMMiAmA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A0@il-ex01.ad.checkpoint.com> 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_0161_01C9C78A.4173C450" MIME-Version: 1.0 Subject: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:47:04 -0000 ------=_NextPart_000_0161_01C9C78A.4173C450 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0162_01C9C78A.4173C450" ------=_NextPart_001_0162_01C9C78A.4173C450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > IKE is a reliable protocol, in the sense that the initiator MUST > retransmit a request until either it receives a corresponding reply > OR it deems the IKE security association to have failed and it > discards all state associated with the IKE_SA and any CHILD_SAs > negotiated using that IKE_SA. > > {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require > some special handling. When a responder receives an IKE_SA_INIT > request, it has to determine whether the packet is retransmission > belonging to an existing 'half-open' IKE_SA (in which case the > responder retransmits the same response), or a new request (in which > case the responder creates a new IKE_SA and sends a fresh response), > or it belongs to an existing IKE_SA where the IKE_AUTH request has > been already received (in which case the responder ignores it). Tero: There is also the case of the invalid KE and cookie notifies, i.e. we need to add comment about those too: ... or it belongs to an existing IKE_SA where the IKE_AUTH request has been already received (in which case the responder ignores it), or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the IKE_SA_INIT request. Paul: Not done. This is interesting, but should be discussed on the list. ------=_NextPart_001_0162_01C9C78A.4173C450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>     IKE is a reliable = protocol, in the sense that the initiator MUST

>     retransmit a request = until either it receives a corresponding reply

>     OR it deems the IKE = security association to have failed and it

>     discards all state = associated with the IKE_SA and any CHILD_SAs

>     negotiated using that = IKE_SA.

> 

>     {{ Clarif-2.3 }} = Retransmissions of the IKE_SA_INIT request require

>     some special = handling.  When a responder receives an IKE_SA_INIT

>     request, it has to = determine whether the packet is retransmission

>     belonging to an existing = 'half-open' IKE_SA (in which case the

>     responder retransmits = the same response), or a new request (in which

>     case the responder = creates a new IKE_SA and sends a fresh response),

>     or it belongs to an = existing IKE_SA where the IKE_AUTH request has

>     been already received = (in which case the responder ignores it).

 

Tero:

There is also the case of the invalid KE and cookie = notifies, i.e. we

need to add comment about those = too:

 

    ...  or it belongs to an = existing IKE_SA where the IKE_AUTH request has

    been already received (in which = case the responder ignores it), or

    it is INVALID_KE_PAYLOAD or COOKIE = notify responses to the

    IKE_SA_INIT = request.

 

Paul: Not done. This is interesting, but should be = discussed on the list.

------=_NextPart_001_0162_01C9C78A.4173C450-- ------=_NextPart_000_0161_01C9C78A.4173C450 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5NDgxN1owIwYJKoZIhvcNAQkEMRYEFG6j607K5pxx DFZFXxU6MnxIDMRzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA iQ+fnvg6vAqk6zOsMq3ikPFCz2SlLOnjKSnbO9i13ZTYUz30LxX1v1KqW5pZExJsfu46PQWq3k7Z 1yFj7RS8CW8kB+7m3Nr9hfJA+OE2bNfFMmEoUD6COtWZWQqCteemlZWaeC5haM4gSWJk4FZRHGQ/ FBKtuAmHFEJiZmo7EkVud5cKjQmE1USgttWDjSAbo/HZMADyGuMBv+HAS45bDxqfZC0yhEN2Q3tQ 9lr6/abel19OpqcZUfJ1LIRD0BlQQ6g0bs3ESkuS6FpWQj0roSi7QQg2ufMErVJHc8hIea8RbUkw kXz1aGGsPhfPbd5LSsL3jfmHv9uNm1BuTBE9tgAAAAAAAA== ------=_NextPart_000_0161_01C9C78A.4173C450-- From yaronf@checkpoint.com Mon Apr 27 12:51:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4353A6ACA for ; Mon, 27 Apr 2009 12:51:13 -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=-0.044, 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 WtYrtVSoOBry for ; Mon, 27 Apr 2009 12:51:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7531F3A687D for ; Mon, 27 Apr 2009 12:50:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EED9B30C001; Mon, 27 Apr 2009 22:52:01 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9C7EE2CC001 for ; Mon, 27 Apr 2009 22:52:01 +0300 (IDT) X-CheckPoint: {49F608B1-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 n3RJq0qO008366 for ; Mon, 27 Apr 2009 22:52:01 +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; Mon, 27 Apr 2009 22:52:00 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:51:58 +0300 Thread-Topic: Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT Thread-Index: AcnHcZ+YaIJxATHRRr+TmvLG3gyQbQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A1@il-ex01.ad.checkpoint.com> 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_0169_01C9C78A.C4F20760" MIME-Version: 1.0 Subject: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:51:13 -0000 ------=_NextPart_000_0169_01C9C78A.C4F20760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_016A_01C9C78A.C4F20760" ------=_NextPart_001_016A_01C9C78A.C4F20760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > 2.5. Version Numbers and Forward Compatibility ... > IKEv2 adds a 'critical' flag to each payload header for further > flexibility for forward compatibility. If the critical flag is set > and the payload type is unrecognized, the message MUST be rejected > and the response to the IKE request containing that payload MUST > include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an > unsupported critical payload was included. {{ 3.10.1-1 }} In that > Notify payload, the notification data contains the one-octet payload > type. If the critical flag is not set and the payload type is > unsupported, that payload MUST be ignored. Payloads sent in IKE > response messages MUST NOT have the critical flag set. Note that the > critical flag applies only to the payload type, not the contents. If > the payload type is recognized, but the payload contains something > which is not (such as an unknown transform inside an SA payload, or > an unknown Notify Message Type inside a Notify payload), the critical > flag is ignored. Tero: What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the initial IKE_SA_INIT message, or do we forbid enhancements and modifications which might cause such error? Paul: Not done. This is interesting, but should be discussed on the list. ------=_NextPart_001_016A_01C9C78A.C4F20760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>  2.5.  Version Numbers and Forward = Compatibility

...

>     IKEv2 adds a 'critical' = flag to each payload header for further

>     flexibility for forward = compatibility.  If the critical flag is set

>     and the payload type is = unrecognized, the message MUST be rejected

>     and the response to the = IKE request containing that payload MUST

>     include a Notify payload = UNSUPPORTED_CRITICAL_PAYLOAD, indicating an

>     unsupported critical = payload was included. {{ 3.10.1-1 }} In that

>     Notify payload, the = notification data contains the one-octet payload

>     type.  If the = critical flag is not set and the payload type is

>     unsupported, that = payload MUST be ignored.  Payloads sent in IKE

>     response messages MUST = NOT have the critical flag set.  Note that the

>     critical flag applies = only to the payload type, not the contents.  If

>     the payload type is = recognized, but the payload contains something

>     which is not (such as an = unknown transform inside an SA payload, or

>     an unknown Notify = Message Type inside a Notify payload), the critical

>     flag is = ignored.

 

Tero:

 

What if such UNSUPPORTED_CRITICAL_PAYLOAD error = happens during the

initial IKE_SA_INIT message, or do we forbid = enhancements and

modifications which might cause such = error?

 

Paul: Not done. This is interesting, but should be = discussed on the list.

------=_NextPart_001_016A_01C9C78A.C4F20760-- ------=_NextPart_000_0169_01C9C78A.C4F20760 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5NTE1OFowIwYJKoZIhvcNAQkEMRYEFLNx7GzoQ7eE 8sCn8FNBp+Z4bcf7MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA iiduGlND+MFTtQngLtV9oLC+jEc5qpGfduCH/k/PGBPKASUrAo26Ee39WFXEEu9XTtAI67EaqZ9v 5xVS9f40pv8y9GPl/+uqkDaVw1V/rG/QsNZVNPQVwd9aaqzNXQDqj2TktFV+w1bI6LdLqyIE1vQj HP/MVCMyJAs5Sj8G0KguTJdx233czLrZgt/8T0QcbHzZoUt1ob4toumZXrPAP7vd3Zzvb2C5jWrV Ue/VDR2imzDB2tyLdEEIta13ggCvCl19h0u7uAJ0qHPLsJKREVi7H5mcLNuG9cq+pwUyI1qetSb2 VnU4N/qHvriikzvcDt2TQb2JZi7IntRavJdhJQAAAAAAAA== ------=_NextPart_000_0169_01C9C78A.C4F20760-- From yaronf@checkpoint.com Mon Apr 27 12:58:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6505028C167 for ; Mon, 27 Apr 2009 12:58:26 -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=-0.044, 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 5gOKiimqhvuo for ; Mon, 27 Apr 2009 12:58:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3EC2A28C166 for ; Mon, 27 Apr 2009 12:58:22 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B68FA30C001; Mon, 27 Apr 2009 22:59:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 626302CC001 for ; Mon, 27 Apr 2009 22:59:42 +0300 (IDT) X-CheckPoint: {49F60A7D-2-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 n3RJxfqO009937 for ; Mon, 27 Apr 2009 22:59:42 +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; Mon, 27 Apr 2009 22:59:41 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 22:59:38 +0300 Thread-Topic: Issue #43: Validity period of addresses obtained with config payload Thread-Index: AcnHcrHWRxodrUajS+q0/L9qYTTnaA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A2@il-ex01.ad.checkpoint.com> 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_0171_01C9C78B.D7324FB0" MIME-Version: 1.0 Subject: [IPsec] Issue #43: Validity period of addresses obtained with config payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:58:26 -0000 ------=_NextPart_000_0171_01C9C78B.D7324FB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0172_01C9C78B.D7324FB0" ------=_NextPart_001_0172_01C9C78B.D7324FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [Sec. 3.15.1:] Tero: The text 'The requested address is valid until there are no IKE_SAs between the peers.' is incorrect, it most likely should say 'The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid.' I.e. even if another IKE SA is created between the peers that does not keep the address allocated in another IKE SA alive, unless it is also allocated in that IKE SA. This is especially the case where let's say multi user hosts do per user IKE SAs and want to allocate IP addresses separately for each user. Paul: Not done. This should be discussed on the mailing list. ------=_NextPart_001_0172_01C9C78B.D7324FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Sec. 3.15.1:]

 

Tero:

 

The text 'The requested address is valid until there = are no IKE_SAs between the peers.' is incorrect, it most likely should say 'The requested address is valid as long as this IKE SA (or its rekeyed = successors) requesting the address is valid.'

 

I.e. even if another IKE SA is created between the = peers that does not keep the address allocated in another IKE SA alive, unless = it is also allocated in that IKE SA. This is especially the case where = let’s say multi user hosts do per user IKE SAs and want to allocate IP addresses = separately for each user.

 

Paul: Not done. This should be discussed on the = mailing list.

------=_NextPart_001_0172_01C9C78B.D7324FB0-- ------=_NextPart_000_0171_01C9C78B.D7324FB0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzE5NTkzOFowIwYJKoZIhvcNAQkEMRYEFJO+ppSY/rtP 7Jcn6+DHH7uhQPrbMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA P20i4pygHtI32CtxpVKLR92K2XIwjyrPPP4rWl3aYLMCysIljgqidVDOmpOB380/fbwkWBRLGnSA UMJBYsRAjpZFOUzTdoq8yEewM0HJWfxqQCLoNgYTbm4hzhYyDHMzHdaPvFC1hXPytBxdH62ghazS ssnSm98VsPi6v+LYix9c8VWRVABttjRxxyTMmF3Pq7iJDDcQ2Q9Q0ICehcwbjPu/6sMOV1D17Tsl w4PLDkNf5Kp7HDArlSSRTgWdFaROijkkhieJTn619NJ2LCIzA2HY3n8OJyvoFsfj64QkMWLE3y4C NkzU5wvyQHlFwe7zL8xofvMnvlrWxxMht2k41gAAAAAAAA== ------=_NextPart_000_0171_01C9C78B.D7324FB0-- From yaronf@checkpoint.com Mon Apr 27 13:08:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E4B3A6C0B for ; Mon, 27 Apr 2009 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 FIG0oa3CI1Kc for ; Mon, 27 Apr 2009 13:08:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5F0A73A6BC1 for ; Mon, 27 Apr 2009 13:08:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C829B30C001; Mon, 27 Apr 2009 23:09:36 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7D6E12CC001 for ; Mon, 27 Apr 2009 23:09:36 +0300 (IDT) X-CheckPoint: {49F60CCF-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 n3RK9ZqO012064 for ; Mon, 27 Apr 2009 23:09:36 +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; Mon, 27 Apr 2009 23:09:35 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 23:09:33 +0300 Thread-Topic: Issue #54: PFKEY: categorization Thread-Index: AcnHdBScCBKs2YLiSwiymf2JATvChg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A3@il-ex01.ad.checkpoint.com> 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_0179_01C9C78D.39EEB070" MIME-Version: 1.0 Subject: [IPsec] Issue #54: PFKEY: categorization X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:08:17 -0000 ------=_NextPart_000_0179_01C9C78D.39EEB070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_017A_01C9C78D.39EEB070" ------=_NextPart_001_017A_01C9C78D.39EEB070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol. Paul: Not done, for the list. ------=_NextPart_001_017A_01C9C78D.39EEB070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

 

2.9: I believe it is more appropriate to describe = PFKEY as an API, rather than protocol.

 

Paul: Not done, for the = list.

------=_NextPart_001_017A_01C9C78D.39EEB070-- ------=_NextPart_000_0179_01C9C78D.39EEB070 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzIwMDkzM1owIwYJKoZIhvcNAQkEMRYEFCJq9JyZaVV7 dKjoyHhG60yck/DWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA VN4ihlQMJ2+GE+do/JBAR3tpnVfhuljC2gmnz5frj3q+Y15UaHu2+CS7H7HnyDDYqfzaVlnB+mfc XJn3+i5h/JoialwiMlNXP1wEe2UL/J2x9XfQ5bDN8ggWjcLjkCTLZfEco4S4vGjI0oe3/6d996KI vzrLHYAEI9zvFtJsXEnqIqF9pRPoAVUv0tJmH9SD2yqBVp5JHNaU0jkXSEzi13QHGWHAbvh8pG9v y6X6XgHfxf0eatgUXVohripbuOKcSzTxne8RQ5jKGCAMJ5FbOApJsGcBwb/ZfSq1hLZQWxmeNtJz ZqyoUMFCYYuawvG+db1b1XlOu00nNR9rSYz/fgAAAAAAAA== ------=_NextPart_000_0179_01C9C78D.39EEB070-- From yaronf@checkpoint.com Mon Apr 27 13:36:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF2D3A69C6 for ; Mon, 27 Apr 2009 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 kww9ixXuBVvK for ; Mon, 27 Apr 2009 13:36:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 920433A6C2C for ; Mon, 27 Apr 2009 13:36:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6243530C002; Mon, 27 Apr 2009 23:37:49 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 299CB2CC001 for ; Mon, 27 Apr 2009 23:37:49 +0300 (IDT) X-CheckPoint: {49F6136C-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 n3RKblqP018162 for ; Mon, 27 Apr 2009 23:37:48 +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; Mon, 27 Apr 2009 23:37:47 +0300 From: Yaron Sheffer To: IPsecme WG Date: Mon, 27 Apr 2009 23:37:47 +0300 Thread-Topic: Issue #79: Remove CP from Create_Child_SA ? Thread-Index: AcnHdrzJLP+TAWQzTOSLVS7DHzjh2w== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A6@il-ex01.ad.checkpoint.com> 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_0181_01C9C78F.E2258410" MIME-Version: 1.0 Subject: [IPsec] Issue #79: Remove CP from Create_Child_SA ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:36:31 -0000 ------=_NextPart_000_0181_01C9C78F.E2258410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0182_01C9C78F.E2258410" ------=_NextPart_001_0182_01C9C78F.E2258410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that "request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload." IMO the normal way of doing things is in this message 3, so rather than a parenthetical remark, it's really the only one anyone uses. I don't think it makes sense to assign a different IP address for each SA, and I don't think anyone actually intended for this to be implied. In RFC 4306 , section 3.15, one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client needs to renew the address with the gateway (probably renew the lease with a DHCP server). With such an attribute, it made sense for the client to renew the address along with rekeying some CHILD_SA. In the bis document, we've deprecated this attribute, and it is now marked as "RESERVED". Since we've done that, I suggest we remove the CP payload from the Create Child SA exchange in appendix A, and reword section 2.19 to reflect that requesting an IP address is only acceptable during IKE_AUTH. ------=_NextPart_001_0182_01C9C78F.E2258410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yoav:

Patricia = noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that "request for such a temporary address can be included in any = request to create a CHILD_SA (including the implicit request in message 3) by = including a CP payload."

IMO the normal way of doing things is in this message 3, so rather than a = parenthetical remark, it's really the only one anyone uses. I don't think it makes = sense to assign a different IP address for each SA, and I don't think anyone = actually intended for this to be implied.

In RFC 4306, section 3.15, = one of the attributes that can be sent in the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the = client needs to renew the address with the gateway (probably renew the lease = with a DHCP server). With such an attribute, it made sense for the client to = renew the address along with rekeying some CHILD_SA.

In the bis document, we've deprecated this attribute, and it is now marked as "RESERVED". Since we've done that, I suggest we remove the CP = payload from the Create Child SA exchange in appendix A, and reword section 2.19 = to reflect that requesting an IP address is only acceptable during = IKE_AUTH.

 

------=_NextPart_001_0182_01C9C78F.E2258410-- ------=_NextPart_000_0181_01C9C78F.E2258410 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQyNzIwMjgzNFowIwYJKoZIhvcNAQkEMRYEFEBZTE+AEkg6 QWzf2O6e+QzXyOImMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Yn2aC5sBwHLWxgEuAoJ67wW8JZ4J3C8r1vLINIvvP1bM594264wexkZEmz+mlADYetJAWziqFwe3 MUGmIrtnLAyz6XfKfJcqLz47CNwSAjxwtYN4gZq6PENbNTcLmMchsNWbCSu5N/O9aOp/Ajx1LPB8 /dg3jYW2eudZ5AHpvLQgUvgUMpR/0s3qibO+3JN0+7HY4sqVu6kY1ro7LuZLExtJkwhZsJm/89lQ 53Ipq5LjFMcXy4qKKhe4IjAgvIJODMohpr0HCZDbL1Hprbdz84K3pjWfD8w44FY8T+LscQUwcTtc kB3k3/Sr2SomOycbi6zvAs1BU8r5vWNkKJl8QAAAAAAAAA== ------=_NextPart_000_0181_01C9C78F.E2258410-- From Pasi.Eronen@nokia.com Tue Apr 28 01:09:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35F43A67FF for ; Tue, 28 Apr 2009 01:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=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 ETcX93PWxXI2 for ; Tue, 28 Apr 2009 01:09:41 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E850E3A67EA for ; Tue, 28 Apr 2009 01:09:40 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S8AkwP027452; Tue, 28 Apr 2009 11:10:55 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:10:55 +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); Tue, 28 Apr 2009 11:10:50 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 10:10:48 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Tue, 28 Apr 2009 10:10:48 +0200 From: To: , Date: Tue, 28 Apr 2009 10:10:47 +0200 Thread-Topic: WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAlz0n0A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246D90A@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7BECA4E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7DBF0D9@il-ex01.ad.checkpoint.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: 28 Apr 2009 08:10:50.0204 (UTC) FILETIME=[D7AC81C0:01C9C7D8] X-Nokia-AV: Clean Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:09:42 -0000 1) The new versions since the previous WGLC introduced a number of additional steps (e.g. nonce payload, clarifying PAD etc.) to the redirection process, but currently these are spread over the whole document, or in some cases, partly missing (e.g. the document never says what the client should do with the nonce data in the REDIRECT notification). IMHO these should be included in the overall flow in Section 3. Proposed text: 3. IKEv2 Initial Exchange with Redirect This section describes the use of Redirect mechanism during the IKE_SA_INIT exchange. Gateway-initiated redirect and the use of redirect during IKE_AUTH exchange are explained in subsequent sections. The VPN client indicates support for the IKEv2 redirect mechanism and the willingness to be redirected by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED notification, the responder MUST NOT use the redirect mechanism specified in this document. To redirect the IKEv2 session to another VPN gateway, the VPN gateway that initially received the IKE_SA_INIT request selects another VPN gateway (how the selection is made is beyond the scope of this document), and replies with an IKE_SA_INIT response containing a REDIRECT notification message. The notification includes the address of the selected VPN gateway, and the nonce data from the Ni payload in the IKE_SA_INIT request. Note that when the IKE_SA_INIT response includes the REDIRECT notification, the exchange does not result in the creation of an IKE_SA, and the responder SPI will be zero. =20 Initiator Responder (initial VPN GW) --------- ------------------------- (IP_I:500 -> Initial_IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECT_SUPPORTED) (Initial_IP_R:500 -> IP_I:500) <-- HDR(A,0), N(REDIRECT, IP_R, nonce data) When the client receives the IKE_SA_INIT response, it MUST verify that the nonce data matches the value sent in the IKE_SA_INIT request. If the values do not match, the client MUST silently discard the response (and keep waiting for another response). This prevents certain Denial-of-Service attacks on the initiator that could be caused by an attacker injecting IKE_SA_INIT responses with REDIRECT payloads. Next, the client initiates a new IKE_SA_INIT exchange to the address included in the REDIRECT payload. The VPN client includes the IP address of the original VPN gateway that redirected the client in the REDIRECTED_FROM notification. The IKEv2 exchange then proceeds as it would have proceeded with the original VPN gateway. Initiator Responder (Selected VPN GW) --------- --------------------------- (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_FROM, Initial_IP_R) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} In particular, the client MUST use the same Peer Authorization Database (PAD) and Security Policy Database (SPD) entries as it would have used with the original gateway. Receiving a redirect notification MUST NOT result in the modification of any PAD or SPD entries. In practise, this means the new gateway either has to either use the same responder identity (IDr) as the original gateway, or the PAD entry must use wildcards (such as gw*.example.com) that match multiple responder identities. 2) As I already noted in my March 2 email, the document does not say exactly what information outside IPsec (i.e. Mobile IPv6) is being updated by the redirect, and the security implications if it. Perhaps something like this, added to the end of Section 3: When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home Agent (HA), redirecting the IKEv2 exchange to another HA is not enough; the Mobile IPv6 signalling also needs to be sent to the new HA address. The MN MAY treat the information received in the IKE_SA_INIT response in similar way as it would treat HA discovery information received from other unauthenticated (and potentially untrustworthy) sources (such as DNS lookups not protected with DNSSEC). However, if the MN has authenticated information about its Home Agent, it MUST NOT be updated based on the IKE_SA_INIT response. If the REDIRECT notification is received during the IKE_AUTH exchange (after the HA has been authenticated; see Section 6), the MN MAY pass the new address to Mobile IPv6 and treat it in similar fashion as information from the Home Agent Switch Message [RFC5142]. Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL exchanges (see Section 5) MUST NOT result in updating any Mobile IPv6 state. In such cases, the Home Agent Switch Message specified in [RFC5142] are used instead. (I haven't fully thought through all the details, so comments are welcome...) And the security considerations text needs something, too. 3) Section 6, 1st paragraph: I think this text needs to be clearer about whether an IKE_SA is created or not (current the SHOULDs etc. make this somewhat unclear). IMHO if the client will always just close the IKE_SA, it doesn't make much sense to create it in the first place? But it looks like the intent of the current text might have been that the IKE_SA *is* created... If that's the case, then the message diagram below this paragraph should also show the INFORMATIONAL exchange with Delete payload. 4) Section 6, last paragraph: > In such cases, the gateway should send the REDIRECT notification > payload in the final IKE_AUTH response message that carries the AUTH > payload and the traffic selectors. The gateway MUST NOT send and > the client MUST NOT accept a redirect in an earlier IKE_AUTH > message. This is a bit confusing, since the first sentence says "should", and in this particular case, the final IKE_AUTH response does not actually have the traffic selectors! Also, if the intent was to allow redirect in the 1st IKE_AUTH response, this text doesn't do it. Perhaps something like this? In such cases, the gateway can include the REDIRECT notification either in the first IKE_AUTH response, or the last IKE_AUTH response. The gateway MUST NOT send, and the client MUST NOT accept, the REDIRECT notification in any other IKE_AUTH response. 5) Section 9, last paragraph, is a bit confusing (even if the redirect message was always authenticated, we still wouldn't want to modify the PAD based on it), and in the wrong place (it's important part of the protocol, not just a security consideration). The proposed text for Section 3 included the essential parts, I think. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Yaron Sheffer > Sent: 16 April, 2009 10:38 > To: IPsecme WG > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 >=20 > This is a 2 week working group last call for > draft-ietf-ipsecme-ikev2-redirect-08. The target status for this > document is > Proposed Standard. This is the document's second last call, following > comments by a number of people and several document revisions. >=20 > Please send your comments to the ipsec list by April 30, 2009, as > follow-ups > to this message. >=20 > Please clearly indicate the position of any issue in the Internet > Draft, and > if possible provide alternative text. Please also indicate the nature > or > severity of the error or correction, e.g. major technical, minor > technical, > nit, so that we can quickly judge the extent of problems with the > document. >=20 > The document can be accessed here: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08. >=20 > Thanks, > Yaron From Pasi.Eronen@nokia.com Tue Apr 28 01:50:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B873A708C for ; Tue, 28 Apr 2009 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 97oVAvoMPyA8 for ; Tue, 28 Apr 2009 01:50:16 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id ACE013A7088 for ; Tue, 28 Apr 2009 01:50:16 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S8ofbN016597; Tue, 28 Apr 2009 03:51:36 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:51:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:51:23 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 28 Apr 2009 10:51:23 +0200 From: To: , Date: Tue, 28 Apr 2009 10:51:22 +0200 Thread-Topic: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies Thread-Index: AcnHcRwVjcvd2ms4ReuFk0TNMMiAmAAbO+xA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246D9A0@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A0@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A0@il-ex01.ad.checkpoint.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2009 08:51:23.0935 (UTC) FILETIME=[824A62F0:01C9C7DE] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:50:17 -0000 Yaron Sheffer wrote: >> {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require >>=A0some special handling.=A0 When a responder receives an IKE_SA_INIT >> request, it has to determine whether the packet is retransmission >> belonging to an existing 'half-open' IKE_SA (in which case the >> responder retransmits the same response), or a new request (in which >> case the responder creates a new IKE_SA and sends a fresh response), >> or it belongs to an existing IKE_SA where the IKE_AUTH request has >> been already received (in which case the responder ignores it). > > Tero: > There is also the case of the invalid KE and cookie notifies, i.e. we > need to add comment about those too: > > =A0=A0=A0 ...=A0 or it belongs to an existing IKE_SA where the IKE_AUTH r= equest=20 > has been already received (in which case the responder ignores it),=20 > or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the > =A0=A0=A0 IKE_SA_INIT request. > > Paul: Not done. This is interesting, but should be discussed on the list. The current text is about processing of IKE_SA_INIT *requests* by=20 the responder, so talking about IKE_SA_INIT responses (such as INVALID_KE_PAYLOAD) in the same sentence would be IMHO very confusing. I'd suggest we keep this paragraph as is. Best regards, Pasi From Pasi.Eronen@nokia.com Tue Apr 28 01:53:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C293A6A12 for ; Tue, 28 Apr 2009 01:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 FX89upPZWbHq for ; Tue, 28 Apr 2009 01:53:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id AC0FB3A67EB for ; Tue, 28 Apr 2009 01:53:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S8sNxn023016; Tue, 28 Apr 2009 11:54:25 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:54:17 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 11:54:17 +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); Tue, 28 Apr 2009 11:54:11 +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; Tue, 28 Apr 2009 10:54:11 +0200 From: To: , Date: Tue, 28 Apr 2009 10:54:07 +0200 Thread-Topic: Issue #54: PFKEY: categorization Thread-Index: AcnHdBScCBKs2YLiSwiymf2JATvChgAanmMA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246D9A7@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A3@il-ex01.ad.checkpoint.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: 28 Apr 2009 08:54:12.0128 (UTC) FILETIME=[E68A9A00:01C9C7DE] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #54: PFKEY: categorization X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:53:11 -0000 Yaron Sheffer wrote: > Yaron:=20 >=20 > 2.9: I believe it is more appropriate to describe PFKEY as an API, > rather than protocol. >=20 > Paul: Not done, for the list. I agree that "API" would be clearer here. Best regards, Pasi From Pasi.Eronen@nokia.com Tue Apr 28 02:06:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFCB3A6BEF for ; Tue, 28 Apr 2009 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 Dpo4plQKP0yx for ; Tue, 28 Apr 2009 02:06:09 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0CD9E3A67EB for ; Tue, 28 Apr 2009 02:06:07 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S97RX2001935; Tue, 28 Apr 2009 04:07:28 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 12:07:17 +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); Tue, 28 Apr 2009 12:07:08 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 11:06:59 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Tue, 28 Apr 2009 11:06:59 +0200 From: To: , Date: Tue, 28 Apr 2009 11:06:58 +0200 Thread-Topic: [IPsec] Issue #43: Validity period of addresses obtained with config payload Thread-Index: AcnHcrHWRxodrUajS+q0/L9qYTTnaAAbYztQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24A1F66@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A2@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A2@il-ex01.ad.checkpoint.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2009 09:07:08.0677 (UTC) FILETIME=[B5669350:01C9C7E0] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #43: Validity period of addresses obtained with config payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:06:10 -0000 Yaron Sheffer wrote: > [Sec. 3.15.1:] =A0=20 > > Tero: =A0=20 > > The text 'The requested address is valid until there are no IKE_SAs > between the peers.' is incorrect, it most likely should say 'The > requested address is valid as long as this IKE SA (or its rekeyed > successors) requesting the address is valid.' > > I.e. even if another IKE SA is created between the peers that does > not keep the address allocated in another IKE SA alive, unless it is > also allocated in that IKE SA. This is especially the case where > let's say multi user hosts do per user IKE SAs and want to allocate > IP addresses separately for each user. >=A0 > Paul: Not done. This should be discussed on the mailing list. I think Tero is right; the scope of configuration payloads is this=20 IKE SA *and* its continuations via rekeying. Best regards, Pasi From Pasi.Eronen@nokia.com Tue Apr 28 02:32:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D8B3A6A1A for ; Tue, 28 Apr 2009 02:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 jNwgdFCXlqz2 for ; Tue, 28 Apr 2009 02:32:22 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 08E753A6867 for ; Tue, 28 Apr 2009 02:32:21 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S9XYXD018440; Tue, 28 Apr 2009 12:33:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 12:33:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 12:33:38 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 11:33:37 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Tue, 28 Apr 2009 11:33:37 +0200 From: To: , Date: Tue, 28 Apr 2009 11:33:36 +0200 Thread-Topic: [IPsec] Reopening issue #12 Thread-Index: AcnHMoy2Jtf5GeyPRaWb2gMvqC6KVAAr6dDA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> In-Reply-To: <18933.41712.378159.694316@fireball.kivinen.iki.fi> 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: 28 Apr 2009 09:33:38.0295 (UTC) FILETIME=[68E30870:01C9C7E4] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Reopening issue #12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:32:23 -0000 Tero Kivinen wrote: > Paul Hoffman writes: > > It was pointed out that (a) this is a new MUST and >=20 > Yes, but it can mostly be already deducted from the requirement that > end node cannot violate its own policy, meaning it needs to delete > Child SA which are not following his policy. If that is already done, > there is no point for the new SA having narrower scope than old SA > had, and making this MUST makes it simplier for implementations (i.e. > they do not need to think what to do for the traffic which do not fit > the rekeyed SA, and we do not need to add the traffic selectors from > the packet parts). >=20 > > (b) this also > > assumes that the encryption algorithm and so on will be the same. >=20 > No it does not. I do not see any text there saying anything about > encryption algorithms. Those are negotiated as normally and again if > policy has been changed so that the original algorithms are not valid > anymore, then the child SA should have been deleted already. Hmm... narrowing and algorithm negotiation can interact. Consider the following situation: Alice's SPD: traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred) Bob's SPD: traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred) traffic on UDP ports 1500-1999 MUST use ESP w/AES The old SA (OK to both Alice and Bob): =20 UDP ports 1000-1999, AES Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this SA, proposing algorithms AES and 3DES, and traffic selectors for UDP ports 1000-1999. Bob prefers 3DES, and picks that. But now Bob cannot meet the requirement "new SA MUST NOT be narrower than the old one", because it would violate his policy. So, I think the current text in 2.9.2 *does* assume that encryption=20 algorithm negotiation behaves differently when rekeying (and IMHO this requirement is not in RFC 4306). Best regards, Pasi From Pasi.Eronen@nokia.com Tue Apr 28 02:39:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9F43A69A8 for ; Tue, 28 Apr 2009 02:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 ML0B1PxmPQGg for ; Tue, 28 Apr 2009 02:38:59 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E47043A65A5 for ; Tue, 28 Apr 2009 02:38:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3S9dwX8002763; Tue, 28 Apr 2009 12:40:12 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 12:40:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 12:39:55 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 28 Apr 2009 11:39:54 +0200 From: To: , Date: Tue, 28 Apr 2009 11:39:53 +0200 Thread-Topic: Issue #79: Remove CP from Create_Child_SA ? Thread-Index: AcnHdrzJLP+TAWQzTOSLVS7DHzjh2wAbcQnA Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24A1FD1@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A6@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A6@il-ex01.ad.checkpoint.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: 28 Apr 2009 09:39:55.0073 (UTC) FILETIME=[4976CB10:01C9C7E5] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #79: Remove CP from Create_Child_SA ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 09:39:00 -0000 Yaron Sheffer wrote: > Yoav: > > Patricia noted in a post to the IPsec mailing list (12/12/2008) that > section 2.19 says that "request for such a temporary address can be > included in any request to create a CHILD_SA (including the implicit > request in message 3) by including a CP payload." > > IMO the normal way of doing things is in this message 3, so rather > than a parenthetical remark, it's really the only one anyone uses. I > don't think it makes sense to assign a different IP address for each > SA, and I don't think anyone actually intended for this to be > implied. > > In RFC 4306, section 3.15, one of the attributes that can be sent in > the CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the > length of time before the client needs to renew the address with the > gateway (probably renew the lease with a DHCP server). With such an > attribute, it made sense for the client to renew the address along > with rekeying some CHILD_SA. > > In the bis document, we've deprecated this attribute, and it is now > marked as "RESERVED". Since we've done that, I suggest we remove the > CP payload from the Create Child SA exchange in appendix A, and > reword section 2.19 to reflect that requesting an IP address is only > acceptable during IKE_AUTH. Including a CP payload in CREATE_CHILD_SA request doesn't mean the CP applies to that particular CHILD_SA (just like CP during IKE_AUTH doesn't apply to that CHILD_SA only). IMHO it's semantics should be exactly the same as first doing an INFORMATIONAL exchange with the CP, immediately followed by a CREATE_CHILD_SA exchange without the CP. So if we would remove CP from the CREATE_CHILD_SA exchange, we should also remove it from the INFORMATIONAL exhange. But we do have an example in Section 2.20 where CP is used in INFORMATIONAL exchange... But perhaps we could add text saying that many implementations will probably support INTERNAL_IP_ADDRESS only during IKE_AUTH, and are likely to refuse it in any other exchange? Best regards, Pasi From kivinen@iki.fi Tue Apr 28 07:34:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCB43A68D2 for ; Tue, 28 Apr 2009 07:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=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 tScONZooEuIU for ; Tue, 28 Apr 2009 07:34:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A40593A6AEF for ; Tue, 28 Apr 2009 07:34:42 -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 n3SEZwtI021822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Apr 2009 17:35:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3SEZwSq018504; Tue, 28 Apr 2009 17:35:58 +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: <18935.5198.554334.837387@fireball.kivinen.iki.fi> Date: Tue, 28 Apr 2009 17:35:58 +0300 From: Tero Kivinen To: IPsecme WG X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 77 min X-Total-Time: 58 min Subject: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:34:44 -0000 Section 3 says: The gateway MUST include the nonce data from the Ni payload sent by the initiator in the REDIRECT payload. This prevents certain Denial- but the figures showing how redirect is done does not include Ni data in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is bit misleading to use IP_R in the payload, perhaps New_GW_ID would be better. I.e. it would be better to write the reply as: (Initial_IP_R:500 -> IP_I:500) <-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data) Similar change is also needed in later sections too. --- In section 5 it should be: <-- HDR, SK {N(REDIRECT, New_GW_ID,)} (also changed the N[] to N() as is used normally). --- In section 6 it should be: (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N(REDIRECT, New_GW_ID,)} (Again changed the N[] to N()). This section does not say whether the Ni is included in the response, but I assume it is omitted as there is no need for it. This section should make it clear whether it is included or omitted. --- In section 6 the text: In such cases, the gateway should send the REDIRECT notification payload in the final IKE_AUTH response message that carries the AUTH payload and the traffic selectors. The gateway MUST NOT send and the client MUST NOT accept a redirect in an earlier IKE_AUTH message. is bit confusing. First it says the gateway (lowercase) should send REDIRECT in final IKE_AUTH response that carries the AUTH payload and traffic selectors. Then it says that gateway MUST NOT send redirect in earlier messages. Firstly the final IKE_AUTH response willnot include the traffic selectors, as they are omitted if client is redirected. Thus it is misleading to say "that carries the AUTH payload and traffic selectors". Secondly, it is not clear whether the "In such cases" only refers to the cases wher gateway decides to do something (interact with AAA server/ use external authentication server), or in all cases where EAP or multiple authentication is used. If it is in all cases where EAP or multiple authentication is used, then that means gateway cannot redirect in first IKE_AUTH (which is fine for me, but I am not sure if that was meant). If it is only when gateway needs AAA/external authentication server, then how can client enforce the "MUST NOT accept redirect in an earlier IKE_AUTH message", if it does not know whether gateway needs to consult external authentication server or AAA server... In general the text is so confusing that I am not sure what is meant. One easy way to solve this problem is to say things clearly, i.e. either add one of the following texts: If multiple IKE_AUTH exchanges are used the REDIRECT notification payload MUST be in the IKE_AUTH response from gateway to the client, which also includes the gateways AUTH payload. With EAP, there is two possible places (first IKE_AUTH and last IKE_AUTH). With multiple authentication support there are AUTH payload after each authentication finished, thus server can redirect after each authentication step is finished. REDIRECT notification MUST NOT be sent or accepted in any other messages than those having AUTH payload. or If multiple IKE_AUTH exchanges are used the REDIRECT notification payload MUST be in the final IKE_AUTH response from the gateway to the client, i.e the one that contains the AUTH payload, and that would also contain the Child SA SA payload and traffic selectors, if connection would not have redirected. REDIRECT notification MUST NOT be sent or accepted in any of the earlier IKE_AUTH messages. --- In section 7.2 the first paragraph says that "The message includes the new responder's IP address.", but this payload can also include FQDN, I think it should be changed to "The message includes the new responder's IP address or DNS name.". --- In section 7.2. the GW Identity Type should be made to be IANA allocated registry. We have already had all kind of problems when we have such registries which are not clearly defined, and then someone wanted to add entries to there. It would also be good to explicitly say that IPv4 address are encoded as 4 octects, and IPv6 addresses are encoded as 16 octets, and that the FQDN of the new VPN gateway is encoded as dns name without any terminators (e.g., NUL, CR, etc). Perhaps it would be good to cut & paste the similar parts from the section 3.5 of the rfc4306. --- In section 7.3 it is not clear whether this registry used for GW Ident Type is same as in section 7.2 or not. As it does not have same values, I assume it is supposed to be separate registry. In that case it would be better to use some different name for it, so there is no confusion which registry is used (for eaxmple "Original GW Ident Type"). As a separate registry it also need to be set up to be IANA registry. --- The example in section 9 about the wildcard is not good, as it is not mandatory to support such wildcard format. The section 4.4.3.1 or RFC4301 uses partial DNS names, thus it requires that omitted parts are separate dns labels (text from RFC4301): o DNS name (specific or partial) o Distinguished Name (complete or sub-tree constrained) o RFC 822 email address (complete or partially qualified) o IPv4 address (range) o IPv6 address (range) o Key ID (exact match only) The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string ".example.com" could be used to match any DNS name ending in these two domain name components. This means that the text should not use "GW*.example.com" as an example, but use ".sgw.example.com" instead, as that conforms to mimimal requirements of the RFC4301. --- Section 10 says there is "four new IKEv2 Notification Message types", but there is only 3... --- Section 10 also needs to create those two "GW Ident Type" and "Original GW Ident Type" registries, and specify what allocation rules are required for them. I.e reserver numbers 4/3 - 240 to IANA, allocate numbers 241-255 to private use, and add text saying that "Changes and additions to any of those registries are by expert review.". -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 29 03:51:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EECB28C21A for ; Wed, 29 Apr 2009 03:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 UEONRMWjc7hT for ; Wed, 29 Apr 2009 03:51:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE3E28C1DC for ; Wed, 29 Apr 2009 03:50:59 -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 n3TAqGR7004607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 13:52:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3TAqFbr004645; Wed, 29 Apr 2009 13:52:15 +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: <18936.12639.255496.137684@fireball.kivinen.iki.fi> Date: Wed, 29 Apr 2009 13:52:15 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A6@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: IPsecme WG Subject: [IPsec] Issue #79: Remove CP from Create_Child_SA ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 10:51:16 -0000 Yaron Sheffer writes: > Patricia noted in a post to the IPsec mailing list (12/12/2008) that section > 2.19 says that "request for such a temporary address can be included in any > request to create a CHILD_SA (including the implicit request in message 3) > by including a CP payload." > > IMO the normal way of doing things is in this message 3, so rather than a > parenthetical remark, it's really the only one anyone uses. I don't think it > makes sense to assign a different IP address for each SA, and I don't think > anyone actually intended for this to be implied. > > In RFC 4306 , section 3.15, one of the > attributes that can be sent in the CP payload is the > INTERNAL_ADDRESS_EXPIRY. That would be the length of time before the client > needs to renew the address with the gateway (probably renew the lease with a > DHCP server). With such an attribute, it made sense for the client to renew > the address along with rekeying some CHILD_SA. > > In the bis document, we've deprecated this attribute, and it is now marked > as "RESERVED". Since we've done that, I suggest we remove the CP payload > from the Create Child SA exchange in appendix A, and reword section 2.19 to > reflect that requesting an IP address is only acceptable during IKE_AUTH. I agree in the common case of doing configuration payloads only during IKE_AUTH, but I do not think it is good idea to restrict it in such way. In future we might make extensions (for example the ipv6-config or similar) where we might want to do configuration payloads as separate informational exchanges, or as part of another create child sa exchange. I am in favor of removing the CP from the appendix C.4 from create child SA, but for example section 2.20 has example showing how configuration payload can be used in separate INFORMATIONAL exchange. The section 4 already mentions that minimal implementations are required to send CP request in message 3, and servers understanding it must return CP payload (it does not explictly mention it must be in same message as where the other child SA specific payloads (SA, TSi, TSr) are). There is no requirement anywhere for implementations to process Configuration payloads in any locations, but I do not think we should forbid them in other locations. In other locations they might be simply ignored if the other end does not support them in those locations. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 29 03:58:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C923A6E88 for ; Wed, 29 Apr 2009 03:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 c3btMMFgiDhU for ; Wed, 29 Apr 2009 03:58:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 93B163A7116 for ; Wed, 29 Apr 2009 03:58:25 -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 n3TAxifK004398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 13:59:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3TAxiba004321; Wed, 29 Apr 2009 13:59:44 +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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <18936.13088.137787.265346@fireball.kivinen.iki.fi> Date: Wed, 29 Apr 2009 13:59:44 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F246D9A0@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A0@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F246D9A0@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 10:58:26 -0000 Pasi.Eronen@nokia.com writes: > Yaron Sheffer wrote: >=20 > >> {{ Clarif-2.3 }} Retransmissions of the IKE=5FSA=5FINIT request re= quire > >>=A0some special handling.=A0 When a responder receives an IKE=5FSA=5F= INIT > >> request, it has to determine whether the packet is retransmission > >> belonging to an existing 'half-open' IKE=5FSA (in which case the > >> responder retransmits the same response), or a new request (in whi= ch > >> case the responder creates a new IKE=5FSA and sends a fresh respon= se), > >> or it belongs to an existing IKE=5FSA where the IKE=5FAUTH request= has > >> been already received (in which case the responder ignores it). > > > > Tero: > > There is also the case of the invalid KE and cookie notifies, i.e. = we > > need to add comment about those too: > > > > =A0=A0=A0 ...=A0 or it belongs to an existing IKE=5FSA where the IK= E=5FAUTH request=20 > > has been already received (in which case the responder ignores = it),=20 > > or it is INVALID=5FKE=5FPAYLOAD or COOKIE notify responses to t= he > > =A0=A0=A0 IKE=5FSA=5FINIT request. > > > > Paul: Not done. This is interesting, but should be discussed on the= list. >=20 > The current text is about processing of IKE=5FSA=5FINIT *requests* by= =20 > the responder, so talking about IKE=5FSA=5FINIT responses (such as > INVALID=5FKE=5FPAYLOAD) in the same sentence would be IMHO very confu= sing. Hmm... true, missed that it was only talking from the responders side, not from the initiator side.=20 > I'd suggest we keep this paragraph as is. I agree on that now when I reread the section.=20 --=20 kivinen@iki.fi From kivinen@iki.fi Wed Apr 29 04:17:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38FF03A711B for ; Wed, 29 Apr 2009 04:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 7oQsDjflaada for ; Wed, 29 Apr 2009 04:17:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 032573A6946 for ; Wed, 29 Apr 2009 04:17:01 -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 n3TBIMP1004417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 14:18:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3TBILJw002046; Wed, 29 Apr 2009 14:18:21 +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: <18936.14205.619538.390538@fireball.kivinen.iki.fi> Date: Wed, 29 Apr 2009 14:18:21 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 16 min Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Reopening issue #12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 11:17:19 -0000 Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > Paul Hoffman writes: > > > It was pointed out that (a) this is a new MUST and > > > > Yes, but it can mostly be already deducted from the requirement that > > end node cannot violate its own policy, meaning it needs to delete > > Child SA which are not following his policy. If that is already done, > > there is no point for the new SA having narrower scope than old SA > > had, and making this MUST makes it simplier for implementations (i.e. > > they do not need to think what to do for the traffic which do not fit > > the rekeyed SA, and we do not need to add the traffic selectors from > > the packet parts). > > > > > (b) this also > > > assumes that the encryption algorithm and so on will be the same. > > > > No it does not. I do not see any text there saying anything about > > encryption algorithms. Those are negotiated as normally and again if > > policy has been changed so that the original algorithms are not valid > > anymore, then the child SA should have been deleted already. > > Hmm... narrowing and algorithm negotiation can interact. Consider > the following situation: > > Alice's SPD: > traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred) > > Bob's SPD: > traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred) > traffic on UDP ports 1500-1999 MUST use ESP w/AES > > The old SA (OK to both Alice and Bob): > UDP ports 1000-1999, AES > > Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this > SA, proposing algorithms AES and 3DES, and traffic selectors for UDP > ports 1000-1999. Bob prefers 3DES, and picks that. Bob cannot pick that one, as it would be against his own policy for the port 1500-1999 range, thus he MUST select AES, which is acceptable for the whole range. > But now Bob cannot meet the requirement "new SA MUST NOT be narrower > than the old one", because it would violate his policy. This depends which happens first, algorithm selection or narrowing. In most cases the first thing happens that traffic selectors are used to find suitable policy entry from SPD and then algorithms and traffic selectors are selected based on that. In most case I would not expect Bob to create the old SA that way at all, as it would require it to combine two SPD rules together when accepting such entry. As the SPD entries are ordered list that would mean it was combining two entries which had different locations in the list, and I am not sure if combining two SPD entries when creating SA is actually allowed by the RFC4301. In general I do not expect implementations ever to do that, and if they happen to do that then they should also have code that understands the rekeying requirements, meaning they must select those same SPD entries for the rekeying and also use the policy restrictions from them to select algorithms for the rekey. Meaning that, in your example the Bob can still pick same SA traffic selectors (UDP ports 1000-1999) and select algorithm which is acceptable for him (AES). He cannot select 3DES even when that is his preferred algorithm for one part of the range. > So, I think the current text in 2.9.2 *does* assume that encryption > algorithm negotiation behaves differently when rekeying (and IMHO > this requirement is not in RFC 4306). I do not find anything from 2.9.2 which would indicate that it assumes algorithms to stay same (which was the actual question of b). It does require algorithm selection to work so it does result in algorithm that is acceptable for the whole old SA. Note, that when the Bob initially created the SA he had exactly same algorithm selection problem, and that algorithm selection problem is because he allowed SA to use multiple SPD entries. If Bob makes sure that SA is derived from exactly one SPD entry, then this problem cannot arise. In that case Bob would also delete the SA when it was reconfigured to have that new policy which splitted old SPD entry to 2 new SPD entries, as the SA would then refer to two SPD entries. -- kivinen@iki.fi From vidyan@qualcomm.com Wed Apr 29 13:18:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62843A6C5F for ; Wed, 29 Apr 2009 13:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, 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 GbxZQU6O2tlU for ; Wed, 29 Apr 2009 13:18:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 539FB3A6AAE for ; Wed, 29 Apr 2009 13:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1241036411; x=1272572411; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Tero=20Kivinen=20|CC:=20"Dondeti,=20La kshminath"=20,=0D=0A=20=20=20=20 =20=20=20=20IPsecme=20WG=0D=0A=09,=20Paul =20Hoffman=20|Date:=20Wed,=2029=20 Apr=202009=2013:20:07=20-0700|Subject:=20RE:=20[IPsec]=20 Issue=20#98:=201=20or=20two=20round=20trips=20for=20resum ption|Thread-Topic:=20[IPsec]=20Issue=20#98:=201=20or=20t wo=20round=20trips=20for=20resumption|Thread-Index:=20Acn HL6Bn1A8OVdmZSXWVEk4hCfEFswB1Qotg|Message-ID:=20|References:=20 =0D=0A=09=0D=0A=09<7F9A6D26EB51614FBF9F81C0D A4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com>=0D=0A=09=0D=0A=09<18925.45980.896489.919446@fireball.kiv inen.iki.fi>=0D=0A=09<49EEBDD3.2070706@qualcomm.com>=0D =0A=09<18926.62554.713509.846039@fireball.kivinen.iki.fi> =0D=0A=09<49F011FE.4070206@qualcomm.com>=0D=0A=09<18928.1 7060.932652.535677@fireball.kivinen.iki.fi>=0D=0A=09<49F0 4C9A.6080400@qualcomm.com>=0D=0A=09<18928.29165.128628.11 9901@fireball.kivinen.iki.fi>=0D=0A=09=0D=0A =20<18933.40440.788476.6666@fireball.kivinen.iki.fi> |In-Reply-To:=20<18933.40440.788476.6666@fireball.kivinen .iki.fi>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17599760"; bh=z6C76F7GzM+fBiacGCbN+VChTwYVb7iETFcuTxoRP2M=; b=S1OnBA4kAMXc5NK1Kx2I8WIUNftdbu3EiOXdTdP1u4dKQU6r4dwxK+vo Jvw+rnEnBw6Y1btiQA6qR2JbSlOzjvwCiNgR2SBXxHwpNysCn36a5aJQs X7j5KtdTI4r43fFjTTZBfWwHt0BnWO5HKuID9NmaDNGtDMDql7cMO8zlN Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17599760" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 13:20:10 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TKKA0f027807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 13:20:10 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3TKK99v032576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Apr 2009 13:20:10 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Apr 2009 13:20:09 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 29 Apr 2009 13:20:08 -0700 From: "Narayanan, Vidya" To: Tero Kivinen Date: Wed, 29 Apr 2009 13:20:07 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnHL6Bn1A8OVdmZSXWVEk4hCfEFswB1Qotg Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> <18933.40440.788476.6666@fireball.kivinen.iki.fi> In-Reply-To: <18933.40440.788476.6666@fireball.kivinen.iki.fi> 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: IPsecme WG , "Dondeti, Lakshminath" , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 20:18:49 -0000 >=20 > It is impossible for IETF to think about those other standard bodies, > as we do not know what they plan to do. I have several times tried to > get people to explain me the use case for which this protocol has been > aimed for, so I could think whether some specific attack or > optimization is suitable or not, but as only reply I have received is, > that it is outside the scope of this discussion, then there is really > no point of blaming people for making decisions for other standard > bodies. What else can we do? >=20 > Nobody has still explained me why the 1 RT protocol is required for > those other standard bodies, and why should the security of this > protocol be weaker because of the requirements from those other > unknown standard bodies. >=20 The requirement is quite simple and you just seem to ignore it or provide u= nacceptable alternatives. The handoff latency must be good enough to suppo= rt VoIP like applications and the handoff may imply needing an IPsec sessio= n between the mobile and a network entity (be it a VPN or for MIP6 channel = security). You claim that in such scenarios, IPsec should be used all the = time, even on the interfaces that don't require it for security purposes - = so, even if the device is not running MIP6 until it moves to the new interf= ace, it now needs to establish an IPsec session. However, this is not acce= ptable for various reasons (including that operators are not interested in = maintaining IPsec sessions for all devices just in case it roams at some po= int). Also, designing for a fixed set of interfaces is a problem - it may = not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G infras= tructure and 3G Femto; it could be 3G infrastructure and 3G multi-hop, etc.= In many of these cases, handoffs don't happen using a single radio operat= ing in multi-mode. =20 > > Also, mobility may need to be handled by MIP6 and we know that it > > doesn't co-exist with MOBIKE. >=20 > That is news for me. One of the reasons MOBIKE was created was to > allow it to be used as building block for Mobile IP. So why does not > MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could > be used by Mobile IP, and there were Mobile IP people taking part in > the specification process back then. >=20 > So what is the exact problem there? >=20 The fundamental issue is that MIP6, using the K bit, allows the IP address = on the IKE SA to change, thereby accomplishing the MOBIKE functionality and= also conflicting with it if it ran together. Please read the thread on "M= OBIKE and MIP6" on the MIP6 mailing list from back in 2006 if you are inter= ested in more details. The conclusion was that a scenario of using MOBIKE = and MIP6 between the same two endpoints must be avoided. Also note that as= I mentioned above, there are scenarios where MIP6 doesn't kick off until a= handoff occurs. =20 > I am thinking it might not be worth of standardizing the resumption at > all, if we for that again hear 3 years after we finished the work that > it cannot be used because of some unspecified reason. >=20 Well, the current approach for designing it for known air interfaces that s= ome of us may be familiar with and some models where multiple interfaces ne= ed to simultaneously be active is certainly not going to help it. We might= as well say that this is not meant for addressing the mobility use cases. = =20 =20 > Most of the DoS attackers are not wanting to get something meaningful > in return. I still think we need to design protocols so they are > secure against such attacks. >=20 I'm really surprised by this. A good threat analysis should determine the = likelihood and impact of an attack and likelihood largely depends on the at= tacker's incentive. If the incentive doesn't exist or is not meaningful, t= he likelihood is generally low, causing the attack to be of low importance.= NIST's Risk Management Guide goes through a good description of how to do= a threat analysis and is useful. Simply protecting against attacks that w= e can all dream up, regardless of the threat model or motivations is not us= eful. =20 Vidya From vidyan@qualcomm.com Wed Apr 29 18:15:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DABBF3A6D8E for ; Wed, 29 Apr 2009 18:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.176 X-Spam-Level: X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, 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 1JlvHrP07lfS for ; Wed, 29 Apr 2009 18:15:39 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 374F93A6C90 for ; Wed, 29 Apr 2009 18:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1241054222; x=1272590222; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"Narayanan,=20Vidya"=20,=20Tero =20Kivinen=20|CC:=20IPsecme=20WG=20,=0D=0A=20=20=20=20=20=20=20=20"Dondeti,=20Laks hminath"=0D=0A=09,=0D=0A=20=20=20 =20=20=20=20=20Paul=20Hoffman=20 |Date:=20Wed,=2029=20Apr=202009=2018:16:43=20-0700 |Subject:=20RE:=20[IPsec]=20Issue=20#98:=201=20or=20two =20round=20trips=20for=20resumption|Thread-Topic:=20[IPse c]=20Issue=20#98:=201=20or=20two=20round=20trips=20for=20 resumption|Thread-Index:=20AcnHL6Bn1A8OVdmZSXWVEk4hCfEFsw B1QotgAAsmrQA=3D|Message-ID:=20|References: =20=0D=0A=09=0D=0A=09<7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5 B@il-ex01.ad.checkpoint.com>=0D=0A=09=0D=0A =09<18925.45980.896489.919446@fireball.kivinen.iki.fi>=0D =0A=09<49EEBDD3.2070706@qualcomm.com>=0D=0A=09<18926.6255 4.713509.846039@fireball.kivinen.iki.fi>=0D=0A=09<49F011F E.4070206@qualcomm.com>=0D=0A=09<18928.17060.932652.53567 7@fireball.kivinen.iki.fi>=0D=0A=09<49F04C9A.6080400@qual comm.com>=0D=0A=09<18928.29165.128628.119901@fireball.kiv inen.iki.fi>=0D=0A=09=0D=0A=09<18933.40440.7 88476.6666@fireball.kivinen.iki.fi>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5600"=3B=20a=3D"17610639"; bh=fzYZU6EYKmMS0WdiaCnzNOh5Neb8rjOTTgHkzJyauPQ=; b=WbOXDxzByFeOd6zTgteLLPu7Ue042lVZoQ1IEEt2Q5jhh9dr1oP/6gdN jnoYXBqJ6+amFuMQnjKm7ZJhQhuoabr8syC5dGwZb6ExbFAKCdLigXTx4 wBXYwwXUudCCDtIkAr2Qcl8ePn8RnMsoIWfsy37yGHY5sCLWRxaGGHI0X c=; X-IronPort-AV: E=McAfee;i="5300,2777,5600"; a="17610639" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2009 18:16:58 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U1Gwi8013330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Apr 2009 18:16:58 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n3U1GjGJ013087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Apr 2009 18:16:55 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 29 Apr 2009 18:16:45 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 29 Apr 2009 18:16:45 -0700 From: "Narayanan, Vidya" To: "Narayanan, Vidya" , Tero Kivinen Date: Wed, 29 Apr 2009 18:16:43 -0700 Thread-Topic: [IPsec] Issue #98: 1 or two round trips for resumption Thread-Index: AcnHL6Bn1A8OVdmZSXWVEk4hCfEFswB1QotgAAsmrQA= Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> <18933.40440.788476.6666@fireball.kivinen.iki.fi> 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: IPsecme WG , "Dondeti, Lakshminath" , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 01:15:41 -0000 One correction below.=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Narayanan, Vidya > Sent: Wednesday, April 29, 2009 1:20 PM > To: Tero Kivinen > Cc: IPsecme WG; Dondeti, Lakshminath; Paul Hoffman > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption >=20 > > > > It is impossible for IETF to think about those other standard bodies, > > as we do not know what they plan to do. I have several times tried to > > get people to explain me the use case for which this protocol has > been > > aimed for, so I could think whether some specific attack or > > optimization is suitable or not, but as only reply I have received > is, > > that it is outside the scope of this discussion, then there is really > > no point of blaming people for making decisions for other standard > > bodies. What else can we do? > > > > Nobody has still explained me why the 1 RT protocol is required for > > those other standard bodies, and why should the security of this > > protocol be weaker because of the requirements from those other > > unknown standard bodies. > > >=20 > The requirement is quite simple and you just seem to ignore it or > provide unacceptable alternatives. The handoff latency must be good > enough to support VoIP like applications and the handoff may imply > needing an IPsec session between the mobile and a network entity (be it > a VPN or for MIP6 channel security). You claim that in such scenarios, > IPsec should be used all the time, even on the interfaces that don't > require it for security purposes - so, even if the device is not > running MIP6 until it moves to the new interface, it now needs to > establish an IPsec session. However, this is not acceptable for > various reasons (including that operators are not interested in > maintaining IPsec sessions for all devices just in case it roams at > some point). Also, designing for a fixed set of interfaces is a > problem - it may not always be 3G and WiFi - it could be 3G and WiMAX; > it could be 3G infrastructure and 3G Femto; it could be 3G > infrastructure and 3G multi-hop, etc. In many of th > ese cases, handoffs don't happen using a single radio operating in > multi-mode. >=20 s/handoffs don't happen/handoffs happen > > > Also, mobility may need to be handled by MIP6 and we know that it > > > doesn't co-exist with MOBIKE. > > > > That is news for me. One of the reasons MOBIKE was created was to > > allow it to be used as building block for Mobile IP. So why does not > > MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it > could > > be used by Mobile IP, and there were Mobile IP people taking part in > > the specification process back then. > > > > So what is the exact problem there? > > >=20 > The fundamental issue is that MIP6, using the K bit, allows the IP > address on the IKE SA to change, thereby accomplishing the MOBIKE > functionality and also conflicting with it if it ran together. Please > read the thread on "MOBIKE and MIP6" on the MIP6 mailing list from back > in 2006 if you are interested in more details. The conclusion was that > a scenario of using MOBIKE and MIP6 between the same two endpoints must > be avoided. Also note that as I mentioned above, there are scenarios > where MIP6 doesn't kick off until a handoff occurs. >=20 > > I am thinking it might not be worth of standardizing the resumption > at > > all, if we for that again hear 3 years after we finished the work > that > > it cannot be used because of some unspecified reason. > > >=20 > Well, the current approach for designing it for known air interfaces > that some of us may be familiar with and some models where multiple > interfaces need to simultaneously be active is certainly not going to > help it. We might as well say that this is not meant for addressing > the mobility use cases. >=20 > >=20 > > Most of the DoS attackers are not wanting to get something meaningful > > in return. I still think we need to design protocols so they are > > secure against such attacks. > > >=20 > I'm really surprised by this. A good threat analysis should determine > the likelihood and impact of an attack and likelihood largely depends > on the attacker's incentive. If the incentive doesn't exist or is not > meaningful, the likelihood is generally low, causing the attack to be > of low importance. NIST's Risk Management Guide goes through a good > description of how to do a threat analysis and is useful. Simply > protecting against attacks that we can all dream up, regardless of the > threat model or motivations is not useful. >=20 > Vidya > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Apr 29 23:54:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06EE3A6F2D for ; Wed, 29 Apr 2009 23:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 g5XmKfL24Etc for ; Wed, 29 Apr 2009 23:54:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 47C8D3A6F38 for ; Wed, 29 Apr 2009 23:54:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0C3BD30C001; Thu, 30 Apr 2009 09:55:41 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BEE752CC001 for ; Thu, 30 Apr 2009 09:55:40 +0300 (IDT) X-CheckPoint: {49F9470F-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 n3U6teqO010845 for ; Thu, 30 Apr 2009 09:55:40 +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; Thu, 30 Apr 2009 09:55:39 +0300 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 30 Apr 2009 09:58:03 +0300 Thread-Topic: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies being discussed Thread-Index: AcnHbuU5YgBif/TrQzKH597dqnlBoAB8hj8g Message-ID: <9FB7C7CE79B84449B52622B506C780361338597CD6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC559D@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC559D@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361338597CD6ilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies being discussed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:54:20 -0000 --_000_9FB7C7CE79B84449B52622B506C780361338597CD6ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tero ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Monday, April 27, 2009 10:32 PM To: IPsecme WG Subject: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies = being discussed > {{ Clarif-7.7 }} There are two cases when such a one-way notification > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > sent outside of an IKE_SA. Note that such notifications are > explicitly not Informational exchanges; these are one-way messages > that must not be responded to. In case of INVALID_IKE_SPI, the > message sent is a response message, and thus it is sent to the IP > address and port from whence it came with the same IKE SPIs and the > Message ID copied. In case of INVALID_SPI, however, there are no IKE > SPI values that would be meaningful to the recipient of such a > notification. Using zero values or random values are both > acceptable. Tero: In a sense INVALID_MAJOR_VERSION is also this kind of notification which is sent outside of an IKE_SA, although it is sent as a response to the incoming IKE SA creation. Perhaps we should note this fact here? Paul: Not done. This is interesting, but should be discussed on the list. =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361338597CD6ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Tero

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron=20 Sheffer
Sent: Monday, April 27, 2009 10:32 PM
To: IPs= ecme=20 WG
Subject: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to = other=20 notifies being discussed

>    = ; {{=20 Clarif-7.7 }} There are two cases when such a one-way=20 notification

>    = ; is=20 sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications=20 are

>    = ; sent=20 outside of an IKE_SA.  Note that such notifications=20 are

>    = ;=20 explicitly not Informational exchanges; these are one-way=20 messages

>    = ; that=20 must not be responded to.  In case of INVALID_IKE_SPI,=20 the

>    = ;=20 message sent is a response message, and thus it is sent to the=20 IP

>    = ;=20 address and port from whence it came with the same IKE SPIs and=20 the

>    = ;=20 Message ID copied.  In case of INVALID_SPI, however, there are no=20 IKE

>    = ; SPI=20 values that would be meaningful to the recipient of such=20 a

>    = ;=20 notification.  Using zero values or random values are=20 both

>    = ;=20 acceptable.

 

Tero:

 

In a sense INVALID_MAJOR_VE= RSION=20 is also this kind of notification

which is sent outside of an= =20 IKE_SA, although it is sent as a response

to the incoming IKE SA crea= tion.=20 Perhaps we should note this fact

here?

 

Paul: Not done. This is=20 interesting, but should be discussed on the=20 list.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361338597CD6ilex01adcheck_-- From ynir@checkpoint.com Thu Apr 30 00:11:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173CE3A6F3D for ; Thu, 30 Apr 2009 00:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 icRiKeSv+5Sx for ; Thu, 30 Apr 2009 00:11:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4651028C122 for ; Thu, 30 Apr 2009 00:11:26 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6601C30C001; Thu, 30 Apr 2009 10:12:48 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 15B8C2CC001 for ; Thu, 30 Apr 2009 10:12:48 +0300 (IDT) X-CheckPoint: {49F94B12-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 n3U7ClqO014868 for ; Thu, 30 Apr 2009 10:12:47 +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; Thu, 30 Apr 2009 10:12:47 +0300 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 30 Apr 2009 10:15:10 +0300 Thread-Topic: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT Thread-Index: AcnHcZ+YaIJxATHRRr+TmvLG3gyQbQB8QGew Message-ID: <9FB7C7CE79B84449B52622B506C780361338597CD8@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A1@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A1@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C780361338597CD8ilex01adcheck_" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:11:49 -0000 --_000_9FB7C7CE79B84449B52622B506C780361338597CD8ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think we should really prohibit such extensions and enhancements. = It's just that IKE will fail if you try it with a peer that does not suppor= t it. As far as the end-user is concerned, this is not different from an UNSUPPOR= TED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel setup fails. Do you see any cause for concern in the UNSUPPORTED_CRITICAL_PAYLOAD being = sent in a non-encrypted unauthenticated message? Or in a response to such? ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Monday, April 27, 2009 10:52 PM To: IPsecme WG Subject: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_I= NIT > 2.5. Version Numbers and Forward Compatibility ... > IKEv2 adds a 'critical' flag to each payload header for further > flexibility for forward compatibility. If the critical flag is set > and the payload type is unrecognized, the message MUST be rejected > and the response to the IKE request containing that payload MUST > include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an > unsupported critical payload was included. {{ 3.10.1-1 }} In that > Notify payload, the notification data contains the one-octet payload > type. If the critical flag is not set and the payload type is > unsupported, that payload MUST be ignored. Payloads sent in IKE > response messages MUST NOT have the critical flag set. Note that the > critical flag applies only to the payload type, not the contents. If > the payload type is recognized, but the payload contains something > which is not (such as an unknown transform inside an SA payload, or > an unknown Notify Message Type inside a Notify payload), the critical > flag is ignored. Tero: What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the initial IKE_SA_INIT message, or do we forbid enhancements and modifications which might cause such error? Paul: Not done. This is interesting, but should be discussed on the list. =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C780361338597CD8ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't think we should really prohibit such extensio= ns and=20 enhancements.  It's just that IKE will fail if you try it with a peer = that=20 does not support it.
 
As far as the end-user is concerned, this is not diff= erent=20 from an UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH.  Either way, the tun= nel=20 setup fails.
 
Do you see any cause for concern in the=20 UNSUPPORTED_CRITICAL_PAYLOAD being sent in a non-encrypted unauthenticated= =20 message?  Or in a response to such?

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron=20 Sheffer
Sent: Monday, April 27, 2009 10:52 PM
To: IPs= ecme=20 WG
Subject: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR durin= g=20 initial IKE_INIT

>  2.5.  Versi= on=20 Numbers and Forward Compatibility

...

>    = ; IKEv2=20 adds a 'critical' flag to each payload header for=20 further

>    = ;=20 flexibility for forward compatibility.  If the critical flag is=20 set

>    = ; and=20 the payload type is unrecognized, the message MUST be=20 rejected

>    = ; and=20 the response to the IKE request containing that payload=20 MUST

>    = ;=20 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating=20 an

>    = ;=20 unsupported critical payload was included. {{ 3.10.1-1 }} In=20 that

>    = ;=20 Notify payload, the notification data contains the one-octet=20 payload

>    = ;=20 type.  If the critical flag is not set and the payload type=20 is

>    = ;=20 unsupported, that payload MUST be ignored.  Payloads sent in=20 IKE

>    = ;=20 response messages MUST NOT have the critical flag set.  Note that=20 the

>    = ;=20 critical flag applies only to the payload type, not the contents. =20 If

>    = ; the=20 payload type is recognized, but the payload contains=20 something

>    = ; which=20 is not (such as an unknown transform inside an SA payload,=20 or

>    = ; an=20 unknown Notify Message Type inside a Notify payload), the=20 critical

>    = ; flag=20 is ignored.

 

Tero:

 

What if such=20 UNSUPPORTED_CRITICAL_PAYLOAD error happens during=20 the

initial IKE_SA_INIT message= , or do=20 we forbid enhancements and

modifications which might c= ause=20 such error?

 

Paul: Not done. This is=20 interesting, but should be discussed on the=20 list.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C780361338597CD8ilex01adcheck_-- From ynir@checkpoint.com Thu Apr 30 00:58:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866933A6EF4 for ; Thu, 30 Apr 2009 00:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 iF0va2+OLo+v for ; Thu, 30 Apr 2009 00:58:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 978173A6E1B for ; Thu, 30 Apr 2009 00:58:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7496830C003; Thu, 30 Apr 2009 10:59:28 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 22C7D2CC001; Thu, 30 Apr 2009 10:59:28 +0300 (IDT) X-CheckPoint: {49F95602-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 n3U7xRqO027650; Thu, 30 Apr 2009 10:59:27 +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; Thu, 30 Apr 2009 10:59:27 +0300 From: Yoav Nir To: "Pasi.Eronen@nokia.com" , Yaron Sheffer , "ipsec@ietf.org" Date: Thu, 30 Apr 2009 11:01:51 +0300 Thread-Topic: [IPsec] Issue #43: Validity period of addresses obtained with config payload Thread-Index: AcnHcrHWRxodrUajS+q0/L9qYTTnaAAbYztQAGJl4eA= Message-ID: <9FB7C7CE79B84449B52622B506C780361338597CE3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A2@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F24A1F66@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F24A1F66@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #43: Validity period of addresses obtained with config payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:58:07 -0000 +1=20 Paso.Eronen wrote: >=20 > Yaron Sheffer wrote: >=20 > > [Sec. 3.15.1:] > > > > Tero: > > > > The text 'The requested address is valid until there are no IKE_SAs=20 > > between the peers.' is incorrect, it most likely should say 'The=20 > > requested address is valid as long as this IKE SA (or its rekeyed > > successors) requesting the address is valid.' > > > > I.e. even if another IKE SA is created between the peers=20 > that does not=20 > > keep the address allocated in another IKE SA alive, unless=20 > it is also=20 > > allocated in that IKE SA. This is especially the case where=20 > let's say=20 > > multi user hosts do per user IKE SAs and want to allocate=20 > IP addresses=20 > > separately for each user. > >=A0 > > Paul: Not done. This should be discussed on the mailing list. >=20 > I think Tero is right; the scope of configuration payloads is=20 > this IKE SA *and* its continuations via rekeying. >=20 > Best regards, > Pasi Email secured by Check Point From Pasi.Eronen@nokia.com Thu Apr 30 02:27:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48ECA3A6D2C for ; Thu, 30 Apr 2009 02:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 4jAhiJc7JIDa for ; Thu, 30 Apr 2009 02:27:45 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 19CE83A68CB for ; Thu, 30 Apr 2009 02:27:44 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3U9Ss9h013283 for ; Thu, 30 Apr 2009 12:29:02 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 12:28:57 +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); Thu, 30 Apr 2009 12:28:28 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 30 Apr 2009 11:28:26 +0200 From: To: Date: Thu, 30 Apr 2009 11:28:19 +0200 Thread-Topic: Transform IDs for AES-GMAC in IKEv1 Thread-Index: AcnJdf/ibfpukJqqRGyuUWXawxE4gg== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@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: 30 Apr 2009 09:28:28.0773 (UTC) FILETIME=[05393950:01C9C976] X-Nokia-AV: Clean Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 09:27:46 -0000 Hi, RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph). However, as Soo-Fei Chew pointed out, the IANA considerations text in the final document didn't actually ask IANA to assign the numbers for IKEv1.=20 Here's my proposal for fixing the situation: (1) ask IANA to assign the four missing numbers (after IESG approval). (2) submit an RFC Editor errata, saying something like this: =20 The following text should have been included in Section 9: For the negotiation of AES-GMAC in AH with IKEv1, the following values have been assigned in the IPsec AH Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use different transform identifiers. "TBD1" for AH_AES_128_GMAC "TBD2" for AH_AES_192_GMAC "TBD3" for AH_AES_256_GMAC For the negotiation of AES-GMAC in ESP with IKEv1, the following value has been assigned from the IPsec ESP Transform Identifiers registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a different transform identifier. =20 "TBD4" for ESP_NULL_AUTH_AES_GMAC (where we will in TBD1..4 after we know the numbers) (3) ask IANA to include a pointer to this errata in the isakmp-registry entries. Does this sound like a reasonable plan? Best regards, Pasi From kivinen@iki.fi Thu Apr 30 03:52:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFE93A6D3F for ; Thu, 30 Apr 2009 03:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 H0XnWvNzV4Rx for ; Thu, 30 Apr 2009 03:52:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C11A83A68C2 for ; Thu, 30 Apr 2009 03:52:33 -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 n3UArrIn013844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 13:53:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3UArpq0014661; Thu, 30 Apr 2009 13:53:51 +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: <18937.33599.729812.351256@fireball.kivinen.iki.fi> Date: Thu, 30 Apr 2009 13:53:51 +0300 From: Tero Kivinen To: "Narayanan, Vidya" In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC4D5B@il-ex01.ad.checkpoint.com> <18925.45980.896489.919446@fireball.kivinen.iki.fi> <49EEBDD3.2070706@qualcomm.com> <18926.62554.713509.846039@fireball.kivinen.iki.fi> <49F011FE.4070206@qualcomm.com> <18928.17060.932652.535677@fireball.kivinen.iki.fi> <49F04C9A.6080400@qualcomm.com> <18928.29165.128628.119901@fireball.kivinen.iki.fi> <18933.40440.788476.6666@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 52 min X-Total-Time: 95 min Cc: IPsecme WG , "Dondeti, Lakshminath" , Paul Hoffman Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 10:52:35 -0000 Narayanan, Vidya writes: > The requirement is quite simple and you just seem to ignore it or > provide unacceptable alternatives. The handoff latency must be good What handoff? We are talking about resumption, not handoff. I do not consider those same. Or then I understand completely wrong what handoff is, and what resumption is. For me handoff is when you have active connection to one place, and then you want to move that connection to another place without interrupting the communications. Resumption is when we have connection that was disconnected temporarely because of some reason, and we want to resume it after some period of time. Their requirements are very different and if we are really making standard for handoff, then our protocol would be different. > enough to support VoIP like applications and the handoff may imply > needing an IPsec session between the mobile and a network entity (be > it a VPN or for MIP6 channel security). You claim that in such > scenarios, IPsec should be used all the time, even on the interfaces > that don't require it for security purposes - so, even if the device > is not running MIP6 until it moves to the new interface, it now > needs to establish an IPsec session. I am not claiming it should be used all the time, but I am claiming that if you are planning to start to use IPsec again you should not first tear down your non-IPsec connection while you set up the IPsec connection. You should keep the old connection alive and then when you have IPsec connection ready, then you move your traffic to that connection requiring IPsec. I do not really belive you get very good handoff with break before make methods on any networks. > However, this is not acceptable for various reasons (including that > operators are not interested in maintaining IPsec sessions for all > devices just in case it roams at some point). They do not need to maintaing IPsec session for all devices for all time, they need to resume them about 10-100ms before they are actually required, i.e. before they break their old connection. One dropped packet on the IPsec resume is going to cause several times longer delay than one round trip. It is bed idea to design system so it does not tolerate even single lost packet. > Also, designing for a fixed set of interfaces is a problem - it may > not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G > infrastructure and 3G Femto; it could be 3G infrastructure and 3G > multi-hop, etc. In many of these cases, handoffs don't happen using > a single radio operating in multi-mode. Then when you decide you are going to roam to network that requires IPsec, you can resume the IPsec connection using the old connection (even when it is unneeded there), and then you have IPsec connection which you can move to new network with single round trip protocol. With WiFi the network setup time is usually much longer than one round trip. In devices I normally use (laptop, pda etc) the device requires about 3-10 seconds to get network up and working (turning radio on, finding basestation, connecting to basestation, getting IP-address via DHCP etc). I have not ever seen wlan that would work so fast that it would be enough for VoIP handoffs. I do not know about WiMAX, but at least my 3G cellular phone usually takes about 1-2 seconds to create data connection (i.e. when I select which "internet" connection to use to the time when it actually starts loading the page) and it seemed to take about one more second before the packet it sent out actually reaching my server. Adding 20-40 ms for one more round trip time to that does not really affect the big picture. On the other hand if you can do network setup while still keeping old connection alive, then you can also do the resumption and the one round trip during that time too. Can you explain me on what kind of devices you can really do handoff to new network with break and make method? > > So what is the exact problem there? > > The fundamental issue is that MIP6, using the K bit, allows the IP > address on the IKE SA to change, thereby accomplishing the MOBIKE > functionality and also conflicting with it if it ran together. When using MOBIKE you should not use the K-bit (if that is what I think it is), but you should just leave the IP-address handling of the IKE and IPsec to MOBIKE. The MOBIKE was meant to be used as building tool for MIP6, i.e. it still requires MIP6 to start using it, i.e. there should have been separate document specifying how to use MOBIKE and MIP6 together. It never assumed it would solve the MIP6 problem directly, it assumed that MIP6 and MOBIKE could together be used to solve the problem. > Please read the thread on "MOBIKE and MIP6" on the MIP6 mailing list > from back in 2006 if you are interested in more details. I have not really been interested in MIP6, after I showed them how MIP6 and IPsec can easily used together without any modifications to either MIP6 or IPsec, but they said that solution was not what they specified, so they are not going to use it (and that solution presented at that time, would work perfectly with MOBIKE now). > The conclusion was that a scenario of using MOBIKE and MIP6 between > the same two endpoints must be avoided. So I assume nobody has yet specified how to use MIP6 and MOBIKE together, but instead MIP6 still want to use their modified version of IPsec? > Well, the current approach for designing it for known air interfaces > that some of us may be familiar with and some models where multiple > interfaces need to simultaneously be active is certainly not going > to help it. We might as well say that this is not meant for > addressing the mobility use cases. Charter or draft does not say anything about resumption to be aimed for mobility use cases. I do not say it should not be one possible use case, but again it is hard to decide which optimizations to take when we do not have common idea where this protocol is meant for. As I still do not know where resumption is really meant for, I cannot really say what kind of protocol it should be. > > Most of the DoS attackers are not wanting to get something meaningful > > in return. I still think we need to design protocols so they are > > secure against such attacks. > > > > I'm really surprised by this. A good threat analysis should > determine the likelihood and impact of an attack and likelihood > largely depends on the attacker's incentive. And where can I find this "good threat analysis"? As you did ignore my point that this sitution can happen also without any attacker, by just in normal use with misconfigured networks. > If the incentive doesn't exist or is not meaningful, the likelihood > is generally low, causing the attack to be of low importance. It is really hard to imagine what kind of incentive could DoS attackers have in general. They could be just pissed of with some operator charging too much money for their phone calls, and they could try to make that operators networks perform badly. If the network is really set up using break-before-make connections (which I still do not belive anybody would really use), they can cause two drops by just first luring network user to wrong network and stealing ticket, and second break when network user tries to use the already consumed ticket later. I.e. they just set up WLAN basestation sending out station id which matches the operators allowed WLAN network. When user roams to that network, it will not get connection at all, thus his phone call breaks. User has still already sent out the ticket to the network, which was stolen by the attacker, and attacker uses that ticket to destroy the state from the SGW side. Now when client moves back to cellular network (after detecting that WLAN it tried to move to didn't offere serivce), everything works fine, until it finally reaches the proper WLAN and tries to move to that. Now the ticket is already used, and instead of the unacceptable 1 RT, he actually now have 3 round trips + Diffie-Hellman time, which is by your definition unacceptable for VoIP handoffs. Of course as attacker does not want to make active transmissions himself, he will rather make virus attacking phones and pdas, which will set up the attack, i.e turn on the WLAN on the phone and starts faking to be basestation, and forwarding the ticket packets forward, but dropping all others. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 30 04:57:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B74D3A71FA for ; Thu, 30 Apr 2009 04:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 oJgdNthYVNnN for ; Thu, 30 Apr 2009 04:57:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 044D33A71F3 for ; Thu, 30 Apr 2009 04:57:54 -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 n3UBxBYI022432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 14:59:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3UBxAbB008701; Thu, 30 Apr 2009 14:59:10 +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: <18937.37518.587112.539846@fireball.kivinen.iki.fi> Date: Thu, 30 Apr 2009 14:59:10 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338597CD8@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC55A1@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361338597CD8@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 11:57:56 -0000 Yoav Nir writes: > I don't think we should really prohibit such extensions and > enhancements. It's just that IKE will fail if you try it with a > peer that does not support it. Yes, but most likely it will ignore unauthenticated error notifications too, so it will fail only after timeout. > As far as the end-user is concerned, this is not different from an > UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel > setup fails. Yes. > Do you see any cause for concern in the UNSUPPORTED_CRITICAL_PAYLOAD > being sent in a non-encrypted unauthenticated message? It can be sent, but as the UNSUPPORTED_CRITICAL_PAYLOAD contains the payload number in, it might be good idea to say that if the payload which had that critical payload was encrypted, then the notification must also be encrypted (this applies to the especially to IKE_AUTH). If such error happens during IKE_SA_INIT, then response will be in clear anyways, and it will most likely be ignored by the initiator anyways (it could use it to shorten its timeouts, but must not fail the negotiation immediately). Question really is, if we want to add something about this to the document or not? -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 30 05:00:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D664228C2C5 for ; Thu, 30 Apr 2009 05:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 e6Jv+5V-TDQt for ; Thu, 30 Apr 2009 05:00:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id DF9B73A71F4 for ; Thu, 30 Apr 2009 05:00:04 -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 n3UC1QvZ015720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 15:01:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n3UC1PMx022655; Thu, 30 Apr 2009 15:01:25 +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: <18937.37653.850952.270704@fireball.kivinen.iki.fi> Date: Thu, 30 Apr 2009 15:01:25 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 12:00:05 -0000 Pasi.Eronen@nokia.com writes: > (1) ask IANA to assign the four missing numbers (after IESG approval). > (2) submit an RFC Editor errata, saying something like this: > (3) ask IANA to include a pointer to this errata in the isakmp-registry > entries. > > Does this sound like a reasonable plan? I think this is good way to solve the issue. -- kivinen@iki.fi From yaronf@checkpoint.com Thu Apr 30 13:36:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BD53A6C66 for ; Thu, 30 Apr 2009 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 LHVilLvx7Sna for ; Thu, 30 Apr 2009 13:36:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D00743A6857 for ; Thu, 30 Apr 2009 13:36:11 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 77D1530C001; Thu, 30 Apr 2009 23:37:33 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2AFE92CC001 for ; Thu, 30 Apr 2009 23:37:33 +0300 (IDT) X-CheckPoint: {49FA07A5-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 n3UKbWqO005052 for ; Thu, 30 Apr 2009 23:37:32 +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; Thu, 30 Apr 2009 23:37:32 +0300 From: Yaron Sheffer To: IPsecme WG Date: Thu, 30 Apr 2009 23:37:28 +0300 Thread-Topic: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcnJ03olVTa/waEaTVy8/VF7hw6pzA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5786@il-ex01.ad.checkpoint.com> 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_001C_01C9C9EC.9FE74B10" MIME-Version: 1.0 Subject: [IPsec] draft-ietf-ipsecme-ikev2-redirect-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:36:41 -0000 ------=_NextPart_000_001C_01C9C9EC.9FE74B10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001D_01C9C9EC.9FE74B10" ------=_NextPart_001_001D_01C9C9EC.9FE74B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We completed today the second WG last call for this document. There were a number of in-depth reviews (thanks everyone!) but no showstopper issues were raised. I would like to ask the authors to submit a new version of the draft covering all the new issues, and we will then submit it for AD review. Thanks, Yaron ------=_NextPart_001_001D_01C9C9EC.9FE74B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We completed today the second WG last call for this document. There were a number of in-depth reviews (thanks everyone!) but = no showstopper issues were raised.

 

I would like to ask the authors to submit a new = version of the draft covering all the new issues, and we will then submit it for AD review.

 

Thanks,

         =    Yaron

------=_NextPart_001_001D_01C9C9EC.9FE74B10-- ------=_NextPart_000_001C_01C9C9EC.9FE74B10 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDQzMDIwMzcyOFowIwYJKoZIhvcNAQkEMRYEFCOYLiipsuir GMTImNCjmvUqYuuPMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA RGKe3v6qi5UdTt8erohCmnfEtshTHb9tdv7TckbcxmGjYan0G2R1tncF5pLX1d3h8hFPZhoIFyWD mT5nVebRGH/9Kiz5TUUnq+G3h6JG3wLZyzKs6GWXrlfQdqmFulWTXQxaRFk2SFh757APDj7WH48U PvWOlXoickNGRok0uTAU1K6TtdDZ5gGyM2r9l5KtmLykRrF+0e50AVC4IEVNEfk/K8jdWVDrk1GQ fvgdWQ3VnZeKB1z+Kqc3TBlxtRpiYuV/Q20VHJzFrZuOLmonlBifLOwWOz/u1GwNVqy6iK1Z5Ygr uNhE52BBodgvVjTcz4zc+O2FGdjmsZR5OkE+SwAAAAAAAA== ------=_NextPart_000_001C_01C9C9EC.9FE74B10-- From ken.grewal@intel.com Thu Apr 30 13:37:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9340D3A6AB5 for ; Thu, 30 Apr 2009 13:37:19 -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 oXaAvF4UYDRU for ; Thu, 30 Apr 2009 13:37:18 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 24AB23A6857 for ; Thu, 30 Apr 2009 13:37:17 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 30 Apr 2009 13:38:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,275,1239001200"; d="scan'208";a="137894874" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 30 Apr 2009 13:38:41 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Thu, 30 Apr 2009 14:38:41 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Thu, 30 Apr 2009 14:38:31 -0600 Thread-Topic: Issue #90: Shorter WESP negotiation Thread-Index: AcnJi2bCXI48BrbLRLmiU4vxxrdrKwARPXxQ Message-ID: References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18937.37653.850952.270704@fireball.kivinen.iki.fi> In-Reply-To: <18937.37653.850952.270704@fireball.kivinen.iki.fi> 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: [IPsec] Issue #90: Shorter WESP negotiation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:37:19 -0000 All,=20 As we prepare to submit the next revision of the WESP draft, we wanted to get some discussion / feedback on some open ticket items. Issue #90: shorter WESP negotiation In the current traffic visibility draft, we indicate that WESP can be negotiated via IKEv2 using a new protocol identifier.=20 Charlie Kaufman suggested that it may be plausible to use a notification method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of transport is negotiated independently of the cryptographic parameters.=20 Pros: Shorted negotiation using notifications. Cons: Some flexibility is lost in not being able to negotiate different Crypto algorithms combinations with/without WESP. =09 Comments / opinions appreciated... Thanks,=20 - Ken= From ken.grewal@intel.com Thu Apr 30 13:37:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC3F3A6BBA for ; Thu, 30 Apr 2009 13:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR0FNQV+bIaD for ; Thu, 30 Apr 2009 13:37:29 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 70D093A6A24 for ; Thu, 30 Apr 2009 13:37:28 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 30 Apr 2009 13:29:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,275,1239001200"; d="scan'208";a="408450308" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga002.jf.intel.com with ESMTP; 30 Apr 2009 13:46:45 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Thu, 30 Apr 2009 14:38:49 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Thu, 30 Apr 2009 14:38:39 -0600 Thread-Topic: Issue #93: Next header value in tunnel mode for WESP Thread-Index: AcnIDrCltR8nsBxpShKdCU0o/k1nFAAEbktQAABP9zAAa9snUA== Message-ID: References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> 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: [IPsec] Issue #93: Next header value in tunnel mode for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:37:30 -0000 All,=20 As we prepare to submit the next revision of the WESP draft, we wanted to get some discussion / feedback on some open ticket items. Issue #93: Next Header field to provide the value for the tunneled packet i= f using tunnel mode In the current traffic visibility draft, we indicate that the next header value in the WESP header is equal to the next header value in the ESP trailer.=20 Charlie Kaufman suggested that middle boxes may not want to differentiate between tunnel / transport mode and just get to the payload.=20 i.e. consider providing the tunneled protocol value in WESP next header fie= ld in the case of tunnel mode and the WESP offset points to the tunneled payload Pros: easier parsing for intermediary devices Cons: lose consistency between next header in WESP and in ESP trailer - any security concerns? Comments / opinions appreciated... Thanks,=20 - Ken From root@core3.amsl.com Thu Apr 30 16:30:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8104428C136; Thu, 30 Apr 2009 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090430233001.8104428C136@core3.amsl.com> Date: Thu, 30 Apr 2009 16:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 23:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : M. Bhatia, K. Grewal, G. Montenegro Filename : draft-ietf-ipsecme-traffic-visibility-02.txt Pages : 12 Date : 2009-4-30 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of ESP [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-30161741.I-D@ietf.org> --NextPart--
algorithm=20 registries appear to have diverged, starting