From root@core3.amsl.com Fri May 1 13: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 3A5D13A6DB3; Fri, 1 May 2009 13: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: <20090501204501.3A5D13A6DB3@core3.amsl.com> Date: Fri, 1 May 2009 13:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-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, 01 May 2009 20: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 : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-ietf-ipsecme-ikev2-resumption-03.txt Pages : 26 Date : 2009-05-01 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. 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. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach requires passing opaque data from the IKEv2 responder to the IKEv2 initiator, which is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but recommendations are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-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-ikev2-resumption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-01133204.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Fri May 1 14: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 DE8F03A702D for ; Fri, 1 May 2009 14:02:09 -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.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 qPCHi8l7G1dB for ; Fri, 1 May 2009 14:02:08 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 827073A6B58 for ; Fri, 1 May 2009 14:00:48 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9C9F230C002; Sat, 2 May 2009 00:02:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1C4BB2CC003 for ; Sat, 2 May 2009 00:02:11 +0300 (IDT) X-CheckPoint: {49FB5ED8-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 n41L2AqO024371 for ; Sat, 2 May 2009 00:02:10 +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, 2 May 2009 00:02:10 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sat, 2 May 2009 00:02:07 +0300 Thread-Topic: Virtual interim meeting agenda Thread-Index: AcnKoBXbVI72M6mVQQGO9R1whxQ7Ug== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC579D@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_008E_01C9CAB9.3B795E20" MIME-Version: 1.0 Subject: [IPsec] Virtual interim meeting agenda 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, 01 May 2009 21:02:10 -0000 ------=_NextPart_000_008E_01C9CAB9.3B795E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, As you recall, we are meeting on Tuesday 5/5, 15:00 GMT, 11:00 EDT, 8:00 PDT. Below is the meeting agenda. Document editors, please confirm your participation or let us know if you are unable to make it into the call. And please send us your slides by Monday, so we can post them on the meeting page: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090505. * Agenda bash, document status (0:10) * Traffic visibility (0:15) * Visibility heuristics (0:10) * Session resumption (0:15) * IKE redirect (0:10) * IKEv2-bis open issues (remaining time) Very important: please make sure you are able to access the TeamSpeak server, even if you have an evil firewall between you and the Internet. The technical details are here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls Thanks, Paul and Yaron ------=_NextPart_000_008E_01C9CAB9.3B795E20 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMTIxMDIwN1owIwYJKoZIhvcNAQkEMRYEFL2SmlTcj4CO KqqWVFcWzUvzynC4MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA CSAgu1ikG4BAtviAzJ12Z6MNZvkaTJsjjHImLlUI82Y1NgfQoaXZ1q3ZQVyObnusmSkD5WpOaHp9 ZCzXcpJS1W7QHy4prnJxhTdp/6k5o3CDEpRs9TZaSJni9W4KerJ5i/CJLV2+gq2T1ta1Vh7J6cpf n/3sNdmeP1w6vjF1KIZ6ljQAsDIn8CRnsw6l3AXKGLCHiooKnyGWQfvzTKKqti0ykQdu/6lrw2oZ P+RzLUkcmgOsY1JGMkIGCYnqyYTvMKXS7/8Kk0sQpopGKdborImc6YidKPSajRwhE8MkyP6u3ETN ZyAlGJSd7lGHwulf2/SJHEsPyjmSBgeW2U1fNgAAAAAAAA== ------=_NextPart_000_008E_01C9CAB9.3B795E20-- From ynir@checkpoint.com Sat May 2 14:42: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 1E9AD3A6E5D for ; Sat, 2 May 2009 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 UI-qokk5nTWy for ; Sat, 2 May 2009 14:42:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 319983A6DD0 for ; Sat, 2 May 2009 14:42:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 69BB62CC006; Sun, 3 May 2009 00:44:03 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DD1C52CC002; Sun, 3 May 2009 00:44:02 +0300 (IDT) X-CheckPoint: {49FCBA15-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 n42Li2qO020056; Sun, 3 May 2009 00:44:02 +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, 3 May 2009 00:44:02 +0300 From: Yoav Nir To: "Grewal, Ken" , "ipsec@ietf.org" Date: Sun, 3 May 2009 00:41:06 +0300 Thread-Topic: Issue #90: Shorter WESP negotiation Thread-Index: AcnJi2bCXI48BrbLRLmiU4vxxrdrKwARPXxQAGeVnJ0= Message-ID: <9FB7C7CE79B84449B52622B506C7803613385C041A@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18937.37653.850952.270704@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 Subject: Re: [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: Sat, 02 May 2009 21:42:41 -0000 Grewal, Ken wrote: >=20 > 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. > 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. > > Pros: Shorted negotiation using notifications. > Cons: Some flexibility is lost in not being able to negotiate different > Crypto algorithms combinations with/without WESP. > > Comments / opinions appreciated... I think the con really addresses a non-problem. I don't think anyone is goi= ng to want NULL encryption if WESP is selected, but AES-256 if regular ESP = is selected. I think we should go with Charlie's suggestion. Yoav= Email secured by Check Point From ken.grewal@intel.com Sat May 2 22:37: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 1041E3A68EF for ; Sat, 2 May 2009 22:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 6Ioi5zApDu9X for ; Sat, 2 May 2009 22:37:41 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 45CB73A687C for ; Sat, 2 May 2009 22:37:41 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 02 May 2009 22:39:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,285,1239001200"; d="scan'208";a="138571394" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 02 May 2009 22:39:05 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Sat, 2 May 2009 23:39:04 -0600 From: "Grewal, Ken" To: Yoav Nir , "ipsec@ietf.org" Date: Sat, 2 May 2009 23:38:58 -0600 Thread-Topic: Issue #90: Shorter WESP negotiation Thread-Index: AcnJi2bCXI48BrbLRLmiU4vxxrdrKwARPXxQAGeVnJ0AEIGWsA== Message-ID: References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18937.37653.850952.270704@fireball.kivinen.iki.fi>, <9FB7C7CE79B84449B52622B506C7803613385C041A@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613385C041A@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 #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: Sun, 03 May 2009 05:37:42 -0000 Agreed - minor issue for the 'con', but needed to be raised. We actually added in a notification method to 'negotiate' WESP in the updat= ed revision of the draft. Look forward to other opinions on this approach... Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Yoav Nir >Sent: Saturday, May 02, 2009 2:41 PM >To: Grewal, Ken; ipsec@ietf.org >Subject: Re: [IPsec] Issue #90: Shorter WESP negotiation > >Grewal, Ken wrote: >> >> 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. >> 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. >> >> Pros: Shorted negotiation using notifications. >> Cons: Some flexibility is lost in not being able to negotiate different >> Crypto algorithms combinations with/without WESP. >> >> Comments / opinions appreciated... > >I think the con really addresses a non-problem. I don't think anyone is >going to want NULL encryption if WESP is selected, but AES-256 if regular >ESP is selected. I think we should go with Charlie's suggestion. > >Yoav >Email secured by Check Point >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Sun May 3 06: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 2DE0728C222 for ; Sun, 3 May 2009 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMwD83SluC7i for ; Sun, 3 May 2009 06:51:39 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5D82928C226 for ; Sun, 3 May 2009 06:50:40 -0700 (PDT) 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 n43Dq3qO000670; Sun, 3 May 2009 16:52:03 +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, 3 May 2009 16:52:03 +0300 From: Yaron Sheffer To: "Grewal, Ken" , "ipsec@ietf.org" Date: Sun, 3 May 2009 16:52:02 +0300 Thread-Topic: Issue #93: Next header value in tunnel mode for WESP Thread-Index: AcnIDrCltR8nsBxpShKdCU0o/k1nFAAEbktQAABP9zAAa9snUACJBKog Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> 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_00FF_01C9CC0F.7B25CB60" MIME-Version: 1.0 Subject: Re: [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: Sun, 03 May 2009 13:51:40 -0000 ------=_NextPart_000_00FF_01C9CC0F.7B25CB60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ken, It seems to me this field is more trouble than it's worth. We are assuming that the hardware will be enforcing a very simplistic security policy (don't care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.) and that the hardware is unable to perform anything more than extremely basic packet parsing. Both assumptions may well be incorrect. And the cost is in complicating the protocol and the endpoint implementations. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Grewal, Ken > Sent: Thursday, April 30, 2009 23:39 > To: ipsec@ietf.org > Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP > > All, > 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 > if > 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. > Charlie Kaufman suggested that middle boxes may not want to differentiate > between tunnel / transport mode and just get to the payload. > i.e. consider providing the tunneled protocol value in WESP next header > field 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, > - Ken > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00FF_01C9CC0F.7B25CB60 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzEzNTIwMVowIwYJKoZIhvcNAQkEMRYEFCA5bmJy4nvQ fUYNLVz1LThuDxLpMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA E7yAwRNvj+X5KosZqPiJOn+1BFGObBABOnOTARoK1zrCmddaPP3fFsW77V+1Sl24k2N0HZR6yt/l GudEyDE9dCGJC8xCWY78oK+rbtr2I5EMvIafRW3gySPpiRzqMmmwyq73kJcGIY9sV3XcNbUcefzm p1SdA8Cur8mM7aZgSpZSCmqjtsfHizNRUNbekhH8yH7cb4Fkj+BWAmx6fmlw49jGAn1hbGWx7qAC H7IJry7sFOmS7Occ9XbgM2ux48Sa/a5Q7AMUPKYlgPDITiwo/31QS720b/uu7VJmRKdskq3jies3 DulA/U1C6xBtyC36xP2xndXBPNgjCfykHl/j6AAAAAAAAA== ------=_NextPart_000_00FF_01C9CC0F.7B25CB60-- From kent@bbn.com Sun May 3 10:29: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 2C89E3A6AE5 for ; Sun, 3 May 2009 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqIWGQ0L99IB for ; Sun, 3 May 2009 10:29:31 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 768E93A69C5 for ; Sun, 3 May 2009 10:29:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.52.233]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0fWh-0008Gi-F8; Sun, 03 May 2009 13:30:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <18936.14205.619538.390538@fireball.kivinen.iki.fi> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> Date: Sat, 2 May 2009 13:01:47 -0400 To: Tero Kivinen From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, 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: Sun, 03 May 2009 17:29:32 -0000 At 2:18 PM +0300 4/29/09, Tero Kivinen wrote: >... > >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. 4301 does not have any notion of "combining" SPD entries. As you note, the SPD is ordered, so whichever SPD entry matches and is encountered first is used. Steve From yaronf@checkpoint.com Sun May 3 12:29: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 161F43A6A7A for ; Sun, 3 May 2009 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b369g2nrh230 for ; Sun, 3 May 2009 12:29:40 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D012B3A6C2A for ; Sun, 3 May 2009 12:29:39 -0700 (PDT) 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 n43JV3qO006514 for ; Sun, 3 May 2009 22:31:03 +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, 3 May 2009 22:31:03 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sun, 3 May 2009 22:31:01 +0300 Thread-Topic: A couple more issues Thread-Index: AcnHdrzJLP+TAWQzTOSLVS7DHzjh2wErm4Wg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5950@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_012B_01C9CC3E.D66A2910" MIME-Version: 1.0 Subject: [IPsec] A couple more 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: Sun, 03 May 2009 19:29:46 -0000 ------=_NextPart_000_012B_01C9CC3E.D66A2910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I will now open a few more IKEv2-bis issues that came up recently. Please reply within the next week, and if we have time, we may discuss some of them tomorrow. Did you notice we are now down to 22 open issues, out of 71? We are definitely getting there! Thanks, Yaron ------=_NextPart_000_012B_01C9CC3E.D66A2910 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzE5MzEwMVowIwYJKoZIhvcNAQkEMRYEFO180LRVsigQ 15Y1gvR41ZchiRT7MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA H0gVlqv4we/lA6eq1G/3xZuB9IBstXNabqEJJLEWj3MZyROGSFSiPWT0jPWfqehduCcevXNQfY6k /E9rjwW693AFeJ+aUypZUBS360Hzs4ZyKUxAsmhHwdKglG/fZSfuIE8PFky4IBhOXkvDMlLBnmpr t4R0kr/DVGsSiYzk+shctFSBrpOLsVUxJxy6Y1Cxr327hKOP/o6yJAerJdfL9QcMbExUhr1uTd/H CNR1662NjiDrWkg0+rW4mrYzMU74udRLWeaT9Zkbw6oCYuqAyTziPJ9XE39sap9bHlPXFMuK1wm3 OXhjYVDCiGzLaXA5lhb7Lp3PGB0B8zr+n7r4PAAAAAAAAA== ------=_NextPart_000_012B_01C9CC3E.D66A2910-- From yaronf@checkpoint.com Sun May 3 12:48: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 665AC3A6FE8 for ; Sun, 3 May 2009 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69yzk12qShLA for ; Sun, 3 May 2009 12:48:42 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 70E3128C1D5 for ; Sun, 3 May 2009 12:47:34 -0700 (PDT) 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 n43JmwqO009636 for ; Sun, 3 May 2009 22:48: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; Sun, 3 May 2009 22:48:58 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sun, 3 May 2009 22:48:56 +0300 Thread-Topic: Issue #57: Clarify D-H transform Thread-Index: AcnMKDGRaHrqk3VoS/6szaYPIvbLtg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5952@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_0130_01C9CC41.56E616B0" MIME-Version: 1.0 Subject: [IPsec] Issue #57: Clarify D-H transform 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, 03 May 2009 19:48:43 -0000 ------=_NextPart_000_0130_01C9CC41.56E616B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 3.3.2: there is no explanation here or elsewhere that the D-H transform for ESP and AH is used for PFS. Paul (off list): Not done. I don't think it belongs in 3.3.2, and I also don't agree that the transform is "the D-H transform for ESP and AH is used for PFS"; that's an oversimplification. Yaron: I will settle for 1.3.1, and/or 1.3.3. ------=_NextPart_000_0130_01C9CC41.56E616B0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzE5NDg1NVowIwYJKoZIhvcNAQkEMRYEFOKGq2IENLs6 FFkdfw5W8f54j1a1MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA JLeHvV/5tQqsmOLOuvbAw6e7M5x+fBG86+pmiBQppn0nZaBwV52ADnhg4iJLL/qlY8gcJnr9RxwI 7Qt4NLTIZinN3W0LwFfBJ3FecJWwOC0n8giEYnHoL9O+VMWOXQe42uSBnuEs4O7+tIcUImVNCIaq 6sy2R/x6602EIsjHloMZ5ec4Es41TDlXkenpYsP7gSU/soteByUELz6F2uiEIpHNlIm9fVu94RfI YDUq/jbvTeqGYbLFrrpvXBM0rLXmzYPlblSejHjRbZOM6aWxaYz/SHLh5gDvG/xd2Hx+C8adr4Kv TerS1y11EDGP7aqYfkTU0PAMPujpURdlLThCgQAAAAAAAA== ------=_NextPart_000_0130_01C9CC41.56E616B0-- From yaronf@checkpoint.com Sun May 3 13:37: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 8E26F3A6BDE for ; Sun, 3 May 2009 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scQiAdAkT85R for ; Sun, 3 May 2009 13:37:28 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 97A0428C292 for ; Sun, 3 May 2009 13:35:49 -0700 (PDT) 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 n43KbDqO018355 for ; Sun, 3 May 2009 23:37:13 +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, 3 May 2009 23:37:13 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sun, 3 May 2009 23:35:47 +0300 Thread-Topic: Issue #58: Access control: add ref to IPsec architecture Thread-Index: AcnMLr19QS3OtHgwTbmU2cPmTy767g== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5956@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_0144_01C9CC47.E2D453C0" MIME-Version: 1.0 Subject: [IPsec] Issue #58: Access control: add ref to IPsec architecture 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, 03 May 2009 20:37:29 -0000 ------=_NextPart_000_0144_01C9CC47.E2D453C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec). Paul: Not done, take to the list. Yaron: I propose to add after this noncommittal paragraph: The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. {{ Clarif-7.1 }} When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr is used purely to fetch the policy and authentication data related to the other party. The following new text, adapted from RFC 4945: The Peer Authorization Database (PAD) as described in RFC 4301 [XX] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE security association management. See RFC 4301 [14], Section 4.4.3 for more details. ------=_NextPart_000_0144_01C9CC47.E2D453C0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzIwMzU0N1owIwYJKoZIhvcNAQkEMRYEFNYXFyYXAQvf FfPObB2eDFtwzieAMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA o4dm/NUuN36bUbAbYDOp7EOjNlejNMqJW3miIBE7DL+3NV1HrHZqdWiGzq8urMunBY1z7Rz/mrKr C2I/DjmhJeZ38LQlIEOX4fC+3TKp0TBsGa20tiQkf7WIRsE08bPdRjEYPSGKB+vkas4hxsxco7J7 ftbPvWmSJ7pCQ7TA5m8X1E5mwcqHajCkGeKssw5bibigYUFzbc+LYBpG/RZMUovw3IeEMp/z+10W hDKrJ9IMCnUwPVP0KwWhdhn5JPpNmKJcdsyPQjjOeHti0expoLz5m2bmQSf+aQlKe/KlEiJtjXxU 51A4gTxMQUbCA14O+iQ4Gkvm5P+VxGDsKjgREAAAAAAAAA== ------=_NextPart_000_0144_01C9CC47.E2D453C0-- From yaronf@checkpoint.com Sun May 3 13:37: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 A65613A712B for ; Sun, 3 May 2009 13:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxvwBfPTqzjE for ; Sun, 3 May 2009 13:37:27 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 9787428C287 for ; Sun, 3 May 2009 13:35:47 -0700 (PDT) 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 n43KbAqO018339 for ; Sun, 3 May 2009 23:37:10 +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, 3 May 2009 23:37:10 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sun, 3 May 2009 23:37:10 +0300 Thread-Topic: Issue #9: Notification when creation of CHILD_SA fails Thread-Index: AcnMKgmpw/w3HJH6RA6KrwzZhXYftw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@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_0135_01C9CC43.2F02D640" MIME-Version: 1.0 Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 03 May 2009 20:37:34 -0000 ------=_NextPart_000_0135_01C9CC43.2F02D640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: > same IP address. The initiator begins negotiation of a CHILD_SA > using the SAi2 payload. The final fields (starting with SAi2) are > described in the description of the CREATE_CHILD_SA exchange. > > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > The responder asserts its identity with the IDr payload, optionally > sends one or more certificates (again with the certificate containing > the public key used to verify AUTH listed first), authenticates its > identity and protects the integrity of the second message with the > AUTH payload, and completes negotiation of a CHILD_SA with the > additional fields described below in the CREATE_CHILD_SA exchange. > > The recipients of messages 3 and 4 MUST verify that all signatures > and MACs are computed correctly and that the names in the ID payloads > correspond to the keys used to generate the AUTH payload. > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > fails for some reason, the IKE_SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an > IKE_SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. In the case of the that kind of failure the return packet will then be without the SAr2, Tsi, and TSr, i.e.: <-- HDR, SK {IDr, [CERT,] AUTH, N(error_for_child_sa)} If the authentication fails in such ways that the entries cannot create IKE SA (authentication failure or similar), then the response will be unencrypted, unauthenticated notify. There is no point of sending the notify encrypted and integrity protected, as it is not authenticated (as initiator and responder have not yet verified the AUTH payloads): <-- HDR, N(error_for_ike_sa) The initiator receiving such reply MUST NOT immediately stop the SA creation, but it should still retransmit the message few times, in case that error notify was forgery and the real responder will reply with valid reply. It can use the recipient of such message as a hint to tell that authentication failed, thus it can shorten the retransmission timers from few minutes down to few tens of seconds. Paul: The first part (don't nuke the IKE SA) is resolved, but the second part (should the error message be encrypted) is still an open issue. Yaron: And then we had a long discussion (see e.g. http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was never resolved. ------=_NextPart_000_0135_01C9CC43.2F02D640 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzIwMDIwOFowIwYJKoZIhvcNAQkEMRYEFFffDoa77RVx sfiUlj2WBUeh0SzBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MjlmrLUREXiNtLHxuCixri6PCixPAA+KDdJEHhFYiw4uyqBxqWHQwGMdEx0Cq4HLBOk5hMhetxoK ITByvcAqCK/HTJf+FtKJf730LN/yoNN+H7fY/7n5KTuNf+1DX7Ma+CSWI5PLZ6z/CT7uNqn3+oar f8KDNkd6mM/hcmAe3yN0u4gP+PlGK+GlMBMJBWonHHMQGKSseg9FYHFz1G9/SlvxzQoHx8zHoOab B5nCa5GSrYDfLWop3qwJRvxQ0Yz7j9ply/fvDKK1JPspaZGz0KuEh5gvLz8tFNHOoNLXv/hkFBz9 y3m+yr09MzC4gqQuPfpl4sqqW1WpvJ6gk31mrwAAAAAAAA== ------=_NextPart_000_0135_01C9CC43.2F02D640-- From yaronf@checkpoint.com Sun May 3 13:47:33 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 327D43A70D8 for ; Sun, 3 May 2009 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2jwGrtDiC-e for ; Sun, 3 May 2009 13:47:32 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 02A4E3A6AB7 for ; Sun, 3 May 2009 13:47:11 -0700 (PDT) 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 n43KbBqO018346 for ; Sun, 3 May 2009 23:37:11 +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, 3 May 2009 23:37:11 +0300 From: Yaron Sheffer To: IPsecme WG Date: Sun, 3 May 2009 23:37:10 +0300 Thread-Topic: Issue #26: Missing treatment of error cases Thread-Index: AcnMK2KMnEyGuAx1S5ykHUnKUOHeuw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5954@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_013A_01C9CC44.87E14660" MIME-Version: 1.0 Subject: [IPsec] Issue #26: Missing treatment of error cases 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, 03 May 2009 20:47:33 -0000 ------=_NextPart_000_013A_01C9CC44.87E14660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: [2.21:] > such a message (and also a network message like ICMP destination > unreachable) as a hint that there might be problems with SAs to that > IP address and should initiate a liveness test for any such IKE_SA. > An implementation SHOULD limit the frequency of such tests to avoid > being tricked into participating in a denial of service attack. > > A node receiving a suspicious message from an IP address with which > it has an IKE_SA MAY send an IKE Notify payload in an IKE > INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The > recipient MUST NOT change the state of any SAs as a result, but may > wish to audit the event to aid in diagnosing malfunctions. A node > MUST limit the rate at which it will send messages in response to > unprotected messages. We should also extend this section and include at least following cases: - Errors happening before authentication - Errors in the IPsec SA creation on IKE_AUTH - Describe which errors are so fatal that they cause the whole IKE SA to destroyed. Paul indicated he's not convinced any of these new cases are needed. Proposed new text would be welcome. ------=_NextPart_000_013A_01C9CC44.87E14660 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwMzIwMTE0NlowIwYJKoZIhvcNAQkEMRYEFBCxiJQCXmbi b89PzLlGivBtaiIxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Dm3nPE54Kk4TXXVRX4U6RCjT4dxUTKJ/i8L2BaDDLcFQFYc409pbt2pbU3ZUKElwtvK6nC50wOIy /jCtMkE1edJ/wdSak6UnB7AX2dlq/Jy9e0oQktQUvSCPAPssGIRAqDg5rhWg4zXEUThflzg+fyyT sChnC/R+xy0Kw629Y/EeR3vlsQtbs8jRXnMjhVbNpSCqOwOWQ0uZMDJKjr/D5KyLedtSzpHTfc2z MQT4DNe4yva6IDIhxmCIYc9AjzKeR8PZ0eRyi4OV+fSq+OCyI5D2zRcnOTt49kzCp37eWFmnukIi wt5nVLcy0iezVfUUQY/C7zmhhpgPmJCswZ3XaAAAAAAAAA== ------=_NextPart_000_013A_01C9CC44.87E14660-- From kivinen@iki.fi Mon May 4 04:47: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 B2A9E3A6C1A for ; Mon, 4 May 2009 04:47:43 -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 AoNpnlzDExhj for ; Mon, 4 May 2009 04:47:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 842A53A6C06 for ; Mon, 4 May 2009 04:47: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 n44Bn3wG025425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:49:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n44Bn3Fh024761; Mon, 4 May 2009 14:49: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: <18942.54830.962303.962170@fireball.kivinen.iki.fi> Date: Mon, 4 May 2009 14:49:02 +0300 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18937.37653.850952.270704@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 11 min Cc: "ipsec@ietf.org" 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: Mon, 04 May 2009 11:47:43 -0000 Grewal, Ken writes: > In the current traffic visibility draft, we indicate that WESP can be > negotiated via IKEv2 using a new protocol identifier. > 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. > > Pros: Shorted negotiation using notifications. For pros you can also put down "automatic fallback to normal ESP if other end does not support WESP". There is no guarantee that other end will properly fall back to other protocol if protocol identifier is used when negotiating WESP, but responder MUST ignore unrecognized status notification types. There is no specified requirement for IKEv2 implementation to support multiple proposal substructures, thus trying to propose ESP-NULL or WESP-NULL might not work (i.e. implementation can only check first the most preferred proposal and ignore the others). The current RFC does not specify how many proposals implementations should check, and at least some implementations do have some kind limit for number of proposals they check (and that limit might even be 1). -- kivinen@iki.fi From kivinen@iki.fi Mon May 4 04:52: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 2CB2B28C103 for ; Mon, 4 May 2009 04:52:23 -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 BfjijySWDxCX for ; Mon, 4 May 2009 04:52:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EE2EB3A6C7B for ; Mon, 4 May 2009 04:52:21 -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 n44Brg8E024004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:53:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n44BrgS0025553; Mon, 4 May 2009 14:53:42 +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: <18942.55110.31534.252679@fireball.kivinen.iki.fi> Date: Mon, 4 May 2009 14:53:42 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5952@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5952@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: IPsecme WG Subject: [IPsec] Issue #57: Clarify D-H transform 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, 04 May 2009 11:52:23 -0000 Yaron Sheffer writes: > Yaron: > > 3.3.2: there is no explanation here or elsewhere that the D-H transform for > ESP and AH is used for PFS. > > Paul (off list): > > Not done. I don't think it belongs in 3.3.2, and I also don't agree that the > transform is "the D-H transform for ESP and AH is used for PFS"; that's an > oversimplification. > > Yaron: I will settle for 1.3.1, and/or 1.3.3. It is not clear for me what kind of text you want to add to there. Can you propose some text so it would be easier to understand what the issue here is? -- kivinen@iki.fi From kivinen@iki.fi Mon May 4 04:57: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 BF6703A7012 for ; Mon, 4 May 2009 04:57:08 -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 vXYcKeReQeK8 for ; Mon, 4 May 2009 04:57:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id ADD123A6867 for ; Mon, 4 May 2009 04:55:44 -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 n44Bv7jD025754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 14:57:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n44Bv7Zj026379; Mon, 4 May 2009 14:57:07 +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: <18942.55315.226069.526924@fireball.kivinen.iki.fi> Date: Mon, 4 May 2009 14:57:07 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5956@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5956@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: IPsecme WG Subject: [IPsec] Issue #58: Access control: add ref to IPsec architecture 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, 04 May 2009 11:57:08 -0000 Yaron Sheffer writes: > 3.5: this section is extremely liberal on what access control policies > people can implement, but that's too late to change now. However, we CAN at > least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, > pki4ipsec). ... > The following new text, adapted from RFC 4945: > > The Peer Authorization Database (PAD) as described in RFC 4301 [XX] > describes the use of the ID payload in IKEv2 and provides a formal model for > the binding of identity to policy in addition to providing services that > deal more specifically with the details of policy enforcement. The PAD is > intended to provide a link between the SPD and the IKE security association > management. See RFC 4301 [14], Section 4.4.3 for more details. This paragraph looks good for me. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon May 4 05:08: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 99AFB3A7017 for ; Mon, 4 May 2009 05:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 ua1eqThvGKt1 for ; Mon, 4 May 2009 05:08:02 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 877FA3A6E3D for ; Mon, 4 May 2009 05:08:02 -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 n44C8e1q011901; Mon, 4 May 2009 07:09:28 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 15:09:23 +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); Mon, 4 May 2009 15:09:18 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 14:09:18 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Mon, 4 May 2009 14:09:17 +0200 From: To: , Date: Mon, 4 May 2009 14:09:16 +0200 Thread-Topic: Issue #9: Notification when creation of CHILD_SA fails Thread-Index: AcnMKgmpw/w3HJH6RA6KrwzZhXYftwAhtTXQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@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: 04 May 2009 12:09:18.0509 (UTC) FILETIME=[269115D0:01C9CCB1] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 04 May 2009 12:08:03 -0000 Tero, What do you think of the proposed text here? http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Yaron Sheffer > Sent: 03 May, 2009 23:37 > To: IPsecme WG > Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails >=20 > Tero: >=20 > > same IP address. The initiator begins negotiation of a CHILD_SA > > using the SAi2 payload. The final fields (starting with SAi2) > are > > described in the description of the CREATE_CHILD_SA exchange. > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > SAr2, TSi, TSr} > > > > The responder asserts its identity with the IDr payload, > optionally > > sends one or more certificates (again with the certificate > containing > > the public key used to verify AUTH listed first), authenticates > its > > identity and protects the integrity of the second message with > the > > AUTH payload, and completes negotiation of a CHILD_SA with the > > additional fields described below in the CREATE_CHILD_SA > exchange. > > > > The recipients of messages 3 and 4 MUST verify that all > signatures > > and MACs are computed correctly and that the names in the ID > payloads > > correspond to the keys used to generate the AUTH payload. > > > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH > exchange > > fails for some reason, the IKE_SA is still created as usual. The > > list of responses in the IKE_AUTH exchange that do not prevent an > > IKE_SA from being set up include at least the following: > > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. >=20 > In the case of the that kind of failure the return packet will then be > without the SAr2, Tsi, and TSr, i.e.: >=20 > <-- HDR, SK {IDr, [CERT,] AUTH, > N(error_for_child_sa)} >=20 > If the authentication fails in such ways that the entries cannot > create IKE SA (authentication failure or similar), then the response > will be unencrypted, unauthenticated notify. There is no point of > sending the notify encrypted and integrity protected, as it is not > authenticated (as initiator and responder have not yet verified the > AUTH payloads): >=20 > <-- HDR, N(error_for_ike_sa) >=20 > The initiator receiving such reply MUST NOT immediately stop the SA > creation, but it should still retransmit the message few times, in > case that error notify was forgery and the real responder will reply > with valid reply. It can use the recipient of such message as a hint > to tell that authentication failed, thus it can shorten the > retransmission timers from few minutes down to few tens of seconds. >=20 > Paul: >=20 > The first part (don't nuke the IKE SA) is resolved, but the second part > (should the error message be encrypted) is still an open issue. >=20 > Yaron: >=20 > And then we had a long discussion (see e.g. > http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but > it was > never resolved. From kivinen@iki.fi Mon May 4 05:08: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 C44633A6FCC for ; Mon, 4 May 2009 05:08:05 -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 8AjhxApQ-Cfo for ; Mon, 4 May 2009 05:08:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 535DD3A7017 for ; Mon, 4 May 2009 05:08: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 n44C9Ofk025885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 May 2009 15:09:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n44C9OLr026130; Mon, 4 May 2009 15:09: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: <18942.56052.591499.891898@fireball.kivinen.iki.fi> Date: Mon, 4 May 2009 15:09:24 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 11 min Cc: IPsecme WG Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 04 May 2009 12:08:05 -0000 Yaron Sheffer writes: > If the authentication fails in such ways that the entries cannot > create IKE SA (authentication failure or similar), then the response > will be unencrypted, unauthenticated notify. There is no point of > sending the notify encrypted and integrity protected, as it is not > authenticated (as initiator and responder have not yet verified the > AUTH payloads): > > <-- HDR, N(error_for_ike_sa) > > The initiator receiving such reply MUST NOT immediately stop the SA > creation, but it should still retransmit the message few times, in > case that error notify was forgery and the real responder will reply > with valid reply. It can use the recipient of such message as a hint > to tell that authentication failed, thus it can shorten the > retransmission timers from few minutes down to few tens of seconds. > > Paul: > > The first part (don't nuke the IKE SA) is resolved, but the second part > (should the error message be encrypted) is still an open issue. > > Yaron: > > And then we had a long discussion (see e.g. > http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was > never resolved. I think I have now changed my mind about this issue, meaning I think the reply should be encrypted and MAC'ed but it should still be clearly specified that it is unauthenticated, as we have not yet verified the identity of the other end. Having the message encrypted and MAC'ed proofs that the entity who sent us the IKE_SA_INIT is also responsible for this IKE_AUTH error, which means there is no point of retransmitting our request anymore, as only the party participating the Diffie-Hellman could have generated the error. I.e. when error of type: <--- HDR, SK { N(error_for_ike_sa) } is received we can consider that IKE SA connection as failed, and delete the IKE SA immediately, but we should not consider that error as permanent error from that node, as man in the middle attacker could have generated such error instead of the intended party. After receiving such error initiator MAY restart IKE SA creation from the beginning few times before completely failing the IKE SA creation. This is related to the section 2.4 3rd last paragraph which explains how initiator can protect himself against this kind of poison the connection setup attempt. I.e. if IKE SA negotiation failed then initiator should perhaps consider there might be man-in-the-middle and enable that protocol described there, i.e. process multiple IKE_SA_INIT replies, and continue them in paralleal and then pick the one which succeeds and fail the others. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon May 4 05:28: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 1452228C134 for ; Mon, 4 May 2009 05:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 deum2XMdJGmJ for ; Mon, 4 May 2009 05:28:44 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BE40D3A68CC for ; Mon, 4 May 2009 05:28:43 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n44CTwJa027180; Mon, 4 May 2009 15:30:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 15:29:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 15:29:40 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 4 May 2009 14:29:39 +0200 From: To: Date: Mon, 4 May 2009 14:29:39 +0200 Thread-Topic: [IPsec] Reopening issue #12 Thread-Index: AcnIvERZ6EqC2Bo5TmmHq89uBe+MZAD9O7Sw Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> In-Reply-To: <18936.14205.619538.390538@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: 04 May 2009 12:29:40.0416 (UTC) FILETIME=[FEE14C00:01C9CCB3] 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: Mon, 04 May 2009 12:28:45 -0000 Tero Kivinen wrote: > > But now Bob cannot meet the requirement "new SA MUST NOT be narrower > > than the old one", because it would violate his policy. >=20 > 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. >=20 > 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. Well, nothing in RFC 4301 requires implementing the SPD internally as an ordered list of entries; some kind of tree or associative array data structure could work, too. The requirement for ordered list of entries applies to the management UI, not the internals. So I think an implementation that treats the following two policies equivalently *is* allowed by RFC 4301 and 4306: Policy A: traffic on UDP ports 1000 MUST use ESP w/AES traffic on UDP ports 1001 MUST use ESP w/AES Policy B: traffic on UDP ports 1000-1001 MUST use ESP w/AES > 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. >=20 > 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. >=20 > > 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). >=20 > 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). >=20 > It does require algorithm selection to work so it does result in > algorithm that is acceptable for the whole old SA. My main concern was whether this (new SA MUST NOT be narrower than old one, but MAY be wider) is a new requirement compared to RFC 4306... Best regards, Pasi From yaronf@checkpoint.com Mon May 4 05:48:28 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 4E03628C16A for ; Mon, 4 May 2009 05:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 zDpRpLJgf4C0 for ; Mon, 4 May 2009 05:48:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5635628C136 for ; Mon, 4 May 2009 05:48:26 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EA82330C002; Mon, 4 May 2009 15:49:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 985CB2CC003; Mon, 4 May 2009 15:49:50 +0300 (IDT) X-CheckPoint: {49FF0E8B-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 n44CnnqP017087; Mon, 4 May 2009 15:49: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, 4 May 2009 15:49:49 +0300 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "kivinen@iki.fi" , "ipsec@ietf.org" Date: Mon, 4 May 2009 15:49:48 +0300 Thread-Topic: Issue #9: Notification when creation of CHILD_SA fails Thread-Index: AcnMKgmpw/w3HJH6RA6KrwzZhXYftwAhtTXQAAH0gHA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A25@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.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_0033_01C9CCCF.F42805D0" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 04 May 2009 12:48:28 -0000 ------=_NextPart_000_0033_01C9CCCF.F42805D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pasi, Tero's mail gives a clearer explanation of the situation than your proposed text. Gluing the two together, how about replacing your last paragraph with: If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not authenticated the other end yet (or if the peer fails to authenticate the other end for some reason), the information needs to be treated with caution. More precisely, (assuming that the MAC verifies correctly) the sender of the error indication is known to be the responder of the IKE_SA_INIT exchange, but the sender's identity cannot be assured. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Monday, May 04, 2009 15:09 > To: kivinen@iki.fi; ipsec@ietf.org > Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA > fails > > Tero, > > What do you think of the proposed text here? > > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html > > Best regards, > Pasi > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of ext Yaron Sheffer > > Sent: 03 May, 2009 23:37 > > To: IPsecme WG > > Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails > > > > Tero: > > > > > same IP address. The initiator begins negotiation of a CHILD_SA > > > using the SAi2 payload. The final fields (starting with SAi2) > > are > > > described in the description of the CREATE_CHILD_SA exchange. > > > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > > SAr2, TSi, TSr} > > > > > > The responder asserts its identity with the IDr payload, > > optionally > > > sends one or more certificates (again with the certificate > > containing > > > the public key used to verify AUTH listed first), authenticates > > its > > > identity and protects the integrity of the second message with > > the > > > AUTH payload, and completes negotiation of a CHILD_SA with the > > > additional fields described below in the CREATE_CHILD_SA > > exchange. > > > > > > The recipients of messages 3 and 4 MUST verify that all > > signatures > > > and MACs are computed correctly and that the names in the ID > > payloads > > > correspond to the keys used to generate the AUTH payload. > > > > > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH > > exchange > > > fails for some reason, the IKE_SA is still created as usual. The > > > list of responses in the IKE_AUTH exchange that do not prevent an > > > IKE_SA from being set up include at least the following: > > > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > > > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. > > > > In the case of the that kind of failure the return packet will then be > > without the SAr2, Tsi, and TSr, i.e.: > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > N(error_for_child_sa)} > > > > If the authentication fails in such ways that the entries cannot > > create IKE SA (authentication failure or similar), then the response > > will be unencrypted, unauthenticated notify. There is no point of > > sending the notify encrypted and integrity protected, as it is not > > authenticated (as initiator and responder have not yet verified the > > AUTH payloads): > > > > <-- HDR, N(error_for_ike_sa) > > > > The initiator receiving such reply MUST NOT immediately stop the SA > > creation, but it should still retransmit the message few times, in > > case that error notify was forgery and the real responder will reply > > with valid reply. It can use the recipient of such message as a hint > > to tell that authentication failed, thus it can shorten the > > retransmission timers from few minutes down to few tens of seconds. > > > > Paul: > > > > The first part (don't nuke the IKE SA) is resolved, but the second part > > (should the error message be encrypted) is still an open issue. > > > > Yaron: > > > > And then we had a long discussion (see e.g. > > http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but > > it was > > never resolved. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0033_01C9CCCF.F42805D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNDEyNDk0OFowIwYJKoZIhvcNAQkEMRYEFPFp7eM245aV SzPla/IhPSBr97BfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA lpL3u1B66Hg4wn+SaOKe0DLmN88R4RDa00/GNLB+fUZz72mStmySxo6GoQgjOskIvkxcBYcEsC+N tGMuT3ZlOZntNF3GNYgxfsj6DGckjpYVXQo4P9xElqdfpa0S0mmRZjtuDpBInmfXrYB9w1l012xk BnR4+Z9/HaUuAwnCCa6NjL+wWgIcVUIIMTAhmiXktmiL8TXfrJMw3gfdWZ9l9gABoar66f5/D9vC 1bytpYLAghqHy8B5XNo6b0GZTmQsmCx/Ob9u+krJwH5M40sP17ZgFrQcDBh/y6kWW/oV6f9LsBQ1 r5oklPsZuJy+PHVOQaei66zkBdRcmKYJGWWNTQAAAAAAAA== ------=_NextPart_000_0033_01C9CCCF.F42805D0-- From yaronf@checkpoint.com Mon May 4 06:07: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 AB8663A6CF5 for ; Mon, 4 May 2009 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 NbeQN07R0Jyq for ; Mon, 4 May 2009 06:07:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3C0CA3A6A04 for ; Mon, 4 May 2009 06:07:23 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 29B6630C002; Mon, 4 May 2009 16:08:48 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D16A12CC003; Mon, 4 May 2009 16:08:47 +0300 (IDT) X-CheckPoint: {49FF12FC-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 n44D8lqO022379; Mon, 4 May 2009 16:08: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; Mon, 4 May 2009 16:08:46 +0300 From: Yaron Sheffer To: Tero Kivinen Date: Mon, 4 May 2009 16:08:45 +0300 Thread-Topic: [IPsec] Issue #57: Clarify D-H transform Thread-Index: AcnMrvteT7qOlDisQRC0XUgGvwU4hQACKNQA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A34@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5952@il-ex01.ad.checkpoint.com> <18942.55110.31534.252679@fireball.kivinen.iki.fi> In-Reply-To: <18942.55110.31534.252679@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_003D_01C9CCD2.9A016170" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Issue #57: Clarify D-H transform 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, 04 May 2009 13:07:24 -0000 ------=_NextPart_000_003D_01C9CCD2.9A016170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Sec. 3.3.2 mentions that you negotiate a D-H group for ESP/AH, even though you only need encryption and integrity transforms for these protocols. I find it confusing, certainly for newcomers. For clarity, I suggest to add after the table in Sec. 3.3.3, this text: Although ESP and AH do not directly include a Diffie Hellman exchange, a D-H group MAY be negotiated for the Child SA. This allows the peers to employ D-H in the CREATE_CHILD_SA exchange, providing Perfect Forward Secrecy for the generated Child SA keys. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, May 04, 2009 14:54 > To: Yaron Sheffer > Cc: IPsecme WG > Subject: [IPsec] Issue #57: Clarify D-H transform > > Yaron Sheffer writes: > > Yaron: > > > > 3.3.2: there is no explanation here or elsewhere that the D-H transform > for > > ESP and AH is used for PFS. > > > > Paul (off list): > > > > Not done. I don't think it belongs in 3.3.2, and I also don't agree that > the > > transform is "the D-H transform for ESP and AH is used for PFS"; that's > an > > oversimplification. > > > > Yaron: I will settle for 1.3.1, and/or 1.3.3. > > It is not clear for me what kind of text you want to add to there. Can > you propose some text so it would be easier to understand what the > issue here is? > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_003D_01C9CCD2.9A016170 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNDEzMDg0NVowIwYJKoZIhvcNAQkEMRYEFBPeJfhh0a2S EIuGwhkVYp5UduTWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA bnMQCH6bQgdd1k7/x9aADiNwLGyM2KJrmsFOrHReE4kA0AKMDYiEYgo8s3lBFkPrNPBFtNo1HX3D yo+D3cSGUvcu+7/0AFqWUg4XrEqwxxrXmv1QSdJnjOIkWyHdUHAz9wLpg9uEd60h739+ZiKo/ZUZ 2UQRuVpKa8tfYda+vccR4sU4iMjASKN1YzV+5TA3UOQMRDAg8Efe/aJY8D3YJz+cIv7O5qMylf37 qQcuLIwJBKCJgIwOG0B8hQmfXqY71I0W2/sA6VjY0IdUc/nwUjxI7HYqtAEzdifHgwCmJ95var7+ h9XMbW/w+JRgrztGksvO36EausbAEH2mXzPytAAAAAAAAA== ------=_NextPart_000_003D_01C9CCD2.9A016170-- From Pasi.Eronen@nokia.com Mon May 4 06:16: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 E832A3A6A0B for ; Mon, 4 May 2009 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 9tWfWzuDtExv for ; Mon, 4 May 2009 06:16:43 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CDAE53A7028 for ; Mon, 4 May 2009 06:16:16 -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 n44DHFlM017658; Mon, 4 May 2009 16:17:36 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 16:16:52 +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); Mon, 4 May 2009 16:16:48 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 15:16:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Mon, 4 May 2009 15:16:47 +0200 From: To: , , Date: Mon, 4 May 2009 15:16:45 +0200 Thread-Topic: Issue #9: Notification when creation of CHILD_SA fails Thread-Index: AcnMKgmpw/w3HJH6RA6KrwzZhXYftwAhtTXQAAH0gHAAAHGk4A== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2515249@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A25@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A25@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: 04 May 2009 13:16:48.0121 (UTC) FILETIME=[9452D690:01C9CCBA] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 04 May 2009 13:16:45 -0000 Yaron Sheffer wrote: > Hi Pasi, >=20 > Tero's mail gives a clearer explanation of the situation than your > proposed text. Gluing the two together, how about replacing your > last paragraph with: >=20 > If the failure is related to creating the IKE SA (for example, > AUTHENTICATION_FAILED), the IKE_SA is not created. Note that > although the IKE_AUTH messages are encrypted and integrity > protected, if the peer receiving this notification has not > authenticated the other end yet (or if the peer fails to > authenticate the other end for some reason), the information needs > to be treated with caution. More precisely, (assuming that the MAC > verifies correctly) the sender of the error indication is known to > be the responder of the IKE_SA_INIT exchange, but the sender's > identity cannot be assured. Looks good to me! Best regards, Pasi > > -----Original Message----- > > From: Pasi.Eronen@nokia.com > > Sent: Monday, May 04, 2009 15:09 > > To: kivinen@iki.fi; ipsec@ietf.org > > Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA > > fails > > > > Tero, > > > > What do you think of the proposed text here? > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html > > > > Best regards, > > Pasi From kent@bbn.com Mon May 4 06:41: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 27FAF3A6B7B for ; Mon, 4 May 2009 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehBnPrL4aXma for ; Mon, 4 May 2009 06:41:08 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5A1FA3A7051 for ; Mon, 4 May 2009 06:40:56 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0yR3-0007Zn-EU; Mon, 04 May 2009 09:42:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 4 May 2009 08:38:20 -0400 To: From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, kivinen@iki.fi 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: Mon, 04 May 2009 13:41:09 -0000 Pasi, It is true that 4301 does not require that the SPD be implemented as an order list of entries. In fact, 4301 specifically adopts a de-correlated SPD model to explain the details of processing. Steve From ken.grewal@intel.com Mon May 4 10:42: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 13AE13A67B2 for ; Mon, 4 May 2009 10:42:05 -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 3Z5QoGrMwL2T for ; Mon, 4 May 2009 10:42:04 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 2C4173A6358 for ; Mon, 4 May 2009 10:42:04 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 04 May 2009 10:32:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,292,1239001200"; d="p7s'?scan'208";a="687367741" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga001.fm.intel.com with ESMTP; 04 May 2009 10:47:03 -0700 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 11:43:27 -0600 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Mon, 4 May 2009 11:43:27 -0600 From: "Grewal, Ken" To: Yaron Sheffer , "ipsec@ietf.org" Date: Mon, 4 May 2009 11:43:16 -0600 Thread-Topic: Issue #93: Next header value in tunnel mode for WESP Thread-Index: AcnIDrCltR8nsBxpShKdCU0o/k1nFAAEbktQAABP9zAAa9snUACJBKogADqQ6jA= Message-ID: References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@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_0044_01C9CCA5.2165A730" MIME-Version: 1.0 Subject: Re: [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: Mon, 04 May 2009 17:42:05 -0000 ------=_NextPart_000_0044_01C9CCA5.2165A730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yaron, I am inclined to agree, but wanted to raise this as an option as it was raised during conversations at the last meeting. Are you indicating that we should set this field to be the same value as in the ESP trailer, irrespective of tunnel / transport mode? Thanks, - Ken >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf@checkpoint.com] >Sent: Sunday, May 03, 2009 6:52 AM >To: Grewal, Ken; ipsec@ietf.org >Subject: RE: Issue #93: Next header value in tunnel mode for WESP > >Hi Ken, > >It seems to me this field is more trouble than it's worth. We are assuming >that the hardware will be enforcing a very simplistic security policy >(don't >care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.) >and that the hardware is unable to perform anything more than extremely >basic packet parsing. Both assumptions may well be incorrect. And the cost >is in complicating the protocol and the endpoint implementations. > >Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Grewal, Ken >> Sent: Thursday, April 30, 2009 23:39 >> To: ipsec@ietf.org >> Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP >> >> All, >> 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 >> if >> 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. >> Charlie Kaufman suggested that middle boxes may not want to differentiate >> between tunnel / transport mode and just get to the payload. >> i.e. consider providing the tunneled protocol value in WESP next header >> field 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, >> - Ken >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0044_01C9CCA5.2165A730 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCTCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAA AAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIy MjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9 x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJ wyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtf p8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP 2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gEC AwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoER ghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGs oIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFs JTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy bDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUy MENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7soc oJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1 kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOS IF2VUmueAmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98k k3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIF9zCC BN+gAwIBAgIKG5+jTgAAAAAg/jANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgM0EwHhcNMDgwNjAyMTU1MzQxWhcNMTEwNjAyMTU1MzQxWjA7MRQwEgYDVQQDEwtHcmV3 YWwsIEtlbjEjMCEGCSqGSIb3DQEJARYUa2VuLmdyZXdhbEBpbnRlbC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC4FCPKjpfz6Mt/j1HuGDmHHXcamuS7gQlfSOQy+phBM4G2Jqw+ oYdOmEj3FadVI6osyhOShSj7mvFE+2UkDyEeIAD1LJrjJHC03jkl5Ll1YrxeNpYN/EMlSCtZZ2iW hd6M0uk+e408Zx2lD06ju+EJ2uNZ4Hux6COGT0cnm8oeL2Lr0eRUM/SdqOGw/LM3btEg6WUfN2MJ 3NeE7TvPifTPSQMMAh7mBzW2YUNem4Cj4uq+vacrn0zEijuh3/wCsn8M7GF1uDBjv7WM9jB/P+lD yCA9hOPxsD+4++AtAkDYm/DAUvarOa3jSAOXPv1PBLexJru6J3a30h1ZbHT1AX9bAgMBAAGjggLg MIIC3DALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFDjNfXcVsj96VG4IIV5BNTJmL9nAMDwGCSsGAQQB gjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4HevTmV8EMCAWQCAQYwHwYD VR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCBtYZUaHR0 cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2lj JTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9y ZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAz QS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwu Y29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDApBgkr BgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAkBgorBgEE AYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAorkt9OOF3L7PME5cQ/2ZXtVbS07RUTBsu+nuHQygUbgYt0sUsnL0G+CA +fu+2R8RrLKvFSsCdkw8FHi+DSaIuYXxQkof+B8GN/9AJ+Xt2zf1Y36ILLoBdwKAwG2GmVEngUoc 0FQQZ9n3GB7DSIK0wKXNwWILJSlnHW0nq5j1k3zP/pmpWe/xv10UGL/otML5weJl0BUDkSoxMES9 Zzi0/Ph4/vENFnZwvbzrLbxi5/wZLsD3KK9PofcAEqXi4z33QIW4Thd8IQzc+UzvRDXS1On+DZyH RbGt9/7GAwfVoFlswIb+/yGds/LuBTxUsVe1d1MRrmeTBniv4UL9Dt2jRjCCBj4wggUmoAMCAQIC Chue2YYAAAAAIP0wDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVs IENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNB MB4XDTA4MDYwMjE1NTI0M1oXDTExMDYwMjE1NTI0M1owOzEUMBIGA1UEAxMLR3Jld2FsLCBLZW4x IzAhBgkqhkiG9w0BCQEWFGtlbi5ncmV3YWxAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA9OP+3itCo/qwJlycjkVscHNGVD6syIQkohfFYGbEwgXDmZ11Mjnfly9kIKmb qJi4AmQLbzxiCNLhze/iWE9oS9q7oTron00id0Jq8RFugV0exfAeZxpsZORofjcq5gpUUAGcMONT 0e8CS9JcQ+X9imcanwXgIpmWs6w5L0j49Lnx3Q5chY3RNp3TZJZlQ5XNVw68ZTj5KBzLRsJGdym9 vMKKvzgkyQVDswbFvnl/AdM2A9X0SLzdmmCOuIxXMLxClqEQfjWq7oVq0U4j7eGk+RkP0Phj02xP qP+VOmXCU8AEAVIO/809uKvPjK8rSEEIybKEb+s/8jWtlw1bH3FyTQIDAQABo4IDJzCCAyMwCwYD VR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIA gDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUznBDWAHsnnyH0lGMsHGgDuEq7HYwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlnhLnZQYeE/04CAWQC AQkwHwYDVR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCB tYZUaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVs LmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjAzQS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMu aW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNp YyUyMElzc3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD BDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEALND1Kg3D0peyUCD/XDB7cpsOWB8zf6omdTwotvEUWZo+KTxB xP5jW3wg++RRfjm5/NoSxJDzEYUTIByV8wI/qlGPPMnFu8MePB3YazYj5UPmgAQzgNTZfKj4UNgG R80voebkkzRBiFsa3j/dd6XHdAf7B+Rsl4ryUzSb87CkAdJVsEadHgjDM+Ft56oumvWzl+v7JWCk BmGPAlUnJGbpREoqWvesP5nGChYh77GYvHDRrSMgpFJ/x30V91BHwEQgSOPPccvf6OZqUJuSc7zT ElztMjoPIL9hjxNsz45KlkEk28siciKUwq2Jx0lnWJiVSL1svhV2DlXSUvn2a4VGWTGCA0EwggM9 AgEBMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQD EyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobn6NOAAAAACD+MAkGBSsOAwIa BQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNDE3 NDMxNVowIwYJKoZIhvcNAQkEMRYEFLbW3dabVrvi4qjQnqy2lqoJif99MGcGCSqGSIb3DQEJDzFa MFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkG A1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRl cm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobntmGAAAAACD9MHUGCyqGSIb3DQEJEAILMWagZDBW MQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVs IEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ECChue2YYAAAAAIP0wDQYJKoZIhvcNAQEBBQAE ggEAg481jpz6KQXeTcIJNT2UZAcsKmh+G3Hy5P/t32W1ZD9PDjgBf+2/r2vr3zBI1GF79khUMkBC lrZ9tT+OwNpLqfo411K6YKNp0N5D824I2MIBfE+IHDJAsIZ2tzNRjK/rm/IZgNPhd0zsIcG0OFyP xlG6J5FOVU2Jm42yXb+Bc1hrQDz1VW6qeEoz1lbZn73BarUk7mTxzov66wHnTvQ889MHmDlyXRi9 GZAydi/M3DrHg/4z7VPg8Sc6FffjKt9gOjVcVZQ4e1H5dKtimW95f5jA+J73fx1zuy+91vKSx7u+ Lk2IWbvQHagmRVhSjkLWUk7e4VLdtUOm9rydPo6sOgAAAAAAAA== ------=_NextPart_000_0044_01C9CCA5.2165A730-- From ken.grewal@intel.com Mon May 4 10:48: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 9700F3A7120 for ; Mon, 4 May 2009 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFFN-JR0jYv2 for ; Mon, 4 May 2009 10:48:35 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id A7EBE3A7019 for ; Mon, 4 May 2009 10:48:35 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 04 May 2009 10:40:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,292,1239001200"; d="scan'208";a="512408480" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 04 May 2009 10:49:19 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 11:50:01 -0600 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Mon, 4 May 2009 11:50:00 -0600 From: "Grewal, Ken" To: Tero Kivinen Date: Mon, 4 May 2009 11:49:48 -0600 Thread-Topic: [IPsec] Issue #90: Shorter WESP negotiation Thread-Index: AcnMrlkhH17nYZYOTMm/AxNEXV2XkAAMXtRQ Message-ID: References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18937.37653.850952.270704@fireball.kivinen.iki.fi> <18942.54830.962303.962170@fireball.kivinen.iki.fi> In-Reply-To: <18942.54830.962303.962170@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: "ipsec@ietf.org" Subject: Re: [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: Mon, 04 May 2009 17:48:37 -0000 Thanks Tero.=20 I agree with your additional observations on the pros of taking this approa= ch for a simpler and shorter WESP negotiation. Furthermore, your point reg= arding undesirable behavior using a multiple proposals approach with WESP i= s well noted.=20 The notification method for WESP negotiation has already been added to the = updated draft we submitted last week and unless someone raises additional p= oints on why this may not work, we can leave it as it stands. Thanks,=20 - Ken =20 >-----Original Message----- >From: Tero Kivinen [mailto:kivinen@iki.fi] >Sent: Monday, May 04, 2009 4:49 AM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: [IPsec] Issue #90: Shorter WESP negotiation > >Grewal, Ken writes: >> In the current traffic visibility draft, we indicate that WESP can be >> negotiated via IKEv2 using a new protocol identifier. >> 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. >> >> Pros: Shorted negotiation using notifications. > >For pros you can also put down "automatic fallback to normal ESP if >other end does not support WESP". There is no guarantee that other end >will properly fall back to other protocol if protocol identifier is >used when negotiating WESP, but responder MUST ignore unrecognized >status notification types. > >There is no specified requirement for IKEv2 implementation to support >multiple proposal substructures, thus trying to propose ESP-NULL or >WESP-NULL might not work (i.e. implementation can only check first the >most preferred proposal and ignore the others). > >The current RFC does not specify how many proposals implementations >should check, and at least some implementations do have some kind >limit for number of proposals they check (and that limit might even be >1). >-- >kivinen@iki.fi From yaronf@checkpoint.com Mon May 4 12:53: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 9C7C63A6B9A for ; Mon, 4 May 2009 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 OudWaUYIJCZj for ; Mon, 4 May 2009 12:53:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 073623A6AE2 for ; Mon, 4 May 2009 12:53:15 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0294630C002; Mon, 4 May 2009 22:54:39 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A94842CC003; Mon, 4 May 2009 22:54:39 +0300 (IDT) X-CheckPoint: {49FF7218-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 n44JscqO005549; Mon, 4 May 2009 22:54:39 +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, 4 May 2009 22:54:38 +0300 From: Yaron Sheffer To: "Grewal, Ken" , "ipsec@ietf.org" Date: Mon, 4 May 2009 22:54:37 +0300 Thread-Topic: Issue #93: Next header value in tunnel mode for WESP Thread-Index: AcnIDrCltR8nsBxpShKdCU0o/k1nFAAEbktQAABP9zAAa9snUACJBKogADqQ6jAABKet4A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5AC5@il-ex01.ad.checkpoint.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@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_004D_01C9CD0B.4CC9FCD0" MIME-Version: 1.0 Subject: Re: [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: Mon, 04 May 2009 19:53:16 -0000 ------=_NextPart_000_004D_01C9CD0B.4CC9FCD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Actually I'm suggesting to drop it altogether. Thanks, Yaron > -----Original Message----- > From: Grewal, Ken [mailto:ken.grewal@intel.com] > Sent: Monday, May 04, 2009 20:43 > To: Yaron Sheffer; ipsec@ietf.org > Subject: RE: Issue #93: Next header value in tunnel mode for WESP > > Hi Yaron, > I am inclined to agree, but wanted to raise this as an option as it was > raised during conversations at the last meeting. > > Are you indicating that we should set this field to be the same value as > in > the ESP trailer, irrespective of tunnel / transport mode? > > Thanks, > - Ken > > > >-----Original Message----- > >From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > >Sent: Sunday, May 03, 2009 6:52 AM > >To: Grewal, Ken; ipsec@ietf.org > >Subject: RE: Issue #93: Next header value in tunnel mode for WESP > > > >Hi Ken, > > > >It seems to me this field is more trouble than it's worth. We are > assuming > >that the hardware will be enforcing a very simplistic security policy > >(don't > >care if it's Tunnel or Transport, don't care if it's a TCP SYN or not > etc.) > >and that the hardware is unable to perform anything more than extremely > >basic packet parsing. Both assumptions may well be incorrect. And the > cost > >is in complicating the protocol and the endpoint implementations. > > > >Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > >> Grewal, Ken > >> Sent: Thursday, April 30, 2009 23:39 > >> To: ipsec@ietf.org > >> Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP > >> > >> All, > >> 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 > >> if > >> 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. > >> Charlie Kaufman suggested that middle boxes may not want to > differentiate > >> between tunnel / transport mode and just get to the payload. > >> i.e. consider providing the tunneled protocol value in WESP next header > >> field 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, > >> - Ken > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> Scanned by Check Point Total Security Gateway. ------=_NextPart_000_004D_01C9CD0B.4CC9FCD0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNDE5NTQzN1owIwYJKoZIhvcNAQkEMRYEFFR2kldjZTXY AZ9rLBbzEJcI16mkMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA t3TK9B/DD0sWYYMK7TLj/CrEJSMyRiH+OW78+GI8n5xmd2TElQtInj38HWvZbj33WYedbSyNqgn4 adex82TWgBVOJE0e0b8hKLZl5sAqWyGupQpr2WLw2zfAzd+vGAzGn8Vqc5sGA0SNpd6yOs0P/L1H Yotc6VNLJa6N/gSlPbWKAiln8D8gZLvej6wktFiG4t1AVjzf3+fp1D0SPUSj3BkulH1iDVc64ycO Dc2T/j3WyGyS6BCktiXYfi4l7y1eE065wN/TWoG6V1qhXVcposNLKvx/AGOB+8VINY4GzxpzAZpL MQGVliE7tmKruZOjokvPeH4FCqtBHZTeCZPbtwAAAAAAAA== ------=_NextPart_000_004D_01C9CD0B.4CC9FCD0-- From vijay@wichorus.com Mon May 4 14: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 41C403A6D36 for ; Mon, 4 May 2009 14:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.115, 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 aGrDFtfh6JyA for ; Mon, 4 May 2009 14:43:16 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C2D383A67AC for ; Mon, 4 May 2009 14:43:15 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) 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, 4 May 2009 21:44:41 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 04 May 2009 14:44:40 -0700 From: Vijay Devarapalli To: , , Message-ID: Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAlz0n0ABSjcw5A== In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F246D90A@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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, 04 May 2009 21:43:17 -0000 Hi Pasi, Thanks for the detailed review (again). On 4/28/09 1:10 AM, "Pasi.Eronen@nokia.com" wrote: > 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: You are right. I guess I kept adding small amounts of text over multiple versions. Your rewrite of section 3 is fine with me. I made one change. > 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, Changed this to "... information about the selected VPN gateway", since you can send the FQDN of the new gateway instead of the IP address. But the original text already had this bug. > 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...) I like the above text. Couldn't think of anything else that might have been missed. > And the security considerations text needs something, too. I added the following text... The redirect mechanism MUST NOT update any state on the client apart from the VPN gateway information. When used with Mobile IPv6, care must be taken to ensure that the home agent information that the mobile node has configured is not modified wrongly by the redirect message. > 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. The current text assumes that the IKE SA is created and needs to be deleted. I don't think we need to show the INFORMATIONAL exchange. We are not modifying anything in the delete procedure. We currently have the following text When the client receives the IKE_AUTH response with the REDIRECT payload, it SHOULD delete the existing IKEv2 security association with the gateway. Isn't this sufficient? > 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. The gateway can always include the REDRIECT notification in the first IKE_AUTH response. The text that you quoted follows the text that says the redirect decision may be done based on the interaction with the AAA server or an external authentication server. But Yoav also had a comment on the same paragraph. This means it is not clear. So I am fine with adopting your text above. > 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. Ok, removed the last paragraph in section 9. Vijay > > 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 >> >> 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Mon May 4 15:24: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 3458C3A687F for ; Mon, 4 May 2009 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 ykhq4Wir2PT6 for ; Mon, 4 May 2009 15:24:07 -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 20F593A69C8 for ; Mon, 4 May 2009 15:24:06 -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 n44M8N42081642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 May 2009 15:08:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 4 May 2009 15:08:18 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Virtual interim is tomorrow, 2009-05-05 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, 04 May 2009 22:24:08 -0000 One last reminder of the virtual interim meeting. It is 5 May 2009 15:00 GMT, 11:00 EDT, 8:00 PDT. A few presentations have slides; see for the agenda and slides. Information on how to get and use the teleconference software is at ; please feel free to connect a bit early to test out your setup. --Paul Hoffman, Director --VPN Consortium From vijay@wichorus.com Mon May 4 15:31: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 CF9E33A67E5 for ; Mon, 4 May 2009 15:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_31=0.6, 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 OrafVpd-90Px for ; Mon, 4 May 2009 15:31:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5E5C73A6CFF for ; Mon, 4 May 2009 15:31:22 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) 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, 4 May 2009 22:32:47 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 04 May 2009 15:32:47 -0700 From: Vijay Devarapalli To: Tero Kivinen , IPsecme WG Message-ID: Thread-Topic: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcnNCD/DtUsEydELgEianCvwwKMjug== In-Reply-To: <18935.5198.554334.837387@fireball.kivinen.iki.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [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: Mon, 04 May 2009 22:31:40 -0000 Hi Tero, Thanks for the detailed review. On 4/28/09 7:35 AM, "Tero Kivinen" wrote: > 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,)} Fixed all of the above. > (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. It is included only in the IKE_SA_INIT response. Section 7.2 says The 'Nonce Data' field is present in the REDIRECT payload only when the REDIRECT payload is sent in the IKE_SA_INIT response message. It MUST NOT be included in the REDIRECT payload if sent in an IKE_AUTH response or in a gateway- initiated redirect message. I hope this is sufficient. > 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". Please see my response to Pasi's email. This text has been updated. Redirect during the first IKE_AUTH response is always allowed even when EAP or multiple authentication is used. > 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. If the gateway decides to redirect after the first authentication, it would be the same as the exchange in section 6. The second authentication would not even happen. If the redirect is as a result of interaction with an external authentication server, then the redirect happens in the final IKE_AUTH message. > 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.". Fixed. > 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. Creating an IANA registry is fine with me. I will add text in the IANA considerations section. > 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. I added the following text. The IPv4 address, the IPv6 address or the FQDN of the new VPN gateway MUST be encoded as described in section 3.5 of [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. I think we should use the same IANA registry for both. > --- > > 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. Good point. In addition, RFC 4301 says 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. So we might not have to give an example at all. Here is the new text 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 practice, this means the new gateway either has to either use the same responder identity (IDr) as the original gateway, or both should be part of a group of responders that are authorized by the same PAD entry. See section 4.4.3.1 of [8] on using DNS names to represent a group of peers in a PAD entry. > 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.". I added the following text to the IANA section. This document creates a new namespace called the "Gateway Identity Type". This is used to indicate the type of information regarding the VPN gateway that is carried in the REDIRECT Section 7.2 and REDIRECTED_FROM Section 7.3 Notification payloads. The following values are assigned. 1 - IPv4 address of the new VPN gateway 2 - IPv6 address of the new VPN gateway 3 - FQDN of the new VPN gateway Values '0', and 4-255 are reserved. New values can be allocated by expert review. Vijay From Satinder.Singh@safenet-inc.com Mon May 4 21:17: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 A05253A6BA7 for ; Mon, 4 May 2009 21:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 7Fvv3Lz251us for ; Mon, 4 May 2009 21:17:36 -0700 (PDT) Received: from exprod7ob112.obsmtp.com (exprod7ob112.obsmtp.com [64.18.2.176]) by core3.amsl.com (Postfix) with SMTP id E113D3A6915 for ; Mon, 4 May 2009 21:17:35 -0700 (PDT) Received: from source ([202.122.134.5]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSf++McCqdU4PiawHlScvY+EVNZ12uleG@postini.com; Mon, 04 May 2009 21:19:02 PDT Received: from 172.25.13.59 ([172.25.13.59]) by NOI1EXCH002.sfnt.local ([172.25.10.6]) via Exchange Front-End Server 172.25.10.5 ([172.25.10.5]) with Microsoft Exchange Server HTTP-DAV ; Tue, 5 May 2009 04:16:06 +0000 Received: from ssingh-dev59 by 172.25.10.5; 05 May 2009 09:45:43 +0530 From: Satinder Singh To: IPSEC@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 05 May 2009 09:45:43 +0530 Message-Id: <1241496943.19817.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Subject: [IPsec] ipsec-request@ietf.org?subject=unsubscribe 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, 05 May 2009 04:17:36 -0000 The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. From yaronf@checkpoint.com Mon May 4 22:26: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 0A74F3A68B1 for ; Mon, 4 May 2009 22:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 DfiI0utM6YvO for ; Mon, 4 May 2009 22:26:24 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8D1723A694E for ; Mon, 4 May 2009 22:26:20 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D285F30C006; Tue, 5 May 2009 08:27:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7FF912CC001; Tue, 5 May 2009 08:27:45 +0300 (IDT) X-CheckPoint: {49FFF864-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 n455RiqO002244; Tue, 5 May 2009 08:27:44 +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, 5 May 2009 08:27:44 +0300 From: Yaron Sheffer To: Vijay Devarapalli , "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Tue, 5 May 2009 08:26:21 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAlz0n0ABSjcw5AAP6Y2w Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5AD0@il-ex01.ad.checkpoint.com> References: <808FD6E27AD4884E94820BC333B2DB7727F246D90A@NOK-EUMSG-01.mgdnok.nokia.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_0069_01C9CD5B.2B769700" 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: Tue, 05 May 2009 05:26:25 -0000 ------=_NextPart_000_0069_01C9CD5B.2B769700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > > 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. > > The current text assumes that the IKE SA is created and needs to be > deleted. > I don't think we need to show the INFORMATIONAL exchange. We are not > modifying anything in the delete procedure. We currently have the > following > text > > When the client > receives the IKE_AUTH response with the REDIRECT payload, it SHOULD > delete the existing IKEv2 security association with the gateway. > > Isn't this sufficient? > No, it's not sufficient. Unfortunately the word "delete" is ambiguous, and people can understand it either as "silently delete" or "delete and inform the peer". So I'd rather have "it SHOULD delete ... using an Informational exchange." Thanks, Yaron ------=_NextPart_000_0069_01C9CD5B.2B769700 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNTA1MjYyMVowIwYJKoZIhvcNAQkEMRYEFGb+NdAcLMQ8 GiFJIzE+svV3URBfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA tVNX2eXG+bKZ7LixUZyp5+5TTz0TcyN+spFyi6qkWeiNUjgKPQp4xWDPitAiGv5IRbH9rXrHx1Yn i4Sg0kS6zwaA6/u8v5PpY7L6c86vzDL2opWF7yn7hiishcscl+GPTQa1awLmZjtRTR7qDAceUjbL RfaWpZKxGinwRRvWe9bKIe7E2LVyAgQHxzG3QMwneoB/+gwjxIQrgtlXH1GDuDJp4mSlPmzD0jPj E+fEwtfqFnG6WM/W+9zLaTqScVE4GymGTW8mrOoPyXH7rOyPKwTqk6uHv6THRy8et5rM2FUz/LOA ExgjZ+H1TA5yKjwWPv5kfGKHFp27wVHskOmUsAAAAAAAAA== ------=_NextPart_000_0069_01C9CD5B.2B769700-- From vijay@wichorus.com Mon May 4 22: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 363233A6915 for ; Mon, 4 May 2009 22:58:26 -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 8G8uEyb8wrHC for ; Mon, 4 May 2009 22:58:25 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5F0B03A68F3 for ; Mon, 4 May 2009 22:58:25 -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: Tue, 5 May 2009 01:59:33 -0400 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5AD0@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAlz0n0ABSjcw5AAP6Y2wAAFQlSA= From: "Vijay Devarapalli" To: "Yaron Sheffer" , , 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, 05 May 2009 05:58:26 -0000 Hi Yaron,=20 > > The current text assumes that the IKE SA is created and needs to be=20 > > deleted. > > I don't think we need to show the INFORMATIONAL exchange.=20 > We are not=20 > > modifying anything in the delete procedure. We currently have the=20 > > following text > >=20 > > When the client > > receives the IKE_AUTH response with the REDIRECT=20 > payload, it SHOULD > > delete the existing IKEv2 security association with the gateway. > >=20 > > Isn't this sufficient? > >=20 > No, it's not sufficient. Unfortunately the word "delete" is=20 > ambiguous, and people can understand it either as "silently=20 > delete" or "delete and inform the peer". So I'd rather have=20 > "it SHOULD delete ... using an Informational exchange." The previous section already says this. Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload.=20 I guess you want this text repeated in section 6 too (?) Vijay From yaronf@checkpoint.com Mon May 4 23:54: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 74F423A6AE2 for ; Mon, 4 May 2009 23:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 4rcOWX8MEfzn for ; Mon, 4 May 2009 23:54:44 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D29CB3A699F for ; Mon, 4 May 2009 23:54:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 50FF530C006; Tue, 5 May 2009 09:56:09 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F20832CC001; Tue, 5 May 2009 09:56:08 +0300 (IDT) X-CheckPoint: {4A000D1A-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 n456u8qO021765; Tue, 5 May 2009 09:56:08 +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, 5 May 2009 09:56:08 +0300 From: Yaron Sheffer To: Vijay Devarapalli , "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Tue, 5 May 2009 09:56:06 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcmQG11xz3Y00zEpSza195DYpuB4qguSXpMgAlz0n0ABSjcw5AAP6Y2wAAFQlSAAAfMDcA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5AF4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5AD0@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_0080_01C9CD67.B534ED00" 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: Tue, 05 May 2009 06:54:45 -0000 ------=_NextPart_000_0080_01C9CD67.B534ED00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, "It SHOULD delete ... using the same procedure as Sec. 6"? Clarity of prose at the expense of the beauty :-( Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Tuesday, May 05, 2009 9:00 > To: Yaron Sheffer; Pasi.Eronen@nokia.com; ipsec@ietf.org > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 > > Hi Yaron, > > > > The current text assumes that the IKE SA is created and needs to be > > > deleted. > > > I don't think we need to show the INFORMATIONAL exchange. > > We are not > > > modifying anything in the delete procedure. We currently have the > > > following text > > > > > > When the client > > > receives the IKE_AUTH response with the REDIRECT > > payload, it SHOULD > > > delete the existing IKEv2 security association with the gateway. > > > > > > Isn't this sufficient? > > > > > No, it's not sufficient. Unfortunately the word "delete" is > > ambiguous, and people can understand it either as "silently > > delete" or "delete and inform the peer". So I'd rather have > > "it SHOULD delete ... using an Informational exchange." > > The previous section already says this. > > Once the client sends an acknowledgement to the gateway, it SHOULD > delete the existing security associations with the old gateway by > sending an Informational message with a DELETE payload. The gateway > MAY also decide to delete the security associations without any > signaling from the client, again by sending an Informational message > with a DELETE payload. > > I guess you want this text repeated in section 6 too (?) > > Vijay > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0080_01C9CD67.B534ED00 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNTA2NTYwNlowIwYJKoZIhvcNAQkEMRYEFHcYOHG16qYx jBnrjG3hdM+wQBTOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA nBoAfSUmAhIsteC7zBSdSxszQVQSLCzsb44lJqqOtCmKE0Z7KHrkIc+13k3ymShSUQrGRIvjiRG+ JcZ+0M6xIY+G2XNIHriqBYmX8JrAWGO9eZ6fdqxt+R1HV/mIVBMxyGqDXp7poR27qiZ+GLoQTY7r I2QGdZ6/tJeVX9u7XzKKfcafEmCJNuEaGtPpv972oUb2e6YIe39dxPVrDb8791p79FHEz6719P8Q nd8ZqSWJKqkuUJO4zY803PYniGdoL6AzPaaf0xbs8mjT60sTVRBRxO+hVYpEHjByl7gG+gM+swu2 Wlkayy4noSj6Xge1ifulORWy69MxH0S6o/xr7gAAAAAAAA== ------=_NextPart_000_0080_01C9CD67.B534ED00-- From kivinen@iki.fi Tue May 5 03:36: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 2277C3A6B36 for ; Tue, 5 May 2009 03:36:39 -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 3K5EMnmHCsw2 for ; Tue, 5 May 2009 03:36:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8736F3A6DED for ; Tue, 5 May 2009 03:35:51 -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 n45AbAKw013951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 13:37:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45Ab9mQ015566; Tue, 5 May 2009 13:37:09 +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: <18944.5845.767702.613952@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 13:37:09 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 05 May 2009 10:36:39 -0000 Pasi.Eronen@nokia.com writes: > What do you think of the proposed text here? > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html The NO_ADDITIONAL_SAS error should be added to the error list, and I am not completely happy with the last paragraph, i.e. it could be expanded bit more to explain the situation more, not just say "treated with caution". I am bit worried that implementors do not understand the difference with encrypted and MACed compared to the fact that the other peer has authenticated himself (i.e. sent AUTH payload). I think adding bit more text there to make that clear would be needed. -- kivinen@iki.fi From kivinen@iki.fi Tue May 5 03:46: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 0CE913A70CA for ; Tue, 5 May 2009 03:46:39 -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 xQy4Mwr4wfVz for ; Tue, 5 May 2009 03:46:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9031B3A6D2B for ; Tue, 5 May 2009 03:45: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 n45Al3QX003742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 13:47:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45Al3FV013515; Tue, 5 May 2009 13:47: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: <18944.6438.936229.687305@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 13:47:02 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min 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, 05 May 2009 10:46:39 -0000 Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > > 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. > > Well, nothing in RFC 4301 requires implementing the SPD internally as > an ordered list of entries; some kind of tree or associative array > data structure could work, too. The requirement for ordered list of > entries applies to the management UI, not the internals. > > So I think an implementation that treats the following two policies > equivalently *is* allowed by RFC 4301 and 4306: > > Policy A: > traffic on UDP ports 1000 MUST use ESP w/AES > traffic on UDP ports 1001 MUST use ESP w/AES > > Policy B: > traffic on UDP ports 1000-1001 MUST use ESP w/AES Perhaps, but it should not consider following policies equivalently: Policy A: traffic on UDP ports 1000 MUST use ESP w/AES or w/3DES traffic on UDP ports 1001 MUST use ESP w/AES Policy B: traffic on UDP ports 1000-1001 MUST use ESP w/AES meaning that it should delete the Child SA immediately when the one of the policy entries in the policy A was changed to include 2 algorithms. > My main concern was whether this (new SA MUST NOT be narrower than old > one, but MAY be wider) is a new requirement compared to RFC 4306... Does that really matter even if it is new requirement or not? Is there something wrong with that requirement, i.e what is the reason why we should not add that MUST NOT in document? As we have already argued quite long about whether it is new requirement or not, that really says that there was nothing that said it was clearly allowed before. I.e. mostly RFC4306 was silent about the issue, and by interpreting other MUSTs in RFC4301 and RFC4306 I think we can derive same "MUST NOT" requirement we added there. I.e. we are just clarifying RFC4306 to explicitly say something that could have beeen derived from very complex text combination from RFC4301 and RFC4306. I do not think we really must add that text, as I still think it can be derived from other part of specifications, but I think it would make it easier to understand how rekeying child SA is supposed to work. -- kivinen@iki.fi From kivinen@iki.fi Tue May 5 03:55: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 5B2673A6D25 for ; Tue, 5 May 2009 03:55:07 -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 TNOaxrsB+iUN for ; Tue, 5 May 2009 03:55:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AC7D83A6CDA for ; Tue, 5 May 2009 03:55: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 n45AuNQj017585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 13:56:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45AuNqu013647; Tue, 5 May 2009 13:56: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: <18944.6999.16110.790156@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 13:56:23 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A25@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5953@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25151BB@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A25@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , "Pasi.Eronen@nokia.com" Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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, 05 May 2009 10:55:07 -0000 Yaron Sheffer writes: > Hi Pasi, > > Tero's mail gives a clearer explanation of the situation than your proposed > text. Gluing the two together, how about replacing your last paragraph with: > > If the failure is related to creating the IKE SA (for example, > AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the > IKE_AUTH messages are encrypted and integrity protected, if the peer > receiving this notification has not authenticated the other end yet (or if > the peer fails to authenticate the other end for some reason), the > information needs to be treated with caution. More precisely, (assuming that > the MAC verifies correctly) the sender of the error indication is known to > be the responder of the IKE_SA_INIT exchange, but the sender's identity > cannot be assured. That is also good, but I would like to add also something about what implementations should do in that situation. Texts with "treated with caution" etc are fine for specifications, but are really annoying for implementors. What does that mean for my implementation? What kind of things should I do after that? I.e. it should tell following things: - If properly MACed error reply is received, the IKE SA creation fails, and no more retransmissions is sent. - This is not fatal permanent error as the identity of the other end could not be proven, meaning active attacker could have faked those messages. - Because of this it should still retry IKE SA creation from the beginning several times, before completely giving up (and perhaps enable multiple IKE_SA_INIT response processing described in section 2.4). -- kivinen@iki.fi From kivinen@iki.fi Tue May 5 04:01: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 944543A699F for ; Tue, 5 May 2009 04:01:40 -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 odIyesjN7Mcf for ; Tue, 5 May 2009 04:01:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A23663A7180 for ; Tue, 5 May 2009 04:01:32 -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 n45B2uqV017211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 14:02:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45B2ubL016381; Tue, 5 May 2009 14:02:56 +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: <18944.7392.81228.763316@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 14:02:56 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A34@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5952@il-ex01.ad.checkpoint.com> <18942.55110.31534.252679@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC5A34@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 5 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #57: Clarify D-H transform 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, 05 May 2009 11:01:40 -0000 Yaron Sheffer writes: > Hi Tero, > > Sec. 3.3.2 mentions that you negotiate a D-H group for ESP/AH, even though > you only need encryption and integrity transforms for these protocols. I > find it confusing, certainly for newcomers. For clarity, I suggest to add > after the table in Sec. 3.3.3, this text: > > Although ESP and AH do not directly include a Diffie Hellman exchange, a D-H > group MAY be negotiated for the Child SA. This allows the peers to employ > D-H in the CREATE_CHILD_SA exchange, providing Perfect Forward Secrecy for > the generated Child SA keys. Ok, I see no problem adding that text, and I think it really belongs to the 3.3.2 as you originally requested, not in 1.3.1/1.3.3. The section 1.3 section already describes about KE payloads and PFS: 1.3. The CREATE_CHILD_SA Exchange .... The CREATE_CHILD_SA request MAY optionally contain a KE payload for an additional Diffie-Hellman exchange to enable stronger guarantees of forward secrecy for the Child SA. The keying material for the Child SA is a function of SK_d established during the establishment of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange). -- kivinen@iki.fi From Pasi.Eronen@nokia.com Tue May 5 04:41:38 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 94FA13A7168 for ; Tue, 5 May 2009 04:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 Ai5hwl-WG7Nq for ; Tue, 5 May 2009 04:41:37 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B91E33A672F for ; Tue, 5 May 2009 04:41:20 -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 n45BgdLQ006743; Tue, 5 May 2009 14:42:41 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 14:42:27 +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, 5 May 2009 14:42:22 +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, 5 May 2009 13:42:22 +0200 From: To: Date: Tue, 5 May 2009 13:42:21 +0200 Thread-Topic: [IPsec] Reopening issue #12 Thread-Index: AcnNbtmMHnQpMwaBQqisUi6BseJ1dwABsp9w Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> In-Reply-To: <18944.6438.936229.687305@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: 05 May 2009 11:42:22.0925 (UTC) FILETIME=[8E0447D0:01C9CD76] 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, 05 May 2009 11:41:38 -0000 Tero Kivinen wrote: > > My main concern was whether this (new SA MUST NOT be narrower than > > old one, but MAY be wider) is a new requirement compared to RFC > > 4306... >=20 > Does that really matter even if it is new requirement or not? >=20 > Is there something wrong with that requirement, i.e what is the reason > why we should not add that MUST NOT in document? Since we're not creating IKEv2.1 here, IMHO we need to be somewhat conservative about adding new requirements. (But less conservative when we're just clarifying existing ones.) > As we have already argued quite long about whether it is new > requirement or not, that really says that there was nothing that said > it was clearly allowed before. I.e. mostly RFC4306 was silent about > the issue, and by interpreting other MUSTs in RFC4301 and RFC4306 I > think we can derive same "MUST NOT" requirement we added there. >=20 > I.e. we are just clarifying RFC4306 to explicitly say something that > could have beeen derived from very complex text combination from > RFC4301 and RFC4306. >=20 > I do not think we really must add that text, as I still think it can > be derived from other part of specifications, but I think it would > make it easier to understand how rekeying child SA is supposed to > work. I agree that rekeying is currently not very easy to understand. But e.g. early drafts of ikev2-clarifications (-00 and -01) included some text wondering about what exactly N(REKEY_SA) means (that is, what is different when you do/don't include REKEY_SA in CREATE_CHILD_SA exchange), and all of those reasons (which I think you also commented back then) would IMHO allow the new SA to be narrower than the old (even when N(REKEY_SA) is included)... =20 Best regards, Pasi From kivinen@iki.fi Tue May 5 04:49: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 0EE623A7186 for ; Tue, 5 May 2009 04:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.567, 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 i7CePIVMZYv3 for ; Tue, 5 May 2009 04:49:51 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 79F243A717D for ; Tue, 5 May 2009 04:49:50 -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 n45Bp9mW017097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 14:51:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45Bp9aJ017886; Tue, 5 May 2009 14:51:09 +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: <18944.10285.231843.727653@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 14:51:09 +0300 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 15 min Cc: IPsecme WG Subject: Re: [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, 05 May 2009 11:49:52 -0000 Vijay Devarapalli writes: > > In section 6 it should be: > > > > (IP_R:500 -> IP_I:500) > > <-- HDR(A,B), SK {IDr, [CERT,] AUTH, > > N(REDIRECT, New_GW_ID,)} > > Fixed all of the above. > > > (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. > > It is included only in the IKE_SA_INIT response. Section 7.2 says > > The 'Nonce Data' field > is present in the REDIRECT payload only when the REDIRECT payload is > sent in the IKE_SA_INIT response message. It MUST NOT be included in > the REDIRECT payload if sent in an IKE_AUTH response or in a gateway- > initiated redirect message. > > I hope this is sufficient. I found that later, but when I was reading the protocol description in section 6 I was wondering whether the nonce is included or not. It might be enough to explain that in the description of the payload itself, especially now if the N(REDIRECT, New_GW_ID,) in example clearly indicates nonce is empty. > > > 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". > > Please see my response to Pasi's email. This text has been updated. Redirect > during the first IKE_AUTH response is always allowed even when EAP or > multiple authentication is used. The text was not very clear about this. I will wait to see next version to see if that is clearer. > > 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. > > If the gateway decides to redirect after the first authentication, > it would be the same as the exchange in section 6. The second > authentication would not even happen. If initiator decides to use EAP, then the exchange is not same as in section 6, as the initiator has not proven his identity yet. The first authentication only authenticates the identity of the server. If Shared secret or certificates are used then both ends identities are authenticated during the first IKE_AUTH exchange. With multiple authentications the server can at any point decided that it has had enough authentication and ignore the ANOTHER_AUTH_FOLLOWS wish from client (as far as I understand the rfc4739), thus it can at any point when authentication is finished decided to finish the whole IKE_SA creation and send final AUTH. I think we need bit more text there explaining how this is supposed to work. > If the redirect is as a result of interaction with an external > authentication server, then the redirect happens in the final > IKE_AUTH message. How is the client supposed to know whether server decides to redirect as a result of interaction with an external authentication server, and make sure server cannot redirect during first IKE_AUTH exchange. The MUST in draft says that client MUST NOT accept redirect in any earlier message. As there is no way for client to know for this, there is no point of putting such requirement there. > I think we should use the same IANA registry for both. ... > I added the following text to the IANA section. > > This document creates a new namespace called the "Gateway Identity > Type". This is used to indicate the type of information regarding > the VPN gateway that is carried in the REDIRECT Section 7.2 and > REDIRECTED_FROM Section 7.3 Notification payloads. The following > values are assigned. > > 1 - IPv4 address of the new VPN gateway > 2 - IPv6 address of the new VPN gateway > 3 - FQDN of the new VPN gateway > > Values '0', and 4-255 are reserved. New values can be allocated by > expert review. So FQDN is allowed in the REDIRECTED_FROM payload too? It is bad idea to share the registries if they can have different values. We already had this problem in the IKEv2, as the encryption algorithms registry was shared with both IKEv2 and ESP, and not all of the algorithms could be used in IKEv2 (combined mode ciphers), and the registry didn't indicate this in any way. So either use two registries, or specify explicitly which values are usable in which payload. -- kivinen@iki.fi From kivinen@iki.fi Tue May 5 06:00: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 D9B2B3A6BFD for ; Tue, 5 May 2009 06:00:01 -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 wMFd-GDbkaPo for ; Tue, 5 May 2009 06:00:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7DE3A6918 for ; Tue, 5 May 2009 05:59: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 n45D1KMB017744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 16:01:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45D1Jxs017753; Tue, 5 May 2009 16:01:19 +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: <18944.14495.541311.36886@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 16:01:19 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min 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, 05 May 2009 13:00:01 -0000 Pasi.Eronen@nokia.com writes: > I agree that rekeying is currently not very easy to understand. But > e.g. early drafts of ikev2-clarifications (-00 and -01) included some > text wondering about what exactly N(REKEY_SA) means (that is, what is > different when you do/don't include REKEY_SA in CREATE_CHILD_SA > exchange), and all of those reasons (which I think you also > commented back then) would IMHO allow the new SA to be narrower > than the old (even when N(REKEY_SA) is included)... I originally also tought so, i.e. that is the reason this issue is here in the first place. I.e. if the narrower traffic selectors are allowed, then we MUST also have traffic selectors from the triggering packet. Then other people convinced me that if there would be reason for the rekeyed SA to have narrower traffic selectors that are currently used, then the SA would have been already deleted because it would have been against policy, thus such situation cannot ever happen. Check the original ticket description (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=1#L1). I do not really have strong opinion which way to go, but we either needs to make sure there is the triggering packet traffic selectors (which might be problematic if SA was rekeyed because of time) and the rekey can narrow down traffic selectors. Or we assume that narrowing case cannot happen, as the SAs were already deleted before they were rekeyed in such situations, and we can say that traffic selectors MUST NOT narrow down. -- kivinen@iki.fi From danmcd@sun.com Tue May 5 06:53:53 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 3693B3A6B78 for ; Tue, 5 May 2009 06:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 Przj+YkFH42x for ; Tue, 5 May 2009 06:53:51 -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 60DA43A686C for ; Tue, 5 May 2009 06:53:51 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n45DtHQc016453 for ; Tue, 5 May 2009 13:55:17 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n45DtHNC033805 for ; Tue, 5 May 2009 09:55:17 -0400 (EDT) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n45DkZDO017534 for ; Tue, 5 May 2009 09:46:35 -0400 (EDT) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n45DkZs1017533 for ipsec@ietf.org; Tue, 5 May 2009 09:46:35 -0400 (EDT) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 5 May 2009 09:46:35 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090505134635.GA17481@kebe.East.Sun.COM> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18944.14495.541311.36886@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) 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, 05 May 2009 13:53:53 -0000 On Tue, May 05, 2009 at 04:01:19PM +0300, Tero Kivinen wrote: > I do not really have strong opinion which way to go, but we either > needs to make sure there is the triggering packet traffic selectors > (which might be problematic if SA was rekeyed because of time) and the > rekey can narrow down traffic selectors. Or we assume that narrowing > case cannot happen, as the SAs were already deleted before they were > rekeyed in such situations, and we can say that traffic selectors MUST > NOT narrow down. Let's assume the worst-case behavior and see what happens: - An SA requires renewal due to time (e.g. a PF_KEY *SOFT lifetime* expiration), and it does not contain original-triggering-packet information. So an initiator just sends the selectors. Let's say it's some sort of remote-port-only protection: TSi = 0.0.0.0-255.255.255.255, proto any, port any TSr = 0.0.0.0-255.255.255.255, proto TCP, port 2112 - If the existing SA selector set matches or is a subset of the peer's SPD TS set, life is good. - If the responder now has a more narrow set than the expiring SA's selectors, (say some remote-peer's traffic for port 2112 is now treated differently) the responder can send TS_UNACCEPTABLE to an overly broad set of TSes. - The rekey then fails, and then the initiator's SA actually disappears due to time (e.g. a PF_KEY *HARD lifetime* expiration). The initiator tries again with no SA available, and it is treated like a brand-new negotiation (where triggering packet information is more readily available). If we go with "assume that the narrowing case cannot happen", even the above worst-case behavior will continue to work, so long as the responder does the right thing and rejects rekeying if the proposed traffic selectors are too broad for its policy. I would lean toward "assume that the narrowing case cannot happen", because if the narrowing case DOES happen, then even if SAs are still lying around, they can expire and negotiations can begin from scratch. It is much harder to include the triggering packet's data all of the time, because if an SA shared by many potential triggering packets, a time-expired renegotiation CANNOT happen. Dan From vijay@wichorus.com Tue May 5 08:00: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 0BC2C3A68CD for ; Tue, 5 May 2009 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 OvUW4ZCIXFH8 for ; Tue, 5 May 2009 08:00:01 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D73953A6781 for ; Tue, 5 May 2009 08:00:00 -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 ; Tue, 5 May 2009 15:01:26 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 05 May 2009 08:01:25 -0700 From: Vijay Devarapalli To: Tero Kivinen Message-ID: Thread-Topic: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08 Thread-Index: AcnNklwMZyMfQna86U+elBvCmuVLig== In-Reply-To: <18944.10285.231843.727653@fireball.kivinen.iki.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IPsecme WG Subject: Re: [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, 05 May 2009 15:00:02 -0000 Hi Tero, On 5/5/09 4:51 AM, "Tero Kivinen" wrote: >>> 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. >> >> If the gateway decides to redirect after the first authentication, >> it would be the same as the exchange in section 6. The second >> authentication would not even happen. > > If initiator decides to use EAP, then the exchange is not same as in > section 6, as the initiator has not proven his identity yet. The first > authentication only authenticates the identity of the server. > > If Shared secret or certificates are used then both ends identities > are authenticated during the first IKE_AUTH exchange. > > With multiple authentications the server can at any point decided that > it has had enough authentication and ignore the ANOTHER_AUTH_FOLLOWS > wish from client (as far as I understand the rfc4739), thus it can at > any point when authentication is finished decided to finish the whole > IKE_SA creation and send final AUTH. > > I think we need bit more text there explaining how this is supposed to > work. > >> If the redirect is as a result of interaction with an external >> authentication server, then the redirect happens in the final >> IKE_AUTH message. > > How is the client supposed to know whether server decides to redirect > as a result of interaction with an external authentication server, and > make sure server cannot redirect during first IKE_AUTH exchange. > > The MUST in draft says that client MUST NOT accept redirect in any > earlier message. > > As there is no way for client to know for this, there is no point of > putting such requirement there. Lets discuss the multiple auth case in today's virtual meeting. I have a slide on that. >> I think we should use the same IANA registry for both. > ... >> I added the following text to the IANA section. >> >> This document creates a new namespace called the "Gateway Identity >> Type". This is used to indicate the type of information regarding >> the VPN gateway that is carried in the REDIRECT Section 7.2 and >> REDIRECTED_FROM Section 7.3 Notification payloads. The following >> values are assigned. >> >> 1 - IPv4 address of the new VPN gateway >> 2 - IPv6 address of the new VPN gateway >> 3 - FQDN of the new VPN gateway >> >> Values '0', and 4-255 are reserved. New values can be allocated by >> expert review. > > So FQDN is allowed in the REDIRECTED_FROM payload too? No. I added text in both sections 7.2 and 7.3 that says which values are valid in the REDIRECT and REDIRECTED_FROM payload. > It is bad idea to share the registries if they can have different > values. We already had this problem in the IKEv2, as the encryption > algorithms registry was shared with both IKEv2 and ESP, and not all of > the algorithms could be used in IKEv2 (combined mode ciphers), and the > registry didn't indicate this in any way. > > So either use two registries, or specify explicitly which values are > usable in which payload. I did the latter. Vijay From kivinen@iki.fi Tue May 5 08:47: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 363F63A6D1A for ; Tue, 5 May 2009 08:47:07 -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 l+uABakVwPv4 for ; Tue, 5 May 2009 08:47:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C22C93A6D00 for ; Tue, 5 May 2009 08:46:58 -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 n45FmJXs019787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 18:48:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n45FmI4T019524; Tue, 5 May 2009 18:48: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: <18944.24514.841452.238086@fireball.kivinen.iki.fi> Date: Tue, 5 May 2009 18:48:18 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 3 min Subject: [IPsec] Resumption and NAT detection and changing ports 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, 05 May 2009 15:47:07 -0000 When should we switch to port 4500 if NAT is detected. I assume we change ports just after IKE_SESSION_RESUME exchange, before going to IKE_AUTH, just like in IKE_SA_INIT case too? That should be mentioned in the draft too. -- kivinen@iki.fi From mcr@sandelman.ca Tue May 5 12:26: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 356C83A6E68 for ; Tue, 5 May 2009 12:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 g1VEMChxxPRs for ; Tue, 5 May 2009 12:26:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id ECC7E3A71C8 for ; Tue, 5 May 2009 12:25:59 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id CDB03341FF for ; Tue, 5 May 2009 19:27:14 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7796D4E816 for ; Tue, 5 May 2009 15:27:13 -0400 (EDT) Message-ID: <4A009310.2020904@sandelman.ca> Date: Tue, 05 May 2009 15:27:12 -0400 From: Michael Richardson User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ipsec@ietf.org 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> In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 05 May 2009 19:26:19 -0000 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 That really seems like a bug in the spec to me. I know that in my code I don't get upset about such a situation, as I have unit test cases that were written when I didn't have child SA code at all. I wonder how many implementations really would get upset? From mcr@sandelman.ca Tue May 5 14:10: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 A59CD3A6BF6 for ; Tue, 5 May 2009 14:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 laugY6CbMCQa for ; Tue, 5 May 2009 14:10:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7E2713A6A76 for ; Tue, 5 May 2009 14:10:14 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 5356F341F0 for ; Tue, 5 May 2009 21:11:41 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 18E484E816 for ; Tue, 5 May 2009 17:11:40 -0400 (EDT) Message-ID: <4A00AB8B.6080505@sandelman.ca> Date: Tue, 05 May 2009 17:11:39 -0400 From: Michael Richardson User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ipsec@ietf.org References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> <20090505134635.GA17481@kebe.East.Sun.COM> In-Reply-To: <20090505134635.GA17481@kebe.East.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 05 May 2009 21:10:17 -0000 Dan McDonald described a worse case scenario. It had the advantage that communication that could continue did continue. It had the disadvantage that the traffic to port 2112 got delayed because we needed the packet contents to get the policy right. This is bad due to the delay. It required specifically: > - If the responder now has a more narrow set than the expiring SA's > selectors, (say some remote-peer's traffic for port 2112 is now > treated differently) the responder can send TS_UNACCEPTABLE to an > overly broad set of TSes. that the responder change it's policy slightly. As long as the responder does not change it's policy again, I think that subsequent rekeys may be fine. It's nice that the responder can change its policy to a policy that might in fact be a bit contradictory, yet communication continues. (If the initiator sent packets through the old SA that the responder's new policy does not allow, it may be able to drop those packets as being from the wrong SA, so the responder does not need to be overly paranoid and drop all SAs when it's policy changes. Whether this happens in practice depends a bit upon how the details of tunnel exit checks are done) {ps: I am using gmane.org to read the list via NNTP. These last three emails elicited a request to confirm from core3.amsl.com, which I think all the gmane.org people saw. I confirmed, but my emails did not show up, so I am resending via SMTP instead of NNTP Post. My appologies if this breaks the threading.} From mcr@sandelman.ca Tue May 5 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 324EC3A6A76 for ; Tue, 5 May 2009 14:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, 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 dW0Dt8DfEkbx for ; Tue, 5 May 2009 14:11:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id D3FD43A6BF6 for ; Tue, 5 May 2009 14:10:43 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id CAE3F341FE for ; Tue, 5 May 2009 21:12:10 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E72514E816 for ; Tue, 5 May 2009 17:12:09 -0400 (EDT) Message-ID: <4A00ABA9.4090201@sandelman.ca> Date: Tue, 05 May 2009 17:12:09 -0400 From: Michael Richardson User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ipsec@ietf.org References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Tue, 05 May 2009 21:11:49 -0000 Yaron Sheffer wrote: > Hi Ken, > > It seems to me this field is more trouble than it's worth. We are assuming > that the hardware will be enforcing a very simplistic security policy (don't > care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.) > and that the hardware is unable to perform anything more than extremely > basic packet parsing. Both assumptions may well be incorrect. And the cost > is in complicating the protocol and the endpoint implementations. Have we received any review yet from companies/individuals that actually build the hardware involved? (I'm out of that business for 8 years myself). From paul.hoffman@vpnc.org Tue May 5 18:38: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 EC1FD3A6AAE for ; Tue, 5 May 2009 18:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 pGHRIGMmaFSn for ; Tue, 5 May 2009 18:38:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C20843A6951 for ; Tue, 5 May 2009 18:38:50 -0700 (PDT) Received: from [75.101.18.87] (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 n461eDjO093356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 18:40:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 5 May 2009 18:37:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Recording of today's interim WG meeting 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, 06 May 2009 01:38:52 -0000 ... is available at ; it's about 90 megabytes (90 minutes). We will leave the slides from the meeting up at --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue May 5 18:41:38 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 8AD423A6C60 for ; Tue, 5 May 2009 18:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 lYybhW08Ft52 for ; Tue, 5 May 2009 18:41:37 -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 7C5A73A63C9 for ; Tue, 5 May 2009 18:40:43 -0700 (PDT) Received: from [75.101.18.87] (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 n461g7wJ093453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 May 2009 18:42:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 5 May 2009 18:42:05 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Draft minutes from the 2009-05-05 interim meeting 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, 06 May 2009 01:41:38 -0000 Please review the minutes and let us know if there are any omissions or inaccuracies. Please DO NOT use this thread to comment on the actual issues. --Paul Hoffman IPsecME WG interim meeting 2009-05-05 Agenda was bashed Roadmap hasn't been updated recently, but is expected to be soon, then maybe WG LC IPv6 considerations: waiting for a rev from Pasi, then Paul will take it to IPv6 folks (Content from slides not reflected here.) Traffic Visibility Gabriel Montenegro #104: Paul asked if this is additional integrity check A: no #93: Gabriel asked if people feel strongly about the next header field No one said they felt so Dan McDonald: I would prefer tunnel mode packets to have IPv[46], just like regular ESP. Less separate codepaths. Yaron: Let's close #84 first Form of next header will be based on #93 Heuristics Dan McDonald Yaron asked everyone to read this sometime soon Does anyone care about SCTP? Hannes: depends on the WG NSMurthy: are these two documents alternate proposals? This is about supporting legacy operating system platforms Paul said that the pseudocode was quite readable Tero: For SCTP, this is just one of the ways to do the checks Others can check deeper if they want Yaron: Should we have something in the pseudocode about amount of confidence you have gained? Tero: We have that, but there is no limit set Session Resumption Yaron Sheffer Major change: went to two round trips Slide 5: only blue is really needed in the ticket Red is "interesting" that is optional Certificates are optional depending on whether or not you want it in the state If the initiator wants to to change internal IP address, need to renegotiate Pasi: Blue things are kept as state and might be regenerated Black items are negotiated freshly Maybe need a new issue on change of ports Paul asked there was any opinions on two round trips Hannes likes it Michael believes 2RTT is necessary Yaron asked for mobile folks to speak about necessity of 1RTT No response Gabriel: Question on the address assignment. The example refers to IKE address assignment, but would there be any issues with "regular" address assignemnt (DHCP, RA-based)? Yoav: the "regular" address assignment affects the IP address of the client as seen by the gateway (or not - it may be behind NAT), and the change of external IP is allowed by the draft Dan: Good point Yoav. If client's address (behind a NAT or not) changes, the non-IKE address assignment protocol will have to deal. Jean-Michel Combes: slide 7, it is said SG should store IDr in ticket but in slide 5, IDr is "black" ... is it normal? (Missed Yaron's response) Gabriel: Pasi had a draft on bypassing PK operations in certain EAP-based auth exchanges, what is the implication with resumption (assuming such an approach were resurrected)? Redirect Vijay Devarapalli Changes after the 2nd WG Last Call Draft is ready to go Still one open issue Pasi agrees that we can drop #3 Tero points out that the server doesn't need to allow client to do another auth Will fix text to match wording in 4739 about "last" IKE_AUTH Will submit last draft today Paul explained the next steps IKEv2bis Paul Hoffman Issue #9: Tero: it's really about the IKE SA failing. Should recommend what the initiator should do. Paul: we don't want to mandate that, there are cases when you don't want to retry. Paul: please write the rationale, rather than the "what to do". Issue #12: Pasi: If it's a new MUST, I want to know that it's really essential. Issue #26: Tero: we have covered some of these. No further discussion. Issue #57: Paul will retry to paste the text into 3.3.2 or 3.3.3. Issue #58: Tero and Paul: yes, add to doc. Adjourned after about 90 minutes Attendees: Dan McDonald Dave Wierbowski Gabriel Montenegro Jean-Michel Combes Jouni Korhonen Key Grewal Manv Bhatia Michael Richardson NS Srinivasa Murthy Pasi Erornen Paul Hoffman Qiu Ying Richard Graveman Sheila Frankel Tero Kivenen Thomas Narten Vijay Devarapalli Yaron Sheffer Yoav Nir From yaronf@checkpoint.com Tue May 5 22:56: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 A1B2A3A6A5D for ; Tue, 5 May 2009 22:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 NGx98VKxQxeS for ; Tue, 5 May 2009 22:56:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D8E8A3A6A9E for ; Tue, 5 May 2009 22:55:44 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0AFAE30C001; Wed, 6 May 2009 08:57:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CC0E52CC003; Wed, 6 May 2009 08:57:10 +0300 (IDT) X-CheckPoint: {4A01266D-10000-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 n465vAqO015363; Wed, 6 May 2009 08:57:10 +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, 6 May 2009 08:57:10 +0300 From: Yaron Sheffer To: Tero Kivinen , "ipsec@ietf.org" Date: Wed, 6 May 2009 08:57:09 +0300 Thread-Topic: [IPsec] Resumption and NAT detection and changing ports Thread-Index: AcnNmQZmTG3CgyIARr2S+VXH3qnTLAAdmTAg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9AD011E4C@il-ex01.ad.checkpoint.com> References: <18944.24514.841452.238086@fireball.kivinen.iki.fi> In-Reply-To: <18944.24514.841452.238086@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_003B_01C9CE28.A34A50A0" MIME-Version: 1.0 Subject: Re: [IPsec] Resumption and NAT detection and changing ports 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, 06 May 2009 05:56:37 -0000 ------=_NextPart_000_003B_01C9CE28.A34A50A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree and will clarify. Issue #106. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Tuesday, May 05, 2009 18:48 > To: ipsec@ietf.org > Subject: [IPsec] Resumption and NAT detection and changing ports > > When should we switch to port 4500 if NAT is detected. > > I assume we change ports just after IKE_SESSION_RESUME exchange, > before going to IKE_AUTH, just like in IKE_SA_INIT case too? That > should be mentioned in the draft too. > -- > 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_003B_01C9CE28.A34A50A0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNjA1NTcwOVowIwYJKoZIhvcNAQkEMRYEFJuH6v5S0P4H Mm7x64Bg9qGLOX5sMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA NJv5P0IyueDHaLRNbELTzGY/9hRbOeweDDSy8V8rlw1/Vvyw5t5QBv7PdZjC6VikB1WYwuypcpqx upNOuLNpVsB8+Bt/xOAYU6o532gZu7joIi9KXfaNrz1BC8x4/WKnzX63XHfDbm+tGg7MzYCTT5j0 iD7LViepKhZbfwO967CYNXQ3cRUekqpS3APn+Jyw825fQbm1D3/D9jmrha0JkpSRymekOkFeepsu A92TSw8nQ3K7VRyo6t6lXrLRS1J3gVBVeyGDf1w5mW4BwvzJLfwiXmC9w293I43ORnt46wr87T0T QUCDeJkPt3BU21VGL2O8TyCsSd9jZ6qAYTFT3wAAAAAAAA== ------=_NextPart_000_003B_01C9CE28.A34A50A0-- From ynir@checkpoint.com Wed May 6 00:49: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 0BC073A6D54 for ; Wed, 6 May 2009 00:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 tOMEhyj8rB9h for ; Wed, 6 May 2009 00:49:22 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7D4393A68C4 for ; Wed, 6 May 2009 00:48:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8687430C001; Wed, 6 May 2009 10:50:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 340762CC003; Wed, 6 May 2009 10:50:22 +0300 (IDT) X-CheckPoint: {4A0140F3-10000-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 n467oKqP014560; Wed, 6 May 2009 10:50: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; Wed, 6 May 2009 10:50:13 +0300 From: Yoav Nir To: Michael Richardson , "ipsec@ietf.org" Date: Wed, 6 May 2009 10:52:54 +0300 Thread-Topic: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr Thread-Index: AcnNt6Cm9R8vV+JvQ1KV0yz6jmuXHgAZ+h8g Message-ID: <9FB7C7CE79B84449B52622B506C780361338598109@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> <4A009310.2020904@sandelman.ca> In-Reply-To: <4A009310.2020904@sandelman.ca> 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] 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, 06 May 2009 07:49:23 -0000 Michael Richardson wrote: > Yoav Nir wrote: > > Hi Raj > > =20 > > Matt is correct. There is no way in IKEv2 to do a phase1-only=20 > > exchange, and then wait for traffic to establish the child SAs. > > =20 > > While we do establish an IKE SA if the piggy-backed child SA failed=20 > > for whatever reason (bad selectors, no proposal chosen), we don't=20 > > allow for an IKE_AUTH exchange that is missing the child payloads. > > =20 > > An IKE_AUTH request without the TSi and TSr payloads is considered=20 > > malformed, and so MUST NOT be processed. Instead, you should reply=20 > > with INVALID_SYNTAX >=20 > That really seems like a bug in the spec to me. > I know that in my code I don't get upset about such a=20 > situation, as I have unit test cases that were written when I=20 > didn't have child SA code at all. I wonder how many=20 > implementations really would get upset? Mine wouldn't. But the spec is adamant.=20 Email secured by Check Point From mcr@marajade.sandelman.ca Wed May 6 05:59: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 266643A6D3F for ; Wed, 6 May 2009 05:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 BbIp6XYVzTA0 for ; Wed, 6 May 2009 05:59:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id CE2CB3A6EAB for ; Wed, 6 May 2009 05:57:33 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id CB002341EE for ; Wed, 6 May 2009 12:59:00 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A43454E811 for ; Wed, 6 May 2009 08:58:59 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338598109@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 06 May 2009 08:58:59 -0400 Message-ID: <7600.1241614739@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca 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, 06 May 2009 12:59:14 -0000 Let me suggest a situation where perhaps I would like to bring up an IKE_SA and not a CHILD_SA: it might be for just sending initial contact, and perhaps even a DELETE. I sometimes move quickly from being "outside" my IPsec gateway/firewall (such as being on wireless), to being wired behind the gateway, where I do not need IPsec. The DPD doesn't kick off fast enough, and my traffic goes to where I am no longer. It would be nice to bring up the IKE_SA (or... haha, resume it), just so that I can send a delete and/or initial_contact.=20 Seems like to do this, once needs to include a known-to-be-unacceptable CHILD_SA proposal. --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ From kivinen@iki.fi Wed May 6 06:08: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 2A1C53A69BC for ; Wed, 6 May 2009 06:08:15 -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 bgXBfaY9KIdi for ; Wed, 6 May 2009 06:08:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 558973A6967 for ; Wed, 6 May 2009 06:07: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 n46D9KEt002233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 May 2009 16:09:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n46D9Kkk002389; Wed, 6 May 2009 16:09:20 +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: <18945.35839.940017.435724@fireball.kivinen.iki.fi> Date: Wed, 6 May 2009 16:09:19 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <4A009310.2020904@sandelman.ca> 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> <4A009310.2020904@sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min 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, 06 May 2009 13:08:15 -0000 Michael Richardson writes: > 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 > > That really seems like a bug in the spec to me. > I know that in my code I don't get upset about such a situation, as I > have unit test cases that were written when I didn't have child SA code > at all. I wonder how many implementations really would get upset? We do. First thing we do when we receive packet, is to check that all mandatory payloads (ID, SA, TSi, TSr) are present, and if they are not, we immediately fail the exchange with INVALID_SYNTAX error. Also our API is built so that it is immediately to even start IKE SA creation at all, you start Child SA creation and that automatically also creates the IKE SA if that is not yet done. Also I do not consider that bug in specification. The idea is that you do not create IKE SA before you actually need it, thus only when you need Child SA. -- kivinen@iki.fi From wierbows@us.ibm.com Wed May 6 06:43: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 6EA5A3A6953 for ; Wed, 6 May 2009 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.404 X-Spam-Level: X-Spam-Status: No, score=-5.404 tagged_above=-999 required=5 tests=[AWL=1.194, 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 5ogRnr0TCwqy for ; Wed, 6 May 2009 06:43:22 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 98ED53A6D59 for ; Wed, 6 May 2009 06:42:33 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n46DcukF023630 for ; Wed, 6 May 2009 09:38:57 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n46DhrlZ154234 for ; Wed, 6 May 2009 09:43:53 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n46DhrjP029150 for ; Wed, 6 May 2009 09:43:53 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n46DhrKd029137 for ; Wed, 6 May 2009 09:43:53 -0400 In-Reply-To: <18945.35839.940017.435724@fireball.kivinen.iki.fi> To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Wed, 6 May 2009 09:43:52 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/06/2009 09:43:52 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFF3DDFDA37708f9e8a93df938690918c0ABBFF3DDFDA3770" Content-Disposition: inline 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, 06 May 2009 13:43:23 -0000 --0__=0ABBFF3DDFDA37708f9e8a93df938690918c0ABBFF3DDFDA3770 Content-type: text/plain; charset=US-ASCII Tero Kivinen writes: > Michael Richardson writes: > > 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 > > > > That really seems like a bug in the spec to me. > > I know that in my code I don't get upset about such a situation, as I > > have unit test cases that were written when I didn't have child SA code > > at all. I wonder how many implementations really would get upset? > > We do. > > First thing we do when we receive packet, is to check that all > mandatory payloads (ID, SA, TSi, TSr) are present, and if they are > not, we immediately fail the exchange with INVALID_SYNTAX error. > > Also our API is built so that it is immediately to even start IKE SA > creation at all, you start Child SA creation and that automatically > also creates the IKE SA if that is not yet done. > > Also I do not consider that bug in specification. The idea is that you > do not create IKE SA before you actually need it, thus only when you > need Child SA. We also verify that all mandatory payloads are present before processing a message and respond with INVALID_SYNTAX if they are not. Dave Wierbowski --0__=0ABBFF3DDFDA37708f9e8a93df938690918c0ABBFF3DDFDA3770 Content-type: text/html; charset=US-ASCII Content-Disposition: inline


Tero Kivinen writes:
> Michael Richardson writes:
> > 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
> >
> > That really seems like a bug in the spec to me.
> > I know that in my code I don't get upset about such a situation, as I
> > have unit test cases that were written when I didn't have child SA code
> > at all. I wonder how many implementations really would get upset?
>
> We do.
>
> First thing we do when we receive packet, is to check that all
> mandatory payloads (ID, SA, TSi, TSr) are present, and if they are
> not, we immediately fail the exchange with INVALID_SYNTAX error.
>
> Also our API is built so that it is immediately to even start IKE SA
> creation at all, you start Child SA creation and that automatically
> also creates the IKE SA if that is not yet done.
>
> Also I do not consider that bug in specification. The idea is that you
> do not create IKE SA before you actually need it, thus only when you
> need Child SA.

We also verify that all mandatory payloads are present before processing
a message and respond with INVALID_SYNTAX if they are not.
 

Dave Wierbowski





--0__=0ABBFF3DDFDA37708f9e8a93df938690918c0ABBFF3DDFDA3770-- From ynir@checkpoint.com Wed May 6 06:50: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 CEF463A6935 for ; Wed, 6 May 2009 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 UetxHSxM2+CB for ; Wed, 6 May 2009 06:50:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 554793A6A72 for ; Wed, 6 May 2009 06:50:05 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6750930C003; Wed, 6 May 2009 16:51:31 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1377B2CC004; Wed, 6 May 2009 16:51:31 +0300 (IDT) X-CheckPoint: {4A019595-10000-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 n46DpUqO000546; Wed, 6 May 2009 16:51:30 +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, 6 May 2009 16:51:30 +0300 From: Yoav Nir To: Michael Richardson , "ipsec@ietf.org" Date: Wed, 6 May 2009 16:54:12 +0300 Thread-Topic: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr Thread-Index: AcnOSq3CEEE6Vtb6TcWa4zLXi9wKPAABCHLg Message-ID: <9FB7C7CE79B84449B52622B506C7803613385981A8@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> In-Reply-To: <7600.1241614739@marajade.sandelman.ca> 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] 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, 06 May 2009 13:50:49 -0000 Hi Michael=20 > Let me suggest a situation where perhaps I would like to=20 > bring up an IKE_SA and not a CHILD_SA: it might be for just=20 > sending initial contact, and perhaps even a DELETE. >=20 > I sometimes move quickly from being "outside" my IPsec=20 > gateway/firewall (such as being on wireless), to being wired=20 > behind the gateway, where I do not need IPsec. The DPD=20 > doesn't kick off fast enough, and my traffic goes to where I=20 > am no longer. It would be nice to bring up the IKE_SA (or...=20 > haha, resume it), just so that I can send a delete and/or=20 > initial_contact.=20 A far more common situation is when I'm "outside", not moving anywhere, and= I want to connect. I haven't even opened my mail client yet, or launched = the browser (because those thing hate it when the VPN client changes routin= g to addresses they are trying to reach). The reason I want to connect before everything else, is that connecting inv= olves some effort (typing the PKCS#12 password, entering a username and pas= sword, copying the OTP from the cellphone to the computer...). I want to ge= t this over with, but there's still no packet to derive selectors from. With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't = do Main Mode without attempting Quick Mode. > Seems like to do this, once needs to include a=20 > known-to-be-unacceptable CHILD_SA proposal. Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed eve= n if the piggy-backed CHILD_SA fails. =20 Now I would never suggest that anyone use a traffic selectors type from the= private range (241-255) which is almost guaranteed to fail... Yoav= Email secured by Check Point From yaronf@checkpoint.com Wed May 6 09:06: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 CF0533A6CCE for ; Wed, 6 May 2009 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 6e4EZgp-GOtA for ; Wed, 6 May 2009 09:06:05 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C76783A6AED for ; Wed, 6 May 2009 09:04:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 29B4430C001; Wed, 6 May 2009 19:06:13 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F034D29C001 for ; Wed, 6 May 2009 19:06:12 +0300 (IDT) X-CheckPoint: {4A01B525-10000-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 n46G6CqO009120 for ; Wed, 6 May 2009 19:06:12 +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, 6 May 2009 19:06:12 +0300 From: Yaron Sheffer To: IPsecme WG Date: Wed, 6 May 2009 19:06:10 +0300 Thread-Topic: Issue #105, was: [IPsec] Draft minutes from the 2009-05-05 interim meeting Thread-Index: AcnN7ArUeG2ggAJdTnOh68Dg1ZYjUwAeAjoA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9AD011F82@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_0068_01C9CE7D.B7E064A0" MIME-Version: 1.0 Subject: [IPsec] Issue #105, was: Draft minutes from the 2009-05-05 interim meeting 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, 06 May 2009 16:06:11 -0000 ------=_NextPart_000_0068_01C9CE7D.B7E064A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Session Resumption [...] > Gabriel: Pasi had a draft on bypassing PK operations in certain > EAP-based auth exchanges, what is the implication with resumption > (assuming such an approach were resurrected)? We recently resurrected this draft, http://tools.ietf.org/html/draft-eronen-ipsec-ikev2-eap-auth-06. It shouldn't affect session resumption, other than you need to maintain the authentication method (certs, pre-shared secret, regular EAP, non-PKI EAP) in the ticket state. I opened Issue #105 for this. Thanks, Yaron ------=_NextPart_000_0068_01C9CE7D.B7E064A0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUwNjE2MDYxMFowIwYJKoZIhvcNAQkEMRYEFGAt92wqbOA2 EaOc+GPRjz+YdvGRMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA MwpLcfWai2izbMRF0OfI6OJjba0rlFqi0/7wpv/F2BGAsoyZAsNiK4MeR/ZSJbah5jPUdERiH5Lk 1BsKjEjaQ+HPZLQEvmmfYjdi6yVemhim8iZNo5CyzQZipRqTOs6NiXeyzx/wMWjKqImrrrvystAa DnSiyPcMSZ5E2umOvW/Rknc5C57kDgnClZi0Ob1N+XpcfEX2sa/p+qGhW5Sx94zXVwnK19CIerkG 5YLYyKiEVRhQgZxe/XrcROtEPRFl9zoa4v6cMYluQ66j7R2HHOZVw1YwxpTNh+K7nnLxsMt0tBgO Mt1em4WCfCnjvya3Ojx10vjx7lQaETkkCWqnDQAAAAAAAA== ------=_NextPart_000_0068_01C9CE7D.B7E064A0-- From kivinen@iki.fi Thu May 7 02:52: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 11F3E3A6B9C for ; Thu, 7 May 2009 02:52:44 -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 cGHONMi3pIWf for ; Thu, 7 May 2009 02:52:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E16F93A6B17 for ; Thu, 7 May 2009 02:52: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 n479s4Yq015815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 12:54:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n479s3g8015863; Thu, 7 May 2009 12:54: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: <18946.44987.506262.354498@fireball.kivinen.iki.fi> Date: Thu, 7 May 2009 12:54:03 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <7600.1241614739@marajade.sandelman.ca> 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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min 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: Thu, 07 May 2009 09:52:44 -0000 Michael Richardson writes: > > Let me suggest a situation where perhaps I would like to bring up > an IKE_SA and not a CHILD_SA: it might be for just sending initial > contact, and perhaps even a DELETE. > > I sometimes move quickly from being "outside" my IPsec gateway/firewall > (such as being on wireless), to being wired behind the gateway, where I > do not need IPsec. The DPD doesn't kick off fast enough, and my traffic > goes to where I am no longer. It would be nice to bring up the IKE_SA > (or... haha, resume it), just so that I can send a delete and/or > initial_contact. Or MOBIKE, and just move tunnel end point to your new location. > Seems like to do this, once needs to include a known-to-be-unacceptable > CHILD_SA proposal. Or just create valid Child SA, and then send delete to IKE SA which will take care of the IKE SA and Child SA. The extra Child SA created there do not really cost anything. The cpu cost will be few symmetric hashing and macin etc, so I do not really consider this worth of one extra mode again. -- kivinen@iki.fi From kivinen@iki.fi Thu May 7 02:57: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 8B85E3A6FB7 for ; Thu, 7 May 2009 02:57:30 -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 HMh5UtBu9Tfv for ; Thu, 7 May 2009 02:57:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3E83A6F30 for ; Thu, 7 May 2009 02:57:29 -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 n479wqTT015327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2009 12:58:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n479wphd014344; Thu, 7 May 2009 12:58: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: <18946.45275.605400.566221@fireball.kivinen.iki.fi> Date: Thu, 7 May 2009 12:58:51 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613385981A8@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@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: "ipsec@ietf.org" , Michael Richardson 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: Thu, 07 May 2009 09:57:30 -0000 Yoav Nir writes: > A far more common situation is when I'm "outside", not moving > anywhere, and I want to connect. I haven't even opened my mail > client yet, or launched the browser (because those thing hate it > when the VPN client changes routing to addresses they are trying to > reach). > > The reason I want to connect before everything else, is that > connecting involves some effort (typing the PKCS#12 password, > entering a username and password, copying the OTP from the cellphone > to the computer...). I want to get this over with, but there's still > no packet to derive selectors from. Most likely in such situations you already have your configuration set up so you know that you are going to request IP-address from inside, and you are going to use traffic selectors from that IP-address to the whole subnet on the other, end so you will propose the any to any traffic selectors to the server anyways. Then server will assign IP-address, narrow the traffic selectors down and then create the Child SA at the same time. All of this could be tied up to the virtual interface up event, i.e. when you say "ifconfig vipsec0 up" or similar (or pressing the "Connect" gui button, which will do the same thing internally), that will trigger the IKE negotiation and all of this. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Fri May 8 04:04: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 C43803A6D82 for ; Fri, 8 May 2009 04:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 E8tlWTi-WXh6 for ; Fri, 8 May 2009 04:04:40 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 98B383A6A39 for ; Fri, 8 May 2009 04:04:39 -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 n48B5oPZ028817; Fri, 8 May 2009 14:06:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 14:05:31 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 14:05:26 +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; Fri, 8 May 2009 13:05:25 +0200 From: To: Date: Fri, 8 May 2009 13:05:25 +0200 Thread-Topic: [IPsec] Reopening issue #12 Thread-Index: AcnNgaWQmHd3opgiQCifd9HxaFSkYQCSWf8A Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2582D2D@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> In-Reply-To: <18944.14495.541311.36886@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: 08 May 2009 11:05:26.0054 (UTC) FILETIME=[E3E5DC60:01C9CFCC] 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: Fri, 08 May 2009 11:04:40 -0000 Tero Kivinen wrote: > I originally also tought so, i.e. that is the reason this issue is > here in the first place. I.e. if the narrower traffic selectors are > allowed, then we MUST also have traffic selectors from the triggering > packet. >=20 > Then other people convinced me that if there would be reason for the > rekeyed SA to have narrower traffic selectors that are currently used, > then the SA would have been already deleted because it would have been > against policy, thus such situation cannot ever happen. Hmm... but it may mean that a narrowing algorithm that takes as inputs the proposed TSi/TSr and your own policy isn't sufficient any more. The algorithm also needs to consider the old SA. If the original CREATE_CHILD_SA request also included the selectors from the triggering packet, and the responder had multiple possible subsets it could narrow to, it picked a subset that included the triggering packet. When rekeying, the triggering packet isn't there necessarily, but the responder still needs to pick the *same* subset (and not one of the other acceptable subsets). Best regards, Pasi=20 From kivinen@iki.fi Fri May 8 04: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 61D463A711A for ; Fri, 8 May 2009 04:59:02 -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 hT2xZIObwQD7 for ; Fri, 8 May 2009 04:59:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD6A3A6A99 for ; Fri, 8 May 2009 04:59:00 -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 n48C0Nuf029105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 15:00:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n48C0Md0022371; Fri, 8 May 2009 15:00:22 +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: <18948.7894.663276.512447@fireball.kivinen.iki.fi> Date: Fri, 8 May 2009 15:00:22 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F2582D2D@NOK-EUMSG-01.mgdnok.nokia.com> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F2582D2D@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 9 min 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: Fri, 08 May 2009 11:59:02 -0000 Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > I originally also tought so, i.e. that is the reason this issue is > > here in the first place. I.e. if the narrower traffic selectors are > > allowed, then we MUST also have traffic selectors from the triggering > > packet. > > > > Then other people convinced me that if there would be reason for the > > rekeyed SA to have narrower traffic selectors that are currently used, > > then the SA would have been already deleted because it would have been > > against policy, thus such situation cannot ever happen. > > Hmm... but it may mean that a narrowing algorithm that takes as inputs > the proposed TSi/TSr and your own policy isn't sufficient any more. > The algorithm also needs to consider the old SA. Only if your old SAs selectors are not based on one SPD rule. If you do not combine multiple SPD entries and share an SA with them, then you can simply take same (decorrelated) SPD entry and TSi/TSr and end up with the exactly same traffic selectors as before. If you do not end up with same traffic selectors, then that means that the old SA had traffic selectors which were not allowed by your policy, thus it would have been removed. > If the original CREATE_CHILD_SA request also included the selectors > from the triggering packet, and the responder had multiple possible > subsets it could narrow to, it picked a subset that included the > triggering packet. When rekeying, the triggering packet isn't there > necessarily, but the responder still needs to pick the *same* subset > (and not one of the other acceptable subsets). Yes, this is true. In a sense you can consider the old traffic selectors from the old SA as "triggering packet", so in that sense you do conside the old SA. We really want to make sure the rekeyed SA will have traffic selectors which are usable for the traffic which went through the SA before rekey. -- kivinen@iki.fi From ynir@checkpoint.com Sun May 10 04:03: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 5B74E3A69B8 for ; Sun, 10 May 2009 04:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkj-1AkaYHYH for ; Sun, 10 May 2009 04:03:56 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8310A3A68D6 for ; Sun, 10 May 2009 04:03:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 92920200E09; Sun, 10 May 2009 14:05:25 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4D985200E00 for ; Sun, 10 May 2009 14:05:25 +0300 (IDT) X-CheckPoint: {4A06B46F-10000-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 n4AB5OqO029853 for ; Sun, 10 May 2009 14:05:24 +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, 10 May 2009 14:05:24 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Sun, 10 May 2009 14:08:17 +0300 Thread-Topic: Issue #107 Thread-Index: AcnO+m9vWzYFefd7Skun5nNJKGDPawCZPwKw Message-ID: <9FB7C7CE79B84449B52622B506C780361338598395@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> In-Reply-To: <18946.45275.605400.566221@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 #107 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, 10 May 2009 11:03:57 -0000 Hi all I've submitted issue #107 about certificate encoding. IMO it's not clear how certificate chains are to be encoded in IKEv2. http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 Yoav Email secured by Check Point From paul.hoffman@vpnc.org Sun May 10 12:32: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 8DCCD3A6CEC for ; Sun, 10 May 2009 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 498sldTcUoFw for ; Sun, 10 May 2009 12:32:14 -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 13FA63A6F02 for ; Sun, 10 May 2009 12:32:06 -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 n4AJXS2V003427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 12:33:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338598395@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com> Date: Sun, 10 May 2009 12:33:27 -0700 To: Yoav Nir , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #107 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, 10 May 2009 19:32:14 -0000 At 2:08 PM +0300 5/10/09, Yoav Nir wrote: >Hi all > >I've submitted issue #107 about certificate encoding. > >IMO it's not clear how certificate chains are to be encoded in IKEv2. > >http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 That would be the CertBundle, also described in section 3.6. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun May 10 14:56: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 4225B3A6BFB for ; Sun, 10 May 2009 14:56:34 -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 G5GP6pQ-T38T for ; Sun, 10 May 2009 14:56:33 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0AE9F3A6B21 for ; Sun, 10 May 2009 14:56:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 656E62CC003; Mon, 11 May 2009 00:58:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D0E9B200E08; Mon, 11 May 2009 00:58:01 +0300 (IDT) X-CheckPoint: {4A074D5D-10000-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 n4ALw1qO009326; Mon, 11 May 2009 00:58: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, 11 May 2009 00:58:00 +0300 From: Yoav Nir To: Paul Hoffman , "ipsec@ietf.org" Date: Mon, 11 May 2009 00:53:56 +0300 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnRpjaLFwjQJONzTcKzFYSrqTofiAAE5qEJ Message-ID: <9FB7C7CE79B84449B52622B506C780361341113027@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@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 Subject: Re: [IPsec] Issue #107 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, 10 May 2009 21:56:34 -0000 Paul Hoffman wrote: > > At 2:08 PM +0300 5/10/09, Yoav Nir wrote: > >Hi all > > > >I've submitted issue #107 about certificate encoding. > > > >IMO it's not clear how certificate chains are to be encoded in IKEv2. > > > >http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 > > That would be the CertBundle, also described in section 3.6. > > --Paul Hoffman, Director > --VPN Consortium And there's the problem. There is no certificate payload encoding for a cer= tificate bundle. Only hash-and-URL So what do I do if the peer sent a certificate request for the root CA, and= I have a certificate by a sub-CA, and we don't use hash-and-URL? I can't = use a bundle in a Type #4 encoding, but I do need to send the subordinate C= A certificate as well. Email secured by Check Point From paul.hoffman@vpnc.org Sun May 10 15:17: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 9B4323A68F4 for ; Sun, 10 May 2009 15:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 GUT74NEKViXM for ; Sun, 10 May 2009 15:17:56 -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 8151E3A68F1 for ; Sun, 10 May 2009 15:17:56 -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 n4AMJLKM012541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 May 2009 15:19:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FB7C7CE79B84449B52622B506C780361341113027@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> Date: Sun, 10 May 2009 15:19:20 -0700 To: Yoav Nir , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #107 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, 10 May 2009 22:17:57 -0000 At 12:53 AM +0300 5/11/09, Yoav Nir wrote: >Paul Hoffman wrote: >> >> At 2:08 PM +0300 5/10/09, Yoav Nir wrote: >> >Hi all >> > >> >I've submitted issue #107 about certificate encoding. >> > >> >IMO it's not clear how certificate chains are to be encoded in IKEv2. >> > >> >http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 >> >> That would be the CertBundle, also described in section 3.6. >> >> --Paul Hoffman, Director >> --VPN Consortium > >And there's the problem. There is no certificate payload encoding for a certificate bundle. Only hash-and-URL > >So what do I do if the peer sent a certificate request for the root CA, and I have a certificate by a sub-CA, and we don't use hash-and-URL? I can't use a bundle in a Type #4 encoding, but I do need to send the subordinate CA certificate as well. You can: a) start using hash-and-url b) hope your peer has the sub-CA c) write an extension to 4306 that allows bundles in CERT Doing (a) is the most interoperable, but you're probably save with (b) in a typical closed network. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun May 10 23:56: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 7294A3A6AC2 for ; Sun, 10 May 2009 23:56:35 -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 SoE0XWw35+yM for ; Sun, 10 May 2009 23:56:34 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 17D2D3A6A84 for ; Sun, 10 May 2009 23:56:33 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BFE1C2CC003; Mon, 11 May 2009 09:58:03 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8059A2CC001; Mon, 11 May 2009 09:58:03 +0300 (IDT) X-CheckPoint: {4A07CBEA-10000-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 n4B6w0qQ023453; Mon, 11 May 2009 09:58:02 +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, 11 May 2009 09:58:01 +0300 From: Yoav Nir To: Paul Hoffman , "ipsec@ietf.org" Date: Mon, 11 May 2009 10:00:57 +0300 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnRvWC7wZaDeI3OSqCah0lOkz5khgASKMPg Message-ID: <9FB7C7CE79B84449B52622B506C7803613410ED4F6@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@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 Subject: Re: [IPsec] Issue #107 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, 11 May 2009 06:56:35 -0000 Paul Hoffman wrote:=20 > > At 12:53 AM +0300 5/11/09, Yoav Nir wrote: > >Paul Hoffman wrote: > >> > >> At 2:08 PM +0300 5/10/09, Yoav Nir wrote: > >> >Hi all > >> > > >> >I've submitted issue #107 about certificate encoding. > >> > > >> >IMO it's not clear how certificate chains are to be=20 > encoded in IKEv2. > >> > > >> >http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 > >> > >> That would be the CertBundle, also described in section 3.6. > >> > >> --Paul Hoffman, Director > >> --VPN Consortium > > > >And there's the problem. There is no certificate payload=20 > encoding for a=20 > >certificate bundle. Only hash-and-URL > > > >So what do I do if the peer sent a certificate request for=20 > the root CA, and I have a certificate by a sub-CA, and we=20 > don't use hash-and-URL? I can't use a bundle in a Type #4=20 > encoding, but I do need to send the subordinate CA=20 > certificate as well. >=20 > You can: >=20 > a) start using hash-and-url >=20 > b) hope your peer has the sub-CA >=20 > c) write an extension to 4306 that allows bundles in CERT >=20 > Doing (a) is the most interoperable, but you're probably save=20 > with (b) in a typical closed network. Or I can go with option (d) and send multiple CERT payloads, as Pasi sugges= ted here: http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html (thanks, Yaron) Either way, we should have it clear what is and is not allowed in section 3= .6.= Email secured by Check Point From Pasi.Eronen@nokia.com Mon May 11 02:05: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 DC90E3A6AD7 for ; Mon, 11 May 2009 02:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 4MeSRFkZI3lj for ; Mon, 11 May 2009 02:05:16 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C54DD3A67EB for ; Mon, 11 May 2009 02:05: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 n4B96jYv022043; Mon, 11 May 2009 04:06:46 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 12:06:41 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 12:06:36 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 11 May 2009 11:06:35 +0200 From: To: , , Date: Mon, 11 May 2009 11:06:35 +0200 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnRvWC7wZaDeI3OSqCah0lOkz5khgASKMPgAARG5XA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613410ED4F6@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: 11 May 2009 09:06:36.0606 (UTC) FILETIME=[C9A7ADE0:01C9D217] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #107 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, 11 May 2009 09:05:17 -0000 Yoav Nir wrote: > > You can: > > > > a) start using hash-and-url > > > > b) hope your peer has the sub-CA > > > > c) write an extension to 4306 that allows bundles in CERT > > > > Doing (a) is the most interoperable, but you're probably save > > with (b) in a typical closed network. >=20 > Or I can go with option (d) and send multiple CERT payloads, as Pasi > suggested here: http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html >=20 > (thanks, Yaron) >=20 > Either way, we should have it clear what is and is not allowed in > section 3.6. I thought this was already clear in RFC 4306, but apparently it's not as clear as it should be. Section 1.2 says "...might also send its certificate(s) in CERT payload(s)..." -- so multiple CERT payloads are allowed -- but Section 3.6 is indeed a bit silent about this. Best regards, Pasi From ynir@checkpoint.com Mon May 11 02:18:33 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 996943A6A85 for ; Mon, 11 May 2009 02:18:33 -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 MWxlvfL-aKMi for ; Mon, 11 May 2009 02:18:32 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 36D903A67DD for ; Mon, 11 May 2009 02:18:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 26D5829C001; Mon, 11 May 2009 12:20:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D63DB200E0F; Mon, 11 May 2009 12:20:01 +0300 (IDT) X-CheckPoint: {4A07ED2F-10000-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 n4B9K1qO002473; Mon, 11 May 2009 12:20: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, 11 May 2009 12:20:00 +0300 From: Yoav Nir To: "Pasi.Eronen@nokia.com" , "paul.hoffman@vpnc.org" , "ipsec@ietf.org" Date: Mon, 11 May 2009 12:22:57 +0300 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnRvWC7wZaDeI3OSqCah0lOkz5khgASKMPgAARG5XAAAKAoUA== Message-ID: <9FB7C7CE79B84449B52622B506C7803613410ED52E@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@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 Subject: Re: [IPsec] Issue #107 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, 11 May 2009 09:18:33 -0000 Pasi.Eronen wrote: >=20 > Yoav Nir wrote: > > > You can: > > > > > > a) start using hash-and-url > > > > > > b) hope your peer has the sub-CA > > > > > > c) write an extension to 4306 that allows bundles in CERT > > > > > > Doing (a) is the most interoperable, but you're probably=20 > save with=20 > > > (b) in a typical closed network. > >=20 > > Or I can go with option (d) and send multiple CERT=20 > payloads, as Pasi=20 > > suggested here:=20 > http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html > >=20 > > (thanks, Yaron) > >=20 > > Either way, we should have it clear what is and is not allowed in=20 > > section 3.6. >=20 > I thought this was already clear in RFC 4306, but apparently=20 > it's not as clear as it should be. Section 1.2 says "...might=20 > also send its > certificate(s) in CERT payload(s)..." -- so multiple CERT=20 > payloads are allowed -- but Section 3.6 is indeed a bit=20 > silent about this. >=20 > Best regards, > Pasi So how about replacing this: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. With this: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding if a chain of certificates needs to be sent, multiple CERT payloads MUST be used, only the=20 first of which holds the public key used to validate the sender's AUTH payload. Email secured by Check Point From kivinen@iki.fi Mon May 11 05:21: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 A100F3A6C14 for ; Mon, 11 May 2009 05:21:44 -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 VWnaT93rl5uZ for ; Mon, 11 May 2009 05:21:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA083A6BCE for ; Mon, 11 May 2009 05:21: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 n4BCN2xw014546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 15:23:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4BCN1Ln015503; Mon, 11 May 2009 15:23:01 +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: <18952.6309.950313.942432@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 15:23:01 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C780361338598395@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 21 min Cc: "ipsec@ietf.org" Subject: [IPsec] Issue #107 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, 11 May 2009 12:21:44 -0000 Yoav Nir writes: > I've submitted issue #107 about certificate encoding. > > IMO it's not clear how certificate chains are to be encoded in IKEv2. > > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107 If certificate chain is sent using X.509 certificate - signature (4) format, then it is sent as multiple separate CERT payloads. There is text about this in multiple places in the RFC4306. In 1.2 it clearly indicates that there can be multiple CERT payloads and the first certificate provided must contain the public key used to verify AUTH field: ---------------------------------------------------------------------- 1.2. The Initial Exchanges ... 2.15). It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s). If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field. The optional payload ... ---------------------------------------------------------------------- and then there is the text you put to the #107: ---------------------------------------------------------------------- 3.6. Certificate Payload ... X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. ... Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. ... ---------------------------------------------------------------------- So if that format 4 (and 7) is used then multiple CERT payloads are used and first of the CERT payloads must be the one matching the public key of the AUTH payload. If other formats which support bundles are used (RCKS#7 wrapped (1), hash and url of X.509 bundle (13)) are used then there usually is only one payload containining the whole chain. As the current document leaves PCKS#7 wrapped X.509 certificates with very little specification implementations could also do things differently there (i.e. wrap each certificate separately or do something else). For the X.509 bundle I think the format is more clear and only one CERT payload is sent containing hash and url of all certificates and crls needed (and first certificate there is the one used for AUTH payload). It might be good to add bit more text to the X.509 Certificate - Signature (4) text, i.e something like: "If multiple certificates are sent, then each of them is encoded as separate CERT payload.". Note, that some implementations might send certificates in multiple formats, i.e. they might send RAW RSA key first, than then provide for example HASH and URL of X.509 bundle also. Depending on the recipient it might jsut use the RAW RSA key or might might actually fetch the bundle and use that. Note, that the ordering requirement that first certificate provided MUST contain the public key used to verify AUTH field, is for the first certificate provided, it is not separately for each certificate encoding type, i.e. if first "certificate" provided happened to be in RAW RSA format, then even if the same public key is given out in different format too (for example as X.509 cetificate), there is no ordering requirements there anymore. Of course it would be best if implementations would keep the same order there, i.e. if they include same public key used in AUTH payload in multiple formats they always include that first for each certificate type they provide (i.e. the first X.509 certificate - signature (4) CERT payload has the public key used in AUTH payload, even when it is not strictly required if there has already been other CERT payloads before it in different format). Smart implementations will simply put all certificates regardless of format to their "certificate validator", and then take public key from the first CERT payload (most likely ignoring all they do not understand) and try to verify if that public key can be verified to be valid with configured trust anchors. I do not expect mixing of cert encodings to happen that much, but the RAW RSA key combined with X.509 certificates might be the exception of that. I.e. in some environments it might be useful to provide both, so minimal implementations just use preconfigured RAW RSA key, and other implementations might actually verify the certificates instead. -- kivinen@iki.fi From kivinen@iki.fi Mon May 11 05:28: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 9DD613A6ABF for ; Mon, 11 May 2009 05:28: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 dgIo4ovR7yMm for ; Mon, 11 May 2009 05:28:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 643833A6802 for ; Mon, 11 May 2009 05:28:24 -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 n4BCTp2h010595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 15:29:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4BCTpqx021062; Mon, 11 May 2009 15:29: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: <18952.6719.692235.810459@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 15:29:51 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613410ED4F6@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@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: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] Issue #107 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, 11 May 2009 12:28:25 -0000 Yoav Nir writes: > Or I can go with option (d) and send multiple CERT payloads, as Pasi > suggested here: > http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html This is what most implementations currently do. > Either way, we should have it clear what is and is not allowed in > section 3.6. The text is very clear that there CAN be multiple CERT payloads. It is also very clear that FIRST public key received must be the one matching the AUTH payload. Everything else is left as implementation matter. I do not see any problem there to send multiple CERT payloads each having one certificate from the end entity cert towards the trust anchor (usually it is not beneficial to provide the trust anchor certificate, as it needs to be preconfigured to the recipient already anyways). -- kivinen@iki.fi From wierbows@us.ibm.com Mon May 11 06:59: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 9B84728C11C for ; Mon, 11 May 2009 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.703 X-Spam-Level: X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[AWL=0.895, 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 lZzQUVMTJGmh for ; Mon, 11 May 2009 06:59:47 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 7AEE628C120 for ; Mon, 11 May 2009 06:59:47 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4BE3NU0010799 for ; Mon, 11 May 2009 10:03:23 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4BE18uu255072 for ; Mon, 11 May 2009 10:01:10 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4BE171m008890 for ; Mon, 11 May 2009 10:01:07 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4BE17W4008868 for ; Mon, 11 May 2009 10:01:07 -0400 In-Reply-To: <18952.6309.950313.942432@fireball.kivinen.iki.fi> To: "ipsec@ietf.org" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Mon, 11 May 2009 10:01:06 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/11/2009 10:01:07 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFF20DFDA033B8f9e8a93df938690918c0ABBFF20DFDA033B" Content-Disposition: inline Subject: Re: [IPsec] Issue #107 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, 11 May 2009 13:59:48 -0000 --0__=0ABBFF20DFDA033B8f9e8a93df938690918c0ABBFF20DFDA033B Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable > Tero said: > > For the X.509 bundle I think the format is more clear and only one > CERT payload is sent containing hash and url of all certificates and > crls needed (and first certificate there is the one used for AUTH > payload). Tero, I do not agree that it is more clear that only one CERT payload w= ould be sent in the X.509 bundle case. I agree logically that makes sense, = but the RFC does not mandate that. In fact the RFC is very vague in the ca= se of the X.509 bundle. The RFC does not even clearly state that the firs= t certificate in the bundle must be used in signing. An x509 bundle is simply a sequence of CertificateOrCRL. It does not impose any order of= the certificates in the bundle, it does not impose any relationship on the certificates in a bundle, it does not even require certificates to be within the bundle (i.e. the bundle could just contain a CRL), and it do= es not limit the number of CERT payloads that can be sent. For example assume there was a cert chain CA1->CA2->EE. An implementat= ion could decide to use encoding 4 to send the certificate of EE1, to use encoding 13 to send a URL of a bundle that contains the certificate of = CA2 and a CRL issued by CA2, and to use encoding 13 to send a URL of a bun= dle that contains a CRL issued by CA1. This would be valid according to wh= at the RFC states. I'm not saying this should be allowed, but without additional restrictions in the RFC one must be prepared to deal with th= is case. I'm not opposed to adding text that says: When X.509 bundle is used only one certificate payload MUST be sent = . The first certificate in an X.509 bundle MUST be the certificate use= d when creating the signature contained in the AUTH payload. Other certificates and CRLs in the X.509 bundle SHOULD relate to the CA tr= ust chain and may appear in only order. I think this would simplify processing and not be too restrictive. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = --0__=0ABBFF20DFDA033B8f9e8a93df938690918c0ABBFF20DFDA033B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

> Tero said:
>
> For the X.509 bundle I think the format is more clear and only= one
> CERT payload is sent containing hash and url of all certificates a= nd
> crls needed (and first certificate there is the one used for AUTH<= br> > payload).

Tero, I do not agree that it is more clear that only one CERT payload w= ould be sent in the X.509 bundle case. I agree logically that makes se= nse, but the RFC does not mandate that. In fact the RFC is very vague = in the case of the X.509 bundle. The RFC does not even clearly state t= hat the first certificate in the bundle must be used in signing. An x5= 09 bundle is simply a sequence of CertificateOrCRL. It does not impose= any order of the certificates in the bundle, it does not impose any re= lationship on the certificates in a bundle, it does not even require ce= rtificates to be within the bundle (i.e. the bundle could just contain = a CRL), and it does not limit the number of CERT payloads that can be s= ent.

For example assume there was a cert chain CA1->CA2->EE. An imple= mentation could decide to use encoding 4 to send the certificate of EE1= , to use encoding 13 to send a URL of a bundle that contains the certif= icate of CA2 and a CRL issued by CA2, and to use encoding 13 to send a= URL of a bundle that contains a CRL issued by CA1. This would be vali= d according to what the RFC states. I'm not saying this should be allo= wed, but without additional restrictions in the RFC one must be prepare= d to deal with this case.

I'm not opposed to adding text that says:

    When X.509 bundle is used only one certificate payload MUST be sent= . The first certificate in an X.509 bundle MUST be the certificate us= ed when creating the signature contained in the AUTH payload. Other ce= rtificates and CRLs in the X.509 bundle SHOULD relate to the CA trust c= hain and may appear in only order.

I think this would simplify processing and not be too restrictive.
=
Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055


= --0__=0ABBFF20DFDA033B8f9e8a93df938690918c0ABBFF20DFDA033B-- From ssmurthy.nittala@freescale.com Mon May 11 07:03: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 C03B33A6D69 for ; Mon, 11 May 2009 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_72=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 qFJOMxAcu7Xh for ; Mon, 11 May 2009 07:03:37 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 1DCA528C12C for ; Mon, 11 May 2009 07:03:37 -0700 (PDT) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n4BE4S3h002444 for ; Mon, 11 May 2009 07:04:30 -0700 (MST) Received: from nsmurthy.freescale.com ([10.232.113.68]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n4BE4Nns002222 for ; Mon, 11 May 2009 09:04:26 -0500 (CDT) Message-Id: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 May 2009 19:40:22 +0530 To: ipsec@ietf.org From: ss murthy nittala Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 14:03:37 -0000 Hi, Is it required for IV to be randomly generated for each ESP packet in case of AES-CTR and AES-CBC methods? AES-CTR:My understanding is that IV is to be generated randomly for the first packet.For each new outgoing packet increment IV and use it. AES-CBC:Is it required for IV to be randomly generated for each of the outgoing ESP packets?In any case i think the packet shall include IV. Thanks -ns murthy From kivinen@iki.fi Mon May 11 07: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 5325A3A6D33 for ; Mon, 11 May 2009 07:22:13 -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 6P3fslBJVqhd for ; Mon, 11 May 2009 07: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 D5DC33A6A74 for ; Mon, 11 May 2009 07:22: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 n4BENbu4018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 17:23:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4BENbkn019909; Mon, 11 May 2009 17:23: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: <18952.13545.832275.598866@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 17:23:37 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <18952.6309.950313.942432@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #107 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, 11 May 2009 14:22:13 -0000 David Wierbowski writes: > > > Tero said: > > > > For the X.509 bundle I think the format is more clear and only one > > CERT payload is sent containing hash and url of all certificates and > > crls needed (and first certificate there is the one used for AUTH > > payload). > > Tero, I do not agree that it is more clear that only one CERT payload would > be sent in the X.509 bundle case. I agree logically that makes sense, but > the RFC does not mandate that. In fact the RFC is very vague in the case > of the X.509 bundle. I think it is quite obvious that you are not supposed to use multiple hash and url of X.509 bundle payloads, even when it is not specifically forbidden. > The RFC does not even clearly state that the first certificate in > the bundle must be used in signing. That is not true. The 1.2 clearly says: ... If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field. Which uses words "first certificate provided", and does not talk about first CERT payload just because of this. Again this same thing is reiterated in the 3.6: ... If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. Again it talks about "first certificate", not first CERT payload. Note that term "certificate" there is defined so it can be also other things than certificates, as it said at the beginnig of 3.6: ... Note that the term "Certificate Payload" is somewhat misleading, because not all authentication mechanisms use certificates and data other than certificates may be passed in this payload. > An x509 bundle is > simply a sequence of CertificateOrCRL. It does not impose any order of the > certificates in the bundle, it does not impose any relationship on the > certificates in a bundle, it does not even require certificates to be > within the bundle (i.e. the bundle could just contain a CRL), and it does > not limit the number of CERT payloads that can be sent. Otherwise true, but IKE do require the first certificate that responder sees when going through the CERT payloads and going through contents of the CERT payloads and going through the URLs the CERT payload contents might have pointed him to, MUST contain the public key used to sign the AUTH payload. That specific MUST is not limited to multiple CERT payloads. It is MUST specified in 2 different locations and in both cases it talks about "certificate provided" or just "first certificate". > For example assume there was a cert chain CA1->CA2->EE. An implementation > could decide to use encoding 4 to send the certificate of EE1, to use > encoding 13 to send a URL of a bundle that contains the certificate of CA2 > and a CRL issued by CA2, and to use encoding 13 to send a URL of a bundle > that contains a CRL issued by CA1. This would be valid according to what > the RFC states. Yes that is valid as long as the EE1 is the first certificate which is provided to the recipient. If we take strict interpretation of the 3.6 where also CRLs are in this sense refered as "certificates", there cannot even be any CRLs before the EE1. I.e. the first CERT payload MUST either have EE1 as first certificate, or the URL pointed by it MUST have EE1 as first certificate. > I'm not saying this should be allowed, but without additional > restrictions in the RFC one must be prepared to deal with this case. Yes, your case is allowed, and actually might be efficient way of doing things, as CA1 and CA2 CRLs might be quite different in size and might have different update frequencies, thus one of the bundles might be very static (and large) and another might be updated very often (but is small). > I'm not opposed to adding text that says: > > When X.509 bundle is used only one certificate payload MUST be sent . > The first certificate in an X.509 bundle MUST be the certificate used > when creating the signature contained in the AUTH payload. Other > certificates and CRLs in the X.509 bundle SHOULD relate to the CA trust > chain and may appear in only order. > > I think this would simplify processing and not be too restrictive. This would add new MUST (1st one), and reiterate old MUST (2nd one), and add new SHOULD (3rd one). I do not think we want to add such text now (I do not see need for it, and I think it will be too restrictive). -- kivinen@iki.fi From danmcd@sun.com Mon May 11 07:24: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 A96EB3A6F28 for ; Mon, 11 May 2009 07:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=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 o8vjcgtUueM2 for ; Mon, 11 May 2009 07:24:57 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 0C7933A6D96 for ; Mon, 11 May 2009 07:24:57 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4BEQPV9028232 for ; Mon, 11 May 2009 14:26:25 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4BEQORp027113 for ; Mon, 11 May 2009 10:26:25 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4BEBMju001935; Mon, 11 May 2009 10:11:22 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4BEBLnZ001934; Mon, 11 May 2009 10:11:21 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 11 May 2009 10:11:21 -0400 From: Dan McDonald To: ss murthy nittala Message-ID: <20090511141121.GH1675@sun.com> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 14:24:57 -0000 On Mon, May 11, 2009 at 07:40:22PM +0530, ss murthy nittala wrote: > Hi, > Is it required for IV to be randomly generated for each ESP packet in > case of AES-CTR and AES-CBC methods? I don't know about AES-CTR, but definitely in AES-CBC. > AES-CBC:Is it required for IV to be randomly generated for each of the > outgoing ESP packets?In any case i think the packet shall include IV. The AES-CBC packets include an IV of 16 bytes (i.e. one AES block) which must be randomly generated. Dan From kivinen@iki.fi Mon May 11 07:31: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 62CF23A6452 for ; Mon, 11 May 2009 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_72=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 88Nt0lYqhbU3 for ; Mon, 11 May 2009 07:31:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB0E28C14A for ; Mon, 11 May 2009 07:30:44 -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 n4BEUXdw016382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 17:30:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4BEUXhL016751; Mon, 11 May 2009 17:30: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: <18952.13961.78245.997197@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 17:30:33 +0300 From: Tero Kivinen To: ss murthy nittala In-Reply-To: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: ipsec@ietf.org Subject: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 14:31:14 -0000 ss murthy nittala writes: > Is it required for IV to be randomly generated for each ESP packet in > case of AES-CTR and AES-CBC methods? > > AES-CTR:My understanding is that IV is to be generated randomly for > the first packet.For each new outgoing packet increment IV and use it. >From RFC3686: The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). I.e. it MUST be unique, but there is no other requirements for it. Incremental counter is one commonly used method. > AES-CBC:Is it required for IV to be randomly generated for each of > the outgoing ESP packets?In any case i think the packet shall include IV. >From RFC3602: The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random, and MUST be unpredictable. ... To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs. I.e. it MUST be unpredictable, i.e. randomly generated is good. Using the final ciphertext block of the previous message is NOT acceptable. -- kivinen@iki.fi From ssmurthy.nittala@freescale.com Mon May 11 07:44:54 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 218163A6F6E for ; Mon, 11 May 2009 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_72=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 l+ZOAaFvfV3P for ; Mon, 11 May 2009 07:44:53 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 5841D3A6EA2 for ; Mon, 11 May 2009 07:44:53 -0700 (PDT) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n4BEkCYW014330; Mon, 11 May 2009 07:46:17 -0700 (MST) Received: from nsmurthy.freescale.com ([10.232.113.68]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n4BEk8Xo017104; Mon, 11 May 2009 09:46:11 -0500 (CDT) Message-Id: <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 May 2009 20:22:05 +0530 To: Tero Kivinen From: ss murthy nittala In-Reply-To: <18952.13961.78245.997197@fireball.kivinen.iki.fi> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> <18952.13961.78245.997197@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Brightmail-Tracker: AAAAAQAAAWE= Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 14:44:54 -0000 The following sentence present in RFC 3602 creates some doubts whether IV in each packet is mandatory or not? "Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit." Thanks -ns murthy At 08:00 PM 5/11/2009, Tero Kivinen wrote: >ss murthy nittala writes: > > Is it required for IV to be randomly generated for each ESP packet in > > case of AES-CTR and AES-CBC methods? > > > > AES-CTR:My understanding is that IV is to be generated randomly for > > the first packet.For each new outgoing packet increment IV and use it. > > From RFC3686: > > The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by > the encryptor in a manner that ensures that the same IV value is used > only once for a given key. The encryptor can generate the IV in any > manner that ensures uniqueness. Common approaches to IV generation > include incrementing a counter for each packet and linear feedback > shift registers (LFSRs). > >I.e. it MUST be unique, but there is no other requirements for it. >Incremental counter is one commonly used method. > > > AES-CBC:Is it required for IV to be randomly generated for each of > > the outgoing ESP packets?In any case i think the packet shall include IV. > > From RFC3602: > > The IV field MUST be the same size as the block size of the cipher > algorithm being used. The IV MUST be chosen at random, and MUST be > unpredictable. >... > To avoid CBC encryption of very similar plaintext blocks in different > packets, implementations MUST NOT use a counter or other low-Hamming > distance source for IVs. > >I.e. it MUST be unpredictable, i.e. randomly generated is good. Using >the final ciphertext block of the previous message is NOT acceptable. >-- >kivinen@iki.fi From Paul_Koning@Dell.com Mon May 11 07:58:28 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 4A0913A6D1C for ; Mon, 11 May 2009 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.53 X-Spam-Level: X-Spam-Status: No, score=-105.53 tagged_above=-999 required=5 tests=[AWL=1.069, 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 jaOjCeK8qBi6 for ; Mon, 11 May 2009 07:58:27 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 69DD13A6CE4 for ; Mon, 11 May 2009 07:58:27 -0700 (PDT) X-Loopcount0: from 12.110.134.31 X-IronPort-AV: E=Sophos;i="4.40,328,1238994000"; d="scan'208";a="397172333" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 11 May 2009 09:59:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18952.15723.303037.123733@gargle.gargle.HOWL> Date: Mon, 11 May 2009 10:59:55 -0400 From: Paul Koning To: ssmurthy.nittala@freescale.com References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> <18952.13961.78245.997197@fireball.kivinen.iki.fi> <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 11 May 2009 14:59:55.0646 (UTC) FILETIME=[254479E0:01C9D249] Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 14:58:28 -0000 >>>>> "ss" == ss murthy nittala writes: ss> The following sentence present in RFC 3602 creates some doubts ss> whether IV in each packet is mandatory or not? ss> "Including the IV in each datagram ensures that decryption of ss> each received datagram can be performed, even when some datagrams ss> are dropped, or datagrams are re-ordered in transit." It's mandatory. The paragraph you quoted is simply an explanation of why this is so. Note the first paragraph of that section, which says "the ESP payload is made up of the IV followed...". There isn't any option in that statement. paul From danmcd@sun.com Mon May 11 08:03: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 9987D3A684C for ; Mon, 11 May 2009 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 KIuUsMfu7T-X for ; Mon, 11 May 2009 08:03:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id A87473A6839 for ; Mon, 11 May 2009 08:03:46 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4BF5HLB005013 for ; Mon, 11 May 2009 15:05:17 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4BF5G7k048848 for ; Mon, 11 May 2009 11:05:17 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4BEoHLO002018; Mon, 11 May 2009 10:50:17 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4BEoGhX002017; Mon, 11 May 2009 10:50:16 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 11 May 2009 10:50:16 -0400 From: Dan McDonald To: ss murthy nittala Message-ID: <20090511145016.GI1675@sun.com> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> <18952.13961.78245.997197@fireball.kivinen.iki.fi> <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 15:03:47 -0000 On Mon, May 11, 2009 at 08:22:05PM +0530, ss murthy nittala wrote: > > The following sentence present in RFC 3602 creates some doubts whether IV > in each packet is mandatory or not? > > "Including the IV in each datagram ensures that decryption of each > received datagram can be performed, even when some datagrams are > dropped, or datagrams are re-ordered in transit." Nothing vague about it at all! In fact, this paragraph strengthens the argument Tero made in his note: Using the previous cipher-text block is a Bad Idea (TM). An IP datagram is self-contained, and the IV is mandatory because you can't start a CBC decryption without one, and there's no other way to get an IV. Dan From paul.hoffman@vpnc.org Mon May 11 08:10: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 974C53A6EA2 for ; Mon, 11 May 2009 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 r6NEV5Imv+Oa for ; Mon, 11 May 2009 08:10: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 6E2953A684C for ; Mon, 11 May 2009 08:10:09 -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 n4BFBZrS069187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 08:11:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18952.13545.832275.598866@fireball.kivinen.iki.fi> References: <18952.6309.950313.942432@fireball.kivinen.iki.fi> <18952.13545.832275.598866@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 08:11:29 -0700 To: Tero Kivinen , David Wierbowski From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #107 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, 11 May 2009 15:10:10 -0000 At 5:23 PM +0300 5/11/09, Tero Kivinen wrote: >I think it is quite obvious that you are not supposed to use multiple >hash and url of X.509 bundle payloads, even when it is not >specifically forbidden. Fully disagree. We have no prohibition against this, and I can imagine corner cases where it would be useful. If we allow multiple CERT payloads, we cannot discourage particular contents in each payload. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon May 11 08:13: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 8460028C147 for ; Mon, 11 May 2009 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 J51bseJvsUhQ for ; Mon, 11 May 2009 08:13:18 -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 519A728C124 for ; Mon, 11 May 2009 08:13:18 -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 n4BFDS4c069331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 08:13:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> <18952.13961.78245.997197@fireball.kivinen.iki.fi> <200905111446.n4BEk8Xo017104@az33smr01.freescale.net> Date: Mon, 11 May 2009 08:13:27 -0700 To: ss murthy nittala , Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 15:13:19 -0000 At 8:22 PM +0530 5/11/09, ss murthy nittala wrote: >The following sentence present in RFC 3602 creates some doubts whether IV in each packet is mandatory or not? > >"Including the IV in each datagram ensures that decryption of each > received datagram can be performed, even when some datagrams are > dropped, or datagrams are re-ordered in transit." That is poor wording on the part of the RFC. It should read something like "The reason that the IV is included in each datagram is to ensure..." --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon May 11 08:24: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 67CB028C0E7 for ; Mon, 11 May 2009 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5Rmpgm6YuPI for ; Mon, 11 May 2009 08:24:13 -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 2FCBE3A696E for ; Mon, 11 May 2009 08:24:12 -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 n4BFBZrQ069187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 08:11:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18952.6309.950313.942432@fireball.kivinen.iki.fi> 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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com> <18952.6309.950313.942432@fireball.kivinen.iki.fi> Date: Mon, 11 May 2009 08:09:24 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #107 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, 11 May 2009 15:24:14 -0000 At 3:23 PM +0300 5/11/09, Tero Kivinen wrote: >There is text about this in multiple places in the RFC4306. ...barely. It is only clear in section 1.2, not in subsections of Section 3. The topic of cert chains is barely discussed. I will clear this up in the next draft. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Mon May 11 08:48: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 8E8EE3A6F7A for ; Mon, 11 May 2009 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 s8JHtZd4mNVs for ; Mon, 11 May 2009 08:48:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 472A528C18D for ; Mon, 11 May 2009 08:47:45 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6C0E4200E04; Mon, 11 May 2009 18:49:15 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1AA8B200E04; Mon, 11 May 2009 18:49:15 +0300 (IDT) X-CheckPoint: {4A084865-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 n4BC9RqO018016; Mon, 11 May 2009 15:09: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; Mon, 11 May 2009 15:09:27 +0300 From: Yaron Sheffer To: Yoav Nir , "Pasi.Eronen@nokia.com" , "paul.hoffman@vpnc.org" , "ipsec@ietf.org" Date: Mon, 11 May 2009 15:09:25 +0300 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnRvWC7wZaDeI3OSqCah0lOkz5khgASKMPgAARG5XAAAKAoUAAFvm+A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C7803613410ED52E@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613410ED52E@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_01C9D24A.77C82CB0" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #107 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, 11 May 2009 15:48:05 -0000 ------=_NextPart_000_0000_01C9D24A.77C82CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Or possibly: X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. With this encoding, if a chain of certificates needs to be sent, multiple CERT payloads of type 4 MUST be used, the first of which holds the public key used to directly validate the sender's AUTH payload. The other CERT payloads contain the other components of the chain in natural order, i.e. each certificate signing the preceding one. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Monday, May 11, 2009 12:23 > To: Pasi.Eronen@nokia.com; paul.hoffman@vpnc.org; ipsec@ietf.org > Subject: Re: [IPsec] Issue #107 > > Pasi.Eronen wrote: > > > > Yoav Nir wrote: > > > > You can: > > > > > > > > a) start using hash-and-url > > > > > > > > b) hope your peer has the sub-CA > > > > > > > > c) write an extension to 4306 that allows bundles in CERT > > > > > > > > Doing (a) is the most interoperable, but you're probably > > save with > > > > (b) in a typical closed network. > > > > > > Or I can go with option (d) and send multiple CERT > > payloads, as Pasi > > > suggested here: > > http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html > > > > > > (thanks, Yaron) > > > > > > Either way, we should have it clear what is and is not allowed in > > > section 3.6. > > > > I thought this was already clear in RFC 4306, but apparently > > it's not as clear as it should be. Section 1.2 says "...might > > also send its > > certificate(s) in CERT payload(s)..." -- so multiple CERT > > payloads are allowed -- but Section 3.6 is indeed a bit > > silent about this. > > > > Best regards, > > Pasi > > So how about replacing this: > > o X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. > > With this: > > o X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. Note that with this encoding if a chain of certificates > needs to be sent, multiple CERT payloads MUST be used, only the > first of which holds the public key used to validate the sender's > AUTH payload. > > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0000_01C9D24A.77C82CB0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxMTEyMDkyM1owIwYJKoZIhvcNAQkEMRYEFEcAOLfny5mD pL2mZLtokB4eoKVoMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Z1aD2XIktNKYS9PXP+gqSHCCbl6+HkLuR2IERd2JQ0CR9+q2TGe7+Zv5K+DP+xfc67fJ84scYpDD Sz7RHBHjCHDfB7+iU5Qy24qw0PnEm567vSVH9Wpx1lOoJ3XP0oeheLNjgf2A+affaxvBsUMCtHrG 96zOKXz/xyDT4uvB5atci5Uciub8fHr4rpaWV1kybswbrjENRay2lhTWjOPmbabTIMUl9fJnFDpG z8vlesLq7lod75JO/LYKwsRHva3Ehubcvm/GTbsaTutt22W0dH9sGcVe4LHsDaInc8i8SJwlSovJ V26Z2SL9/vlgEBoq+d1RI4IN8X1NNZKcN8dBZQAAAAAAAA== ------=_NextPart_000_0000_01C9D24A.77C82CB0-- From paul.hoffman@vpnc.org Mon May 11 08:57: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 91A9A3A6D9C for ; Mon, 11 May 2009 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9RfVT5E9yOP for ; Mon, 11 May 2009 08:57:00 -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 61ABC28C152 for ; Mon, 11 May 2009 08:56:09 -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 n4BFvb0Q072698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 May 2009 08:57:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C7803613410ED52E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@il-ex01.ad.checkpoint.com> Date: Mon, 11 May 2009 08:57:36 -0700 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #107 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, 11 May 2009 15:57:01 -0000 At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote: >Or possibly: > >X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate >whose public key is used to validate the sender's AUTH payload. With this >encoding, if a chain of certificates needs to be sent, multiple CERT >payloads of type 4 MUST be used, the first of which holds the public key >used to directly validate the sender's AUTH payload. The other CERT payloads >contain the other components of the chain in natural order, i.e. each >certificate signing the preceding one. In a word: no. This is a new requirement on a topic that was vague before. It should be sufficient for us to say something in 3.6 about multiple CERT payloads being acceptable, and probably (but not necessarily) the correct way to send a PKIX chain if the party believes that it is needed. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Mon May 11 10: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 D806B3A6C62; Mon, 11 May 2009 10: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: <20090511173001.D806B3A6C62@core3.amsl.com> Date: Mon, 11 May 2009 10:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-09.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, 11 May 2009 17: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 : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-09.txt Pages : 14 Date : 2009-05-11 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-11102828.I-D@ietf.org> --NextPart-- From kent@bbn.com Mon May 11 12:28: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 098783A6D94 for ; Mon, 11 May 2009 12:28:15 -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 huKLglEAUnyz for ; Mon, 11 May 2009 12:28:14 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4903C3A6D69 for ; Mon, 11 May 2009 12:28:14 -0700 (PDT) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M3bC3-0006io-CM; Mon, 11 May 2009 15:29:44 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> References: <200905111404.n4BE4Nns002222@az33smr01.freescale.net> Date: Mon, 11 May 2009 15:05:06 -0400 To: ss murthy nittala From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods 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, 11 May 2009 19:28:15 -0000 At 7:40 PM +0530 5/11/09, ss murthy nittala wrote: >Hi, >Is it required for IV to be randomly generated for each ESP packet >in case of AES-CTR and AES-CBC methods? > >AES-CTR:My understanding is that IV is to be generated randomly for >the first packet.For each new outgoing packet increment IV and use >it. Even for CTR mode, an explicit IV MUST be included with each packet, because the receiver does not know what method of counter value generation the sender has elected to employ. Steve From yaronf@checkpoint.com Mon May 11 14:18: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 84AD228C153 for ; Mon, 11 May 2009 14:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 5q8x02VrgeAI for ; Mon, 11 May 2009 14:18:16 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id ED0F53A6A4A for ; Mon, 11 May 2009 14:18:15 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3142F29C001; Tue, 12 May 2009 00:19:46 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E2F1C200E04; Tue, 12 May 2009 00:19:45 +0300 (IDT) X-CheckPoint: {4A0895DA-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 n4BLJjqO003668; Tue, 12 May 2009 00:19: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; Tue, 12 May 2009 00:19:45 +0300 From: Yaron Sheffer To: Paul Hoffman , "ipsec@ietf.org" Date: Tue, 12 May 2009 00:19:41 +0300 Thread-Topic: [IPsec] Issue #107 Thread-Index: AcnSUVv0DyLXJhA6TLSfy1jTdpI9QAALHBjQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583AEA@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C7803613410ED52E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@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_0053_01C9D297.58190860" MIME-Version: 1.0 Subject: Re: [IPsec] Issue #107 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, 11 May 2009 21:18:17 -0000 ------=_NextPart_000_0053_01C9D297.58190860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In two words, why not? What is the exact new requirement you are referring to? More generally, this is not some obscure part of the RFC that we're discussing. This is possibly the most mainstream usage scenario. And we need to make every effort possible in order to ensure interoperability. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Monday, May 11, 2009 18:58 > To: ipsec@ietf.org > Subject: Re: [IPsec] Issue #107 > > At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote: > >Or possibly: > > > >X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate > >whose public key is used to validate the sender's AUTH payload. With this > >encoding, if a chain of certificates needs to be sent, multiple CERT > >payloads of type 4 MUST be used, the first of which holds the public key > >used to directly validate the sender's AUTH payload. The other CERT > payloads > >contain the other components of the chain in natural order, i.e. each > >certificate signing the preceding one. > > In a word: no. This is a new requirement on a topic that was vague before. > > It should be sufficient for us to say something in 3.6 about multiple CERT > payloads being acceptable, and probably (but not necessarily) the correct > way to send a PKIX chain if the party believes that it is needed. > > --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. ------=_NextPart_000_0053_01C9D297.58190860 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxMTIxMTk0MVowIwYJKoZIhvcNAQkEMRYEFCmSChrViTH4 0aiEB+QLOmu+aTF/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA sNFGn3sc5ujDeX/XsaFAwZ3qWQWxF/wXP4OOIIB2IH6Z5hcd40o2yPlLHEf+kI6tv6AcykHu42P8 woxutwPBqKLcovdHbVh6rln+j/w4mQMNyUa3V3A2HPSTgnfsTUxA61vtH5LcAUCKhbJI51D0snnh eEILcw9rmj+abuUE7e82OUyYyTm+2siPhWUrExZpcg11Z+QrqOwrQNNCzBZSFw8PfLU2mhhF8XTT 3yuK7pWYjcxygE3/G+d5KAaFk+fyyxmpb3PLMyzHFIkPJgzsl4xJIQnYYWaYfP7D7nzhV0va43fC +VPKf1sY/hHEJ+MtuCY4EjOtpLuAPpIYJNWjKAAAAAAAAA== ------=_NextPart_000_0053_01C9D297.58190860-- From paul.hoffman@vpnc.org Mon May 11 14:53: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 4E60C3A6B16 for ; Mon, 11 May 2009 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 fENrVZVYYYIa for ; Mon, 11 May 2009 14:53:42 -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 3F02D3A6AFC for ; Mon, 11 May 2009 14:53:42 -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 n4BLt7p8094580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2009 14:55:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583AEA@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com>, <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C7803613410ED52E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583AEA@il-ex01.ad.checkpoint.com> Date: Mon, 11 May 2009 14:55:06 -0700 To: Yaron Sheffer , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Issue #107 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, 11 May 2009 21:53:43 -0000 At 12:19 AM +0300 5/12/09, Yaron Sheffer wrote: >In two words, why not? What is the exact new requirement you are referring >to? "multiple CERT payloads of type 4 MUST be used". That is a new requirement. >More generally, this is not some obscure part of the RFC that we're >discussing. This is possibly the most mainstream usage scenario. I suspect not. From what I have heard from VPNC members over the years: preshared secrets >> certs issued directly from a trust anchor > certs in a hierarchy (Where EAP fits in this list varies wildly between vendors) >And we need >to make every effort possible in order to ensure interoperability. Fully agree. That's why I think it is important to not create new MUSTs for this, but to expect implementers to be able to handle validation chains in a variety of sensible fashions. --Paul Hoffman, Director --VPN Consortium From manav@alcatel-lucent.com Mon May 11 16:10: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 3CAEB3A69DD for ; Mon, 11 May 2009 16:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 4SMgnNl64HUf for ; Mon, 11 May 2009 16:10:15 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 1B7163A68E0 for ; Mon, 11 May 2009 16:10:14 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4BNBibg012796 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 May 2009 01:11:44 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 12 May 2009 01:11:44 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 May 2009 04:41:42 +0530 From: "Bhatia, Manav (Manav)" To: "ipsec@ietf.org" Date: Tue, 12 May 2009 04:41:41 +0530 Thread-Topic: Next Header field in WESP header Thread-Index: AcnNxngb/n2nk180Rn+zgQSzRZ7rFwExOXQQ Message-ID: <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> In-Reply-To: <4A00ABA9.4090201@sandelman.ca> 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [IPsec] Next Header field in WESP header 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, 11 May 2009 23:10:16 -0000 Hi, I'd personally like to see the "Next Header" field retained in the WESP hea= der. It becomes extremely easy for the ASICs (even off the shelf ones like = Broadcom, Wintegra, etc) to look at a fixed offset in the packet for a part= icular byte pattern and decide on what it needs to do with that packet. By = removing the "Next Header" it becomes quite difficult to do this in the fas= t path unless one has customized ASICs used in their Hardware.=20 In our current implementation it is trivial to add a HW filter which says t= he following: Drop all WESP traffic if its carrying TCP to port 8008 (we could also speci= fy the source/dest IP) This is possible because I know exactly where to look at in the incoming pa= cket and decide based on that. Is there a strong reason for doing away with the "Next Header" field in the= WESP header as was suggested some time back? Cheers, Manav=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Michael Richardson > Sent: Wednesday, May 06, 2009 2.42 AM > To: ipsec@ietf.org > Subject: Re: [IPsec] Issue #93: Next header value in tunnel=20 > mode for WESP >=20 > Yaron Sheffer wrote: > > Hi Ken, > >=20 > > It seems to me this field is more trouble than it's worth.=20 > We are assuming > > that the hardware will be enforcing a very simplistic=20 > security policy (don't > > care if it's Tunnel or Transport, don't care if it's a TCP=20 > SYN or not etc.) > > and that the hardware is unable to perform anything more=20 > than extremely > > basic packet parsing. Both assumptions may well be=20 > incorrect. And the cost > > is in complicating the protocol and the endpoint implementations. >=20 > Have we received any review yet from companies/individuals=20 > that actually > build the hardware involved? (I'm out of that business for 8=20 > years myself). >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From g_e_montenegro@yahoo.com Mon May 11 16:26: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 EB9863A6C29 for ; Mon, 11 May 2009 16:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB3OD7K9MKUU for ; Mon, 11 May 2009 16:26:09 -0700 (PDT) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 4318B3A6C42 for ; Mon, 11 May 2009 16:25:44 -0700 (PDT) Received: (qmail 33415 invoked by uid 60001); 11 May 2009 23:27:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242084433; bh=k3ncnzKXM12TekuGgn2sBs4344oSXqsE7zZ4Tq9XwYY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iJWD/dLfySXAptDHb8MvkzSILYT/WWAhj0BfThAzQCT8kUBJ7AhRhhhRSRBuJWcPlzk3dVvR4PV6ZeYhYOHuE4VYMpu6MY59uIluT4NTjOYfYuk+FvyTnPW0fjzzPqBopo5qJcFAoOMCdeSHtt6ArkQE9o/JV6SMRWACJ18Mvfk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2rKoJnG8A51kweDOSip/BDGYvJQRxZQNxnFKPvRdH3ywdm6wLlhxGJZblCG1GdyNO3WAe5K9e7GY5nS8mCVyah5sAAwpg5BG0PA84JIcjqSAUjNNbXAR0KJkAXor8cp4wmgsFHuS3ffNzcschgWUeTLocZ2J8qWiiCFszUNZ48A=; Message-ID: <714328.31562.qm@web82605.mail.mud.yahoo.com> X-YMail-OSG: EBftkiEVM1l2BfD9EoekuAq03gAB_ZcCWdHe_kcmEDUplzbtiPdxKXw25VH9P98X0pD63os88zCP0FP_2UYRjMciecrdrXtnaqvbCoF6xyN3NdZhBLzDeDRj7lYZ.bP73OXnQddX1HaYa7u.Zpb0ERDrCBuBfE_Dr6N4JZZJAO0uHFRlNEurprAGO5X7btJKSqC3ihf9T6jBq_42gCV7iViX38.9WYVHzKUyRi_uq3k4w8RgXnhr2RYcfeoWGIqBqKNx7SoiXA1rHJCqmsokwBvXvqbrNCiKUkNAM4l_DO.lG.aTQ378NnoUukVS9B3nymFyIKokcYAFF6qU02c- Received: from [131.107.0.77] by web82605.mail.mud.yahoo.com via HTTP; Mon, 11 May 2009 16:27:13 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 11 May 2009 16:27:13 -0700 (PDT) From: gabriel montenegro To: "Bhatia, Manav \(Manav\)" , "ipsec@ietf.org" In-Reply-To: <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [IPsec] Next Header field in WESP header 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, 11 May 2009 23:26:11 -0000 Per my recollection, during the interim last week, Yaron clarified that eve= n though he had made =0Athe suggestion to do away with the=A0Next Header fi= eld, he did not feel strongly about it. =0A=0AHis point is valid, though: i= f it is not found to be useful, then the field should not be included.=0AYo= ur point below about=A0Next Header being useful=A0is specially valuable as = it is from someone =0Ainvolved in developing these boxes.=0A=0AGabriel=0A= =0A=0A----- Original Message ----=0A> From: "Bhatia, Manav (Manav)" =0A> To: "ipsec@ietf.org" =0A> Sent: Mon= day, May 11, 2009 4:11:41 PM=0A> Subject: [IPsec] Next Header field in WESP= header=0A> =0A> Hi,=0A> =0A> I'd personally like to see the "Next Header" = field retained in the WESP header. =0A> It becomes extremely easy for the A= SICs (even off the shelf ones like Broadcom, =0A> Wintegra, etc) to look at= a fixed offset in the packet for a particular byte =0A> pattern and decide= on what it needs to do with that packet. By removing the =0A> "Next Header= " it becomes quite difficult to do this in the fast path unless one =0A> ha= s customized ASICs used in their Hardware. =0A> =0A> In our current impleme= ntation it is trivial to add a HW filter which says the =0A> following:=0A>= =0A> Drop all WESP traffic if its carrying TCP to port 8008 (we could also= specify =0A> the source/dest IP)=0A> =0A> This is possible because I know = exactly where to look at in the incoming packet =0A> and decide based on th= at.=0A> =0A> Is there a strong reason for doing away with the "Next Header"= field in the WESP =0A> header as was suggested some time back?=0A> =0A> Ch= eers, Manav =0A> =0A> > -----Original Message-----=0A> > From: ipsec-bounce= s@ietf.org [mailto:ipsec-bounces@ietf.org] =0A> > On Behalf Of Michael Rich= ardson=0A> > Sent: Wednesday, May 06, 2009 2.42 AM=0A> > To: ipsec@ietf.org= =0A> > Subject: Re: [IPsec] Issue #93: Next header value in tunnel =0A> > m= ode for WESP=0A> > =0A> > Yaron Sheffer wrote:=0A> > > Hi Ken,=0A> > > =0A>= > > It seems to me this field is more trouble than it's worth. =0A> > We a= re assuming=0A> > > that the hardware will be enforcing a very simplistic = =0A> > security policy (don't=0A> > > care if it's Tunnel or Transport, don= 't care if it's a TCP =0A> > SYN or not etc.)=0A> > > and that the hardware= is unable to perform anything more =0A> > than extremely=0A> > > basic pac= ket parsing. Both assumptions may well be =0A> > incorrect. And the cost=0A= > > > is in complicating the protocol and the endpoint implementations.=0A>= > =0A> > Have we received any review yet from companies/individuals =0A> >= that actually=0A> > build the hardware involved?=A0 (I'm out of that busin= ess for 8 =0A> > years myself).=0A> > =0A> > =0A> > _______________________= ________________________=0A> > IPsec mailing list=0A> > IPsec@ietf.org=0A> = > https://www.ietf.org/mailman/listinfo/ipsec=0A> > =0A> __________________= _____________________________=0A> IPsec mailing list=0A> IPsec@ietf.org=0A>= https://www.ietf.org/mailman/listinfo/ipsec=0A From ssmurthy.nittala@freescale.com Tue May 12 00:03: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 5E1523A6BB1 for ; Tue, 12 May 2009 00:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11, J_CHICKENPOX_46=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 s5FPFJCLIQ5J for ; Tue, 12 May 2009 00:03:28 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id A10FB28C0EF for ; Tue, 12 May 2009 00:03:28 -0700 (PDT) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n4C74ghh019758 for ; Tue, 12 May 2009 00:04:48 -0700 (MST) Received: from nsmurthy.freescale.com ([10.232.113.68]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n4C74bYZ029918 for ; Tue, 12 May 2009 02:04:41 -0500 (CDT) Message-Id: <200905120704.n4C74bYZ029918@az33smr01.freescale.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 May 2009 12:40:39 +0530 To: ipsec@ietf.org From: ss murthy nittala Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [IPsec] IV in ESP packets for DES and 3DES methods 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, 12 May 2009 07:03:29 -0000 Hi Thanks for the clarifications regarding IV usage for AES methods. RFC 2405 (DES) in its implementation note says "Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption process; this logically extends the CBC across the packets.It also has the advantage of limiting the leakage of information from the random number genrator. No matter which mechnism is used, the receiver MUST NOT assume any meaning for this value, other than that it is an IV." But towards the end of the RFC, it says "For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks." What is RFC suggesting here?Anyway we can not avoid the possibility of successive plain packets being identical atleast partially. Is Random number for IV a must or it is ok to get it from the previous encrypted packet for DES? What are the latest observations? I also want know the same regarding 3DES. Thanks in advance -ns murthy From ynir@checkpoint.com Tue May 12 00:40: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 890FC3A6AF3 for ; Tue, 12 May 2009 00:40:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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.261, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7eYgimoWs+c for ; Tue, 12 May 2009 00:40:21 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1242114022-13205-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0EFC83A6830 for ; Tue, 12 May 2009 00:40:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AE6DC29C001; Tue, 12 May 2009 10:41:51 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5F337200E04; Tue, 12 May 2009 10:41:51 +0300 (IDT) 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 n4C7foqO017370; Tue, 12 May 2009 10:41: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; Tue, 12 May 2009 10:41:49 +0300 From: Yoav Nir To: "ssmurthy.nittala@freescale.com" Date: Tue, 12 May 2009 10:41:49 +0300 Message-ID: <9FB7C7CE79B84449B52622B506C78036134114A7B2@il-ex01.ad.checkpoint.com> Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 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, 12 May 2009 07:40:22 -0000 This is a multi-part message in MIME format... ------------=_1242114022-13205-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1242114022-13205-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0EFC83A6830 for ; Tue, 12 May 2009 00:40:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AE6DC29C001; Tue, 12 May 2009 10:41:51 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5F337200E04; Tue, 12 May 2009 10:41:51 +0300 (IDT) X-CheckPoint: {4A0927A4-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 n4C7foqO017370; Tue, 12 May 2009 10:41: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; Tue, 12 May 2009 10:41:49 +0300 Content-Type: multipart/mixed; boundary="_000_9FB7C7CE79B84449B52622B506C78036134114A7B2ilex01adcheck_" From: Yoav Nir To: "ssmurthy.nittala@freescale.com" CC: "ipsec@ietf.org" Date: Tue, 12 May 2009 10:41:49 +0300 Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods Thread-Topic: [IPsec] IV in ESP packets for DES and 3DES methods Thread-Index: AcnS1RvMyCQuziDgSBO1ijyVB73JXg== Message-ID: <9FB7C7CE79B84449B52622B506C78036134114A7B2@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <9FB7C7CE79B84449B52622B506C78036134114A7B2@il-ex01.ad.checkpoint.com> acceptlanguage: en-US MIME-Version: 1.0 --_000_9FB7C7CE79B84449B52622B506C78036134114A7B2ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-12 at 10:05 +0000, ss murthy nittala wrote:=0A= > Hi=0A= > =0A= > Thanks for the clarifications regarding IV usage for AES methods.=0A= > =0A= > RFC 2405 (DES) in its implementation note says=0A= > =0A= > "Common practice is to use random data for the first IV and the last =0A= > 8 octets of encrypted data from an encryption process as the IV for =0A= > the next encryption process; this logically extends the CBC across =0A= > the packets.It also has the advantage of limiting the leakage of =0A= > information from the random number genrator. No matter which mechnism =0A= > is used, the receiver MUST NOT assume any meaning for this value, =0A= > other than that it is an IV."=0A= =0A= This was common practice at the time. Random numbers were considered a=0A= scarce resources then, so using the last block of ciphertext was a close=0A= enough approximation. Today random data is not scarce (operating systems=0A= provide good enough random), so it's no longer recommended.=0A= =0A= > But towards the end of the RFC, it says=0A= > =0A= > "For the first block of plaintext, though, the IV takes the place=0A= > of the previous block of ciphertext. If the IV doesn't differ=0A= > much from the previous IV, and the actual plaintext block doesn't=0A= > differ much from the previous packet's, then the effective=0A= > plaintext won't differ much, either. This means that you have=0A= > pairs of ciphertext blocks combined with plaintext blocks that=0A= > differ in just a few bit positions. This can be a wedge for=0A= > assorted cryptanalytic attacks."=0A= > =0A= > What is RFC suggesting here?Anyway we can not avoid the possibility =0A= > of successive plain packets being identical atleast partially.=0A= > Is Random number for IV a must or it is ok to get it from the =0A= > previous encrypted packet for DES?=0A= > =0A= > What are the latest observations?=0A= > =0A= > I also want know the same regarding 3DES.=0A= =0A= RFCs are more about interoperability than operational security. The=0A= method of generating the IV does not affect interoperability, so you'll=0A= often see it discussed in "Security Considerations" sections without the=0A= RFC 2119 terminology. Random numbers are better than using the previous=0A= ciphertext block, and this is true for DES, 3DES, AES or any block=0A= cipher.=0A= =0A= =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036134114A7B2ilex01adcheck_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+IhIwAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADRCREMyRUI4 MENDNzAzNDE5MDQxODIyRUZFMTVDM0Y4ADcHAQ2ABAACAAAAAgACAAEFgAMADgAAANkHBQAMAAcA KQAxAAIAVAEBIIADAA4AAADZBwUADAAHACkAMQACAFQBAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABADcAAABSZTogW0lQc2VjXSBJViBpbiBFU1AgcGFja2V0cyBmb3IgREVT IGFuZCAzREVTIG1ldGhvZHMAXxEBA5AGAJQNAAArAAAAAgF/AAEAAABHAAAAPDlGQjdDN0NFNzlC ODQ0NDlCNTI2MjJCNTA2Qzc4MDM2MTM0MTE0QTdCMkBpbC1leDAxLmFkLmNoZWNrcG9pbnQuY29t PgAAAgEJEAEAAABcBgAAWAYAANsKAABMWkZ1wrS0GWEACmZiaWQEAABjY8BwZzEyNTIA/gND8HRl eHQB9wKkA+MCAARjaArAc2V0MCDvB20CgwBQEU0yCoAGtAKAln0KgAjIOwliMTkOwL8JwxZyCjIW cQKAFWIqCbBzCfAEkGF0BbIOUANgc6JvAYAgRXgRwW4YMF0GUnYEkBe2AhByAMB0fQhQbhoxECAF wAWgG2RkmiADUiAQIheyXHYIkOR3awuAZDUdUwTwB0ANF3AwCnEX8mJrbWsGcwGQACAgQk1fQuBF R0lOfQr7C/IBMJR7TwOgVApQLCAB0EAwOS0wNS0OkCCVGIAgHpA6ImAgKx6gFx6gIfAEEW0IcHRo eY4gAwACQAdAYSB3A2BRECA6XGwLgGUKgD7cIEgAoCVWJUdUGaEfUO8ccAWxJCAZ4GMLYAaBDlDd GIBpAiAEIAlwZwsRC4AAZyBJViB1c2HzGdEngkFFBfAHgCQgBHBMcy4l/wfwRkMiADTJIyEoRCpw KSALgC0g7nQEIAdwC1BlB4ACMCiDZyRQJQEjsGF5DgArPyKtCFBtBGADoHAYcGMokO5jGeAEABzA bymxGeAYcPsdwByhZBiAJMAnhihQEfB/BUApkTIBJ7MLYDNhJUc4vCBvMPASEAQgGTAgCfD9BQB5 BTAcUTJkHJIDkTXl/y5SMMA1QAeQBCA0UCezKZF/J4IlRyfCGFAQQDdPBBA7lyexMVEJAGcoYWxs JEDPEDEJ8CrwJ7NDQixgANBPGQEEITl6CrBjazVxLm5JBUAHQBkgIBHQOJRhfGR2AHABkBnRNbEl UG3HJHApUjQDZWFrQNUlRz8LgBrkLlIchCfRMfVude8G0BuxGDEYcy4HsDGQGxF9G6J3O9ARwCqR EcADAHPvHLBCyAQgMbFkIfBEYwWQjGVpGjEF0FVTVAewtk9J0DRQc0UgQFFuJED/B4AAcClSJ4Qx UUCQCkEh8P8lRyUAJ9AnogORTVEFQCRw5zFCA5EpkC4iJUUlRScQ/TFRdziBBaAwfCLBJ8IokPsH gEYAUkS6T9EEkCfhKLG3DdBTARxgYSVFHkFyMSHfCXAZIAhwODEnsm4joTGSr0GXNFICYDVAazWi YwUgv00RECJP4yTAKAAZEGUlRUsJ8AhgZ0cAYXA4AXj3B3Aog0YAVARwLvAx6zFRxy6RI7BUhChv cBhiKVL2cy8AECBtLxY4AR1gAQC9RXBvBHA10VmDMfQpVcP9JHAnW/I8ARnBBcBJETBhTzzhCYAr FiVHQnVRQW//T/ALIDiUPOE1oifCLEEh8PdN8S7vL/RGMstXBwtTECL/SLJZgki0KZEBkD8gOJQL Ud8xICVHayBkRTDAZR1gCGD/BCBXDxBARgApgGRUKZEyIPkHkG4nBUAN4AEgBJBqqf8j8EbxRBdr xymQIfAzxjDh/nUHQGgIbEVuVWqpbtRv3/9r5T70YHBIs02CY+Fu8TDx9xowaqlyiHcCIG6ndQMh 8H9JQE0CbYFPo0riOJIiwXn/CGA/4XgsC3BSwVdsbFNQE/8NwBhQHGAD8CQgcn575HP//S0iainA P4EccAfRDcAFQP5wGRBBcSixeyYeUAOgRUD7WHFS8GQp9GqpSjEJERxR9zYDAHAHQHkxASKxAZB+ 8XtOpyZpV02zBCAsQkpQZ48YMB9gKVJNEWU/QUqwv0/wJEBS8ISjXBJ8oG8N0Ns+pD3haQ3AJVB0 JEBMaPs1wEpQYzgySVFoBD7mhOH/KVJTgQIwPEIisUIRM2EKsfcokDxiKxhJigFEuyeCM5LvI+Ez YQWxTfRvV0AxgRgw/03TRBclR2vHNeg+9CdzLOH+P4iPiZQKwFGBNBMQIJSi/mISABogKISZb5LB P5RP8PkCMCBrLpAH4CfCKdBKcf0o+DMs4WH9LEE4YVMRBGD/UxEBoAhgTdFoUQNgXOKNdd9NU1zV AiByURIAYwhxjbD/WqEn0CVFKqQ1ohg1QZZuJd+MNHfDom9Vw3xRJzxwJUX/GTF3QRIAMTFusgTw KcBIgX0tIiIGYKS0PWBTVSiEIn+kgiiUf8KiMifBoMgiADHfFnAcwRsAC4AI8WelAVIN/5riRUBG c01TVhhrxiVFfh73cXYxUTFScgpQmOYh8KAC/yHwKmIFsUqibFO0G2H9FUIBuqAfAEIAAQAAABIA AABZAG8AYQB2ACAATgBpAHIAAAAAAB8AZQABAAAAKAAAAHkAbgBpAHIAQABjAGgAZQBjAGsAcABv AGkAbgB0AC4AYwBvAG0AAAAfAGQAAQAAAAoAAABTAE0AVABQAAAAAAACAUEAAQAAAFwAAAAAAAAA gSsfpL6jEBmdbgDdAQ9UAgAAAIBZAG8AYQB2ACAATgBpAHIAAABTAE0AVABQAAAAeQBuAGkAcgBA AGMAaABlAGMAawBwAG8AaQBuAHQALgBjAG8AbQAAAB8AGgwBAAAAEgAAAFkAbwBhAHYAIABOAGkA cgAAAAAAHwAfDAEAAAAoAAAAeQBuAGkAcgBAAGMAaABlAGMAawBwAG8AaQBuAHQALgBjAG8AbQAA AB8AHgwBAAAACgAAAFMATQBUAFAAAAAAAAIBGQwBAAAAXAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC AAAAgFkAbwBhAHYAIABOAGkAcgAAAFMATQBUAFAAAAB5AG4AaQByAEAAYwBoAGUAYwBrAHAAbwBp AG4AdAAuAGMAbwBtAAAACwBAOgEAAAAfABoAAQAAABIAAABJAFAATQAuAE4AbwB0AGUAAAAAAAMA 8T8JBAAACwBAOgEAAAADAP0/5AQAAAIBCzABAAAAEAAAAEvcLrgMxwNBkEGCLv4Vw/gDABcAAQAA AEAAOQCAXJ4b1dLJAUAACDA9Dcwb1dLJAQMANgAAAAAAAgFHAAEAAAAzAAAAYz11czthPSA7cD1D aGVjayBQb2ludDtsPUlMLUVYMDEtMDkwNTEyMDc0MTQ5Wi00OTgAAB8AcAABAAAAZgAAAFsASQBQ AHMAZQBjAF0AIABJAFYAIABpAG4AIABFAFMAUAAgAHAAYQBjAGsAZQB0AHMAIABmAG8AcgAgAEQA RQBTACAAYQBuAGQAIAAzAEQARQBTACAAbQBlAHQAaABvAGQAcwAAAAAAAgFxAAEAAAAWAAAAAcnS 1RvMyCQuziDgSBO1ijyVB73JXgAAHwA1EAEAAACOAAAAPAA5AEYAQgA3AEMANwBDAEUANwA5AEIA OAA0ADQANAA5AEIANQAyADYAMgAyAEIANQAwADYAQwA3ADgAMAAzADYAMQAzADQAMQAxADQAQQA3 AEIAMgBAAGkAbAAtAGUAeAAwADEALgBhAGQALgBjAGgAZQBjAGsAcABvAGkAbgB0AC4AYwBvAG0A PgAAAAAACwDyEAEAAAAfAPMQAQAAAHoAAABSAGUAJQAzAEEAIABbAEkAUABzAGUAYwBdACAASQBW ACAAaQBuACAARQBTAFAAIABwAGEAYwBrAGUAdABzACAAZgBvAHIAIABEAEUAUwAgAGEAbgBkACAA MwBEAEUAUwAgAG0AZQB0AGgAbwBkAHMALgBFAE0ATAAAAAAACwD0EAAAAAALAPUQAAAAAAsA9hAA AAAAQAAHMAZKqBvV0skBHwD4PwEAAAASAAAAWQBvAGEAdgAgAE4AaQByAAAAAAACAfk/AQAAAF0A AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089Q0hFQ0sgUE9JTlQvT1U9SUwgQURNSU5J U1RSQVRJVkUgR1JPVVBTL0NOPVJFQ0lQSUVOVFMvQ049WU5JUgAAAAAfAPo/AQAAABIAAABZAG8A YQB2ACAATgBpAHIAAAAAAAIB+z8BAAAAXQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAv Tz1DSEVDSyBQT0lOVC9PVT1JTCBBRE1JTklTVFJBVElWRSBHUk9VUFMvQ049UkVDSVBJRU5UUy9D Tj1ZTklSAAAAAAMAGUAAAAAAAwAaQAAAAAADAA00+T8AAAIBFDQBAAAAEAAAAFSUocApfxAbpYcI ACsqJRcfAD0AAQAAAAoAAABSAGUAOgAgAAAAAAAfADcAAQAAAG4AAABSAGUAOgAgAFsASQBQAHMA ZQBjAF0AIABJAFYAIABpAG4AIABFAFMAUAAgAHAAYQBjAGsAZQB0AHMAIABmAG8AcgAgAEQARQBT ACAAYQBuAGQAIAAzAEQARQBTACAAbQBlAHQAaABvAGQAcwAAAAAAHwAAgIYDAgAAAAAAwAAAAAAA AEYBAAAAHgAAAGEAYwBjAGUAcAB0AGwAYQBuAGcAdQBhAGcAZQAAAAAAAQAAAAwAAABlAG4ALQBV AFMAAAAfAACAhgMCAAAAAADAAAAAAAAARgEAAAAgAAAAeAAtAG0AcwAtAGgAYQBzAC0AYQB0AHQA YQBjAGgAAAABAAAAAgAAAAAAAAADAN4/n04AAElu --_000_9FB7C7CE79B84449B52622B506C78036134114A7B2ilex01adcheck_-- ------------=_1242114022-13205-1-- From kivinen@iki.fi Tue May 12 01:51: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 AD93F3A6B1C for ; Tue, 12 May 2009 01:51:30 -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 YCknKpSEB+O9 for ; Tue, 12 May 2009 01:51:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1483A6D13 for ; Tue, 12 May 2009 01:51:07 -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 n4C8qNvU006086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 11:52:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4C8qNP5000498; Tue, 12 May 2009 11:52: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: <18953.14535.158400.388006@fireball.kivinen.iki.fi> Date: Tue, 12 May 2009 11:52:23 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: 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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <18946.45275.605400.566221@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C780361338598395@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C780361341113027@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C7803613410ED4F6@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB7727F25B4C1F@NOK-EUMSG-01.mgdnok.nokia.com> <9FB7C7CE79B84449B52622B506C7803613410ED52E@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583A53@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #107 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, 12 May 2009 08:51:30 -0000 Paul Hoffman writes: > At 3:09 PM +0300 5/11/09, Yaron Sheffer wrote: > >Or possibly: > > > >X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate > >whose public key is used to validate the sender's AUTH payload. With this > >encoding, if a chain of certificates needs to be sent, multiple CERT > >payloads of type 4 MUST be used, the first of which holds the public key > >used to directly validate the sender's AUTH payload. The other CERT payloads > >contain the other components of the chain in natural order, i.e. each > >certificate signing the preceding one. > > In a word: no. This is a new requirement on a topic that was vague before. > > It should be sufficient for us to say something in 3.6 about > multiple CERT payloads being acceptable, and probably (but not > necessarily) the correct way to send a PKIX chain if the party > believes that it is needed. Yes, it might be better to say at the beginning of the section 3.6 that multiple CERT payloads is allowed, and if CERT encoding is such that it can only encode one certificate then multiple CERT payloads is the way to send the chains. If encoding can handle multiple certificates (Hash and URL of X.509 bundle), then the whole certificate chain (and associated CRLs if needed) can be sent as one CERT payload (or split to multiple pieces if needed). There can also be multiple CERT payloads with different encodings. Sending multiple CERT payloads is not only restricted to X.509 Certificate - Signature (4) format, and because of this the text should be at the beginning of 3.6 section. Note, that 3.6 explicitly says that except the first certificate, all other certificates can be in any order. -- kivinen@iki.fi From yaronf@checkpoint.com Tue May 12 01:52: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 285EE3A6A7E for ; Tue, 12 May 2009 01:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 0DyoY1OL7rXT for ; Tue, 12 May 2009 01:52:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 43A033A69B5 for ; Tue, 12 May 2009 01:52:40 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1B8A530C001; Tue, 12 May 2009 11:54:08 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BE407200E08; Tue, 12 May 2009 11:54:07 +0300 (IDT) X-CheckPoint: {4A093894-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 n4C8s6qO007659; Tue, 12 May 2009 11:54:07 +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, 12 May 2009 11:54:06 +0300 From: Yaron Sheffer To: gabriel montenegro , "Bhatia, Manav (Manav)" , "ipsec@ietf.org" Date: Tue, 12 May 2009 11:54:04 +0300 Thread-Topic: [IPsec] Next Header field in WESP header Thread-Index: AcnSkB4HWMCnzck3SyWpZg62Gumz/AATlQsA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583B71@il-ex01.ad.checkpoint.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <714328.31562.qm@web82605.mail.mud.yahoo.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_00A6_01C9D2F8.58D5AA90" MIME-Version: 1.0 Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 08:52:42 -0000 ------=_NextPart_000_00A6_01C9D2F8.58D5AA90 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable On reconsideration, I agree with Manav that the NH field will be useful = for hardware implementations. Let's keep it. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of > gabriel montenegro > Sent: Tuesday, May 12, 2009 2:27 > To: Bhatia, Manav (Manav); ipsec@ietf.org > Subject: Re: [IPsec] Next Header field in WESP header >=20 >=20 > Per my recollection, during the interim last week, Yaron clarified = that > even though he had made the suggestion to do away with the=A0Next = Header > field, he did not feel strongly about it. >=20 > His point is valid, though: if it is not found to be useful, then the > field should not be included. > Your point below about=A0Next Header being useful=A0is specially = valuable as > it is from someone involved in developing these boxes. >=20 > Gabriel >=20 >=20 > ----- Original Message ---- > > From: "Bhatia, Manav (Manav)" > > To: "ipsec@ietf.org" > > Sent: Monday, May 11, 2009 4:11:41 PM > > Subject: [IPsec] Next Header field in WESP header > > > > Hi, > > > > I'd personally like to see the "Next Header" field retained in the = WESP > header. > > It becomes extremely easy for the ASICs (even off the shelf ones = like > > Broadcom, Wintegra, etc) to look at a fixed offset in the packet for = a > > particular byte pattern and decide on what it needs to do with that > > packet. By removing the "Next Header" it becomes quite difficult to = do > > this in the fast path unless one has customized ASICs used in their > Hardware. > > > > In our current implementation it is trivial to add a HW filter which > > says the > > following: > > > > Drop all WESP traffic if its carrying TCP to port 8008 (we could = also > > specify the source/dest IP) > > > > This is possible because I know exactly where to look at in the > > incoming packet and decide based on that. > > > > Is there a strong reason for doing away with the "Next Header" field > > in the WESP header as was suggested some time back? > > > > Cheers, Manav > > > > > -----Original Message----- > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > > Behalf Of Michael Richardson > > > Sent: Wednesday, May 06, 2009 2.42 AM > > > To: ipsec@ietf.org > > > Subject: Re: [IPsec] Issue #93: Next header value in tunnel mode = for > > > WESP > > > > > > Yaron Sheffer wrote: > > > > Hi Ken, > > > > > > > > It seems to me this field is more trouble than it's worth. > > > We are assuming > > > > that the hardware will be enforcing a very simplistic > > > security policy (don't > > > > care if it's Tunnel or Transport, don't care if it's a TCP > > > SYN or not etc.) > > > > and that the hardware is unable to perform anything more > > > than extremely > > > > basic packet parsing. Both assumptions may well be > > > incorrect. And the cost > > > > is in complicating the protocol and the endpoint = implementations. > > > > > > Have we received any review yet from companies/individuals that > > > actually build the hardware involved?=A0 (I'm out of that business = for > > > 8 years myself). > > > > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_00A6_01C9D2F8.58D5AA90 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxMjA4NTQwNFowIwYJKoZIhvcNAQkEMRYEFGr3ypdEsHRM nBEuiid1pJ4jZ4iIMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA b9SyKbcMDdZyfuVaIlkcc6ahjfWpNJuQb9uNen9WizDjNwaD3T/BqmFsDhcl4Iouuh+TsUTjgRnb yT2wYiMt39QiFb0QOHIi6NI82Je1ZflI/OUrumT/Wr7Rf2CESclqK++Ua9hAK3mprzs14jPprUP1 ujfwu5epC6WQ8mpaLW++eU9XldBk4z6lkVg4kh9Yln9g8RvbP5ZxEay27FPepHuW+YXjXssoLl9u +vhOD3ElBlP8FKFKnJoGekB624VvVV3Z/LwqJlS82XQK3uNKZhKwJMJ//YAW9r59B5fLjnlmrQl4 eALLr4B0n1YOOJs5WjdmTHXJqseRydf9pEzJ7gAAAAAAAA== ------=_NextPart_000_00A6_01C9D2F8.58D5AA90-- From kivinen@iki.fi Tue May 12 01:59:28 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 EE0DE3A6D51 for ; Tue, 12 May 2009 01:59:28 -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 HgJT7EMZEUb0 for ; Tue, 12 May 2009 01:59:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E58E53A6D47 for ; Tue, 12 May 2009 01:59:27 -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 n4C90sBj001571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 12:00:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4C90rsH002127; Tue, 12 May 2009 12:00:53 +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: <18953.15045.697978.618223@fireball.kivinen.iki.fi> Date: Tue, 12 May 2009 12:00:53 +0300 From: Tero Kivinen To: gabriel montenegro In-Reply-To: <714328.31562.qm@web82605.mail.mud.yahoo.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 08:59:29 -0000 gabriel montenegro writes: > Your point below about=A0Next Header being useful=A0is specially > valuable as it is from someone involved in developing these boxes. If the box can do IPv6 header processing (which do require similar offset calculations) to find the WESP header in the first place, then doing packet length - ICV length (from packet) and get byte from there is not that complicated and hardware can most likely do that already. And I hope nobody is designing new hardware now which cannot do IPv6 processing...=20 --=20 kivinen@iki.fi From manav@alcatel-lucent.com Tue May 12 03:55: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 0A6CD3A6C27 for ; Tue, 12 May 2009 03:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 fnL+EM4pZWBT for ; Tue, 12 May 2009 03:55:23 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id EDC383A6A7E for ; Tue, 12 May 2009 03:55:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4CAupfF000483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 May 2009 12:56:51 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 12 May 2009 12:56:50 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 12 May 2009 16:17:41 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen , gabriel montenegro Date: Tue, 12 May 2009 16:17:39 +0530 Thread-Topic: [IPsec] Next Header field in WESP header Thread-Index: AcnS4C/QGk1Dp6mWSTWauIafH+xFpwAAdyUg Message-ID: <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> In-Reply-To: <18953.15045.697978.618223@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 10:55:24 -0000 There are a lot of boxes deployed in the field that cant do what you seem t= o be suggesting.=20 If we are to pick up the "Next Header" from the ESP trailer then we need to= parse the entire packet with the variability in the ICV length. This would= entail storing the entire IPv4/Ipv6 packet (coming at line rate) in the si= licon's buffer which would need to be really large. Not many boxes would be= able to do that. However, if we specify the "Next Header" in the WESP head= er than most HWs capable of deep inspecting the first 128 bytes would be ab= le to discern the packet. Is there an issue in keeping "Next Header" in the WESP header? I see an adv= antage in doing so. Would like to hear arguments against it! Cheers, Manav > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Tuesday, May 12, 2009 2.31 PM > To: gabriel montenegro > Cc: Bhatia, Manav (Manav); ipsec@ietf.org > Subject: Re: [IPsec] Next Header field in WESP header >=20 > gabriel montenegro writes: > > Your point below about=A0Next Header being useful=A0is specially > > valuable as it is from someone involved in developing these boxes. >=20 > If the box can do IPv6 header processing (which do require similar > offset calculations) to find the WESP header in the first place, then > doing packet length - ICV length (from packet) and get byte from there > is not that complicated and hardware can most likely do that already. >=20 > And I hope nobody is designing new hardware now which cannot do IPv6 > processing...=20 > --=20 > kivinen@iki.fi > = From sfluhrer@cisco.com Tue May 12 04:57:53 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 512B13A6837 for ; Tue, 12 May 2009 04:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=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 YU1gJG3tifxD for ; Tue, 12 May 2009 04:57:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 52CEC3A6831 for ; Tue, 12 May 2009 04:57:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,182,1241395200"; d="scan'208";a="184210278" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 May 2009 11:59:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4CBxN7g005308; Tue, 12 May 2009 04:59:23 -0700 Received: from sfluhrerwxp (stealth-10-32-244-83.cisco.com [10.32.244.83]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4CBxN7Y000082; Tue, 12 May 2009 11:59:23 GMT From: "Scott Fluhrer" To: "'Yoav Nir'" , References: <9FB7C7CE79B84449B52622B506C78036134114A7B2@il-ex01.ad.checkpoint.com> Date: Tue, 12 May 2009 07:59:23 -0400 Message-ID: <021f01c9d2f9$17765350$53f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9FB7C7CE79B84449B52622B506C78036134114A7B2@il-ex01.ad.checkpoint.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnS1RvMyCQuziDgSBO1ijyVB73JXgAIbKPQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3571; t=1242129564; x=1242993564; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20IV=20in=20ESP=20packets=20for =20DES=20and=203DES=20methods |Sender:=20; bh=bxAgrSsgq4lQITKrceW+IHTwnG/Oz3FMEHTklV3Jre8=; b=TmyKMn0+/K0lOFjoRQTnUrTNK5anvHAMRtEk4iHYd5Nd4g8f97AkdJMCRj INnBdvy5Xxlugb5OryHcuzC/no+suFmV28dxVpSS2TqL3zBDK9NXVEJAJq9o g3gmp7hjcc; Authentication-Results: sj-dkim-3; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 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, 12 May 2009 11:57:53 -0000 > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Tuesday, May 12, 2009 3:42 AM > To: ssmurthy.nittala@freescale.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods > > On Tue, 2009-05-12 at 10:05 +0000, ss murthy nittala wrote: > > Hi > > > > Thanks for the clarifications regarding IV usage for AES methods. > > > > RFC 2405 (DES) in its implementation note says > > > > "Common practice is to use random data for the first IV and the last > > 8 octets of encrypted data from an encryption process as the IV for > > the next encryption process; this logically extends the CBC > across the > > packets.It also has the advantage of limiting the leakage of > > information from the random number genrator. No matter > which mechnism > > is used, the receiver MUST NOT assume any meaning for this value, > > other than that it is an IV." > > This was common practice at the time. Random numbers were > considered a scarce resources then, so using the last block > of ciphertext was a close enough approximation. Today random > data is not scarce (operating systems provide good enough > random), so it's no longer recommended. More than recommended; after the time RFC 2405 was written, it was recognized that predictable IVs can be used as a part of an attack if the attacker can inject his own traffic into the plaintext stream (and there are scenarios where that is plausible). Now, it's not essential that the IV be actually random; another possibility would be to use the same key used to encrypt the plaintext to form the IV as well (by taking a predictable value and encrypting that). That makes it unpredictable to someone who doesn't know the key, and that's what we care about. > > > But towards the end of the RFC, it says > > > > "For the first block of plaintext, though, the IV takes the place > > of the previous block of ciphertext. If the IV doesn't differ > > much from the previous IV, and the actual plaintext block doesn't > > differ much from the previous packet's, then the effective > > plaintext won't differ much, either. This means that you have > > pairs of ciphertext blocks combined with plaintext blocks that > > differ in just a few bit positions. This can be a wedge for > > assorted cryptanalytic attacks." > > > > What is RFC suggesting here?Anyway we can not avoid the > possibility of > > successive plain packets being identical atleast partially. > > Is Random number for IV a must or it is ok to get it from > the previous > > encrypted packet for DES? > > > > What are the latest observations? > > > > I also want know the same regarding 3DES. > > RFCs are more about interoperability than operational > security. Well, no, the RFCs for security protocols are, in part, about security (and yes, they can't cover every misimplementation possible, they at least make an attempt). RFC 2405 would have forbidden reusing the ciphertext block, had it been recognized for a weakness at the time. > The method of generating the IV does not affect > interoperability, so you'll often see it discussed in > "Security Considerations" sections without the RFC 2119 > terminology. Random numbers are better than using the > previous ciphertext block, and this is true for DES, 3DES, > AES or any block cipher. In CBC mode. Other modes (say, counter or GCM) have different requirements for IV generation. -- scott From kivinen@iki.fi Tue May 12 05:56: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 B5CF63A6B84 for ; Tue, 12 May 2009 05:56:44 -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 qNwbALSGm-3J for ; Tue, 12 May 2009 05:56:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 852183A6CDC for ; Tue, 12 May 2009 05:56:43 -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 n4CCw4x3008238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2009 15:58:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4CCw2Rw004887; Tue, 12 May 2009 15:58: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: <18953.29274.893504.206960@fireball.kivinen.iki.fi> Date: Tue, 12 May 2009 15:58:02 +0300 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 32 min Cc: "ipsec@ietf.org" , gabriel montenegro Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 12:56:44 -0000 Bhatia, Manav (Manav) writes: > There are a lot of boxes deployed in the field that cant do what you > seem to be suggesting. Those deployed boxes will need updates anyways, as they do not support WESP either... > If we are to pick up the "Next Header" from the ESP trailer then we > need to parse the entire packet with the variability in the ICV > length. Note, that if you want to have port numbers, you still need to do variable offset based on the IV length also. > This would entail storing the entire IPv4/Ipv6 packet > (coming at line rate) in the silicon's buffer which would need to be > really large. Yes. With ethernet 1500 bytes is normally enough though. Might be different situation if IPv6 jumbograms are used. > Not many boxes would be able to do that. I think most of the firewall / security processor type chips I know do that anyways (most of those are chips doing IPsec, thus they are bit more powerful than the very basic chips). Can you list some (new) chips that cannot access the full packet? > However, if we specify the "Next Header" in the WESP header than > most HWs capable of deep inspecting the first 128 bytes would be > able to discern the packet. That might not be enough for IPv6, and suddenly noticing at that point that you need more data could make HW quite complex. > Is there an issue in keeping "Next Header" in the WESP header? I see > an advantage in doing so. Would like to hear arguments against it! I think the most of the concerns were bacause then we have two Next Header fields, and there could be security concerns because of that. On of the options would of course then be to get rid of the Next Header field at the end, and only have that in the WESP header. Or we can mandate that recipient IPsec node MUST drop the packet if next header field in the WESP header and the next header field in the end are different. Then there is also question what if the next header field in the WESP header is 0, should the recipient IPsec node drop the packet if packet was ESP-NULL and still had next header field in WESP header of 0? I am not really strongly against the next header field in the WESP header, I am just sure we have good reasons to duplicate data which might cause security implications before we do that. I am not fully convinced that the cannot get the next header field from the end is good enough reason for adding possible security problems and more complicated protocol. Especially when we are talking about new HW designs coming after WESP is specified. If old HW design can be made to understand WESP then it most likely is already one of those more complex security processor type things which do get full packet anyways. -- kivinen@iki.fi From manav@alcatel-lucent.com Tue May 12 07:03: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 7BA2B3A6A29 for ; Tue, 12 May 2009 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 d5IJ0gtOo8TX for ; Tue, 12 May 2009 07:03:16 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 278F83A6D99 for ; Tue, 12 May 2009 07:03:15 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4CE4ihV020517 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 May 2009 16:04:44 +0200 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 12 May 2009 16:04:44 +0200 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 12 May 2009 19:18:21 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Tue, 12 May 2009 19:18:19 +0530 Thread-Topic: [IPsec] Next Header field in WESP header Thread-Index: AcnTAYlACb+M7GJKT4KVweMn3ATSiwAAvyhQ Message-ID: <7C362EEF9C7896468B36C9B79200D83503604B5F75@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-lucent.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-lucent.com> <18953.29274.893504.206960@fireball.kivinen.iki.fi> In-Reply-To: <18953.29274.893504.206960@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-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "ipsec@ietf.org" , gabriel montenegro Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 14:03:17 -0000 > > There are a lot of boxes deployed in the field that cant do what you > > seem to be suggesting. =20 >=20 > Those deployed boxes will need updates anyways, as they do not support > WESP either...=20 I had meant that there are boxes currently deployed in the field which woul= d have HW capable of only looking at the fixed offsets. SW is a commodity i= tem and can always be upgraded. If you have Next Header in the WESP header = then some bit of filtering (at least at the protocol level) can still be do= ne without upgrading the HW.=20 >=20 > > If we are to pick up the "Next Header" from the ESP trailer then we > > need to parse the entire packet with the variability in the ICV > > length. >=20 > Note, that if you want to have port numbers, you still need to do > variable offset based on the IV length also.=20 >=20 > > This would entail storing the entire IPv4/Ipv6 packet > > (coming at line rate) in the silicon's buffer which would need to be > > really large. >=20 > Yes. With ethernet 1500 bytes is normally enough though. Might be > different situation if IPv6 jumbograms are used. I am talking about routers and switches here. Their main job is not to deep= inspect the packets but to route/switch them. Filtering is a capability ad= ded to them and most of them would not look at the entire 1500 bytes to fig= ure out the contents of the packets (they're not even meant to do that). As= I stated earlier, most would pick up the first 128 or so bytes and filter = based on that. >=20 > > Not many boxes would be able to do that. >=20 > I think most of the firewall / security processor type chips I know do > that anyways (most of those are chips doing IPsec, thus they are bit > more powerful than the very basic chips). That's the disconnect then. I am talking about routers/switches where we mi= ght want to deep inspect the packet for different QoS/Policy reasons. =20 > Can you list some (new) chips that cannot access the full packet? You can look at Broadcom and Wintegra. I could be mistaken but I don't thin= k they read the *entire* packet for content aware filtering. You can contac= t me offline if you want more details on the specific chipset(s) I am refer= ring to. =20 > > However, if we specify the "Next Header" in the WESP header than > > most HWs capable of deep inspecting the first 128 bytes would be > > able to discern the packet. >=20 > That might not be enough for IPv6, and suddenly noticing at that point > that you need more data could make HW quite complex. >=20 > > Is there an issue in keeping "Next Header" in the WESP header? I see > > an advantage in doing so. Would like to hear arguments against it!=20 >=20 > I think the most of the concerns were bacause then we have two Next > Header fields, and there could be security concerns because of that. >=20 > On of the options would of course then be to get rid of the Next > Header field at the end, and only have that in the WESP header. Or we > can mandate that recipient IPsec node MUST drop the packet if next > header field in the WESP header and the next header field in the end > are different. This is mentioned in the draft. >=20 > Then there is also question what if the next header field in the WESP > header is 0, should the recipient IPsec node drop the packet if packet > was ESP-NULL and still had next header field in WESP header of 0? Yup, I thought we were clear on this; patently, I was mistaken ;-)=20 Next Header of 0 implies that the packet uses encryption and the intermedia= te nodes MUST not attempt to read them. If the end node finds that this isn= 't true, then it MUST drop the packet. >=20 > I am not really strongly against the next header field in the WESP > header, I am just sure we have good reasons to duplicate data which > might cause security implications before we do that. Point well taken. >=20 > I am not fully convinced that the cannot get the next header field > from the end is good enough reason for adding possible security > problems and more complicated protocol. >=20 > Especially when we are talking about new HW designs coming after WESP > is specified. If old HW design can be made to understand WESP then it > most likely is already one of those more complex security processor > type things which do get full packet anyways. Not really. Most network processors have a capability of defining user defi= ned fields (UDFs) which the chip looks at in the incoming packet. Using tha= t it becomes trivial to implement and support WESP without any HW change. T= his to me is a big reason why we must have the Next Header in the WESP head= er.=20 A compliant implementation can trivially check the sanity of the Next Heade= r field before accepting the packet and this doesn't really sound like a se= curity hole to me (unless I am missing out on something!). Cheers, Manav From mcr@sandelman.ca Tue May 12 07:44: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 2418628C101 for ; Tue, 12 May 2009 07:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, 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 rzcCsEW7wT-G for ; Tue, 12 May 2009 07:44:01 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4B71A3A6D7F for ; Tue, 12 May 2009 07:44:00 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id C93DB341FB for ; Tue, 12 May 2009 14:45:31 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 83C564E811 for ; Tue, 12 May 2009 10:45:27 -0400 (EDT) Message-ID: <4A098B87.70805@sandelman.ca> Date: Tue, 12 May 2009 10:45:27 -0400 From: Michael Richardson User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ipsec@ietf.org References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> <20090505134635.GA17481@kebe.East.Sun.COM> <4A00AB8B.6080505@sandelman.ca> In-Reply-To: <4A00AB8B.6080505@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 12 May 2009 14:44:02 -0000 Let me draw a time-sequence diagram to explain things as I understand them (fixed-width font alert) site to site policy policy: 1.0.0.0/8 <-> 2.0.0.0/8 Alice-GW Bob-GW --Trigger--> (1.2.3.4->2.3.4.5) (1) <====IKEv2 exchange 1==> <***Trigger**IPsec SA**> (2) <====IKEv2 rekey ======> <***second***IPsec SA**> (3) "POLICY CHANGE" (4) <====IKEv2 rekey: fail=> (5) new trigger (1.2.3.4 -> 2.3.4.5) (6) <====IKEv2 exchange 1==> <***third***IPsec SA***> 1.2.3.4/32 <-> 2.0.0.0/8 The question is, what was this policy change at (3)? Shouldn't such a policy change have caused any incompatible SAs to be removed? Let me suggest that perhaps there are changes which are not clearly policy changes. Postulate that Bob-GW also has a "road-warrior" (George) that normally lives at Alice's site. Normally, George lives behind Alice-GW, and uses the site to site tunnel. When George is on the road, he uses his 1.0.0.0/8 address (which is 1.4.5.6) (He may also bring up a tunnel with Alice-GW) Let's say that the event at (3) is that George brought up his tunnel with Bob-GW. Bob now has two SAs in his SPD: 1. src: 2.0.0.0/8 dst: 1.4.5.6/32 STUFF. 2. src: 2.0.0.0/8 dst: 1.0.0.0/8 STUFF. The SPD is nicely ordered, so traffic to George travels down the seperate tunnel, while traffic back to Alice-site uses the original tunnel. The George tunnel had to be inserted before #2 so that it would have higher priority. Now, when Alice rekeys, is that site allowed to assert control over George's traffic? There are many answers here. I think that there are arguments for many things. Note that in this situation, (3) is not a policy change from an administrative point of view, but simply George bringing up his tunnel. The IP address 1.4.5.6 might not even be present in the PAD: it could come from a certificate. Note that I am not saying that that the situation outlined above (whereby Bob-GW fails the rekey, forcing Alice-GW to try again when she has a trigger packet, resulting in a much narrower SA -- how narrow is up to Bob-GW) is correct. From kent@bbn.com Tue May 12 08:41: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 0E09028C179 for ; Tue, 12 May 2009 08:41:26 -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 9KiPNTrsRitV for ; Tue, 12 May 2009 08:41:25 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A8F5828C18B for ; Tue, 12 May 2009 08:41:06 -0700 (PDT) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M3u7o-0007I4-CF; Tue, 12 May 2009 11:42:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200905120704.n4C74bYZ029918@az33smr01.freescale.net> References: <200905120704.n4C74bYZ029918@az33smr01.freescale.net> Date: Tue, 12 May 2009 11:09:41 -0400 To: ss murthy nittala From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 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, 12 May 2009 15:41:26 -0000 2405 is out of date. Its recommendation re using the last 8 octets of ciphertext from the previous packet has been replaced with one of using a randomly-generated IV for each packet. Steve From kent@bbn.com Tue May 12 08:41: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 D4B0028C179 for ; Tue, 12 May 2009 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAWwM01CB3jL for ; Tue, 12 May 2009 08:41:26 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 405573A6912 for ; Tue, 12 May 2009 08:41:11 -0700 (PDT) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M3u7p-0007I4-Al; Tue, 12 May 2009 11:42:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Tue, 12 May 2009 11:18:18 -0400 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , gabriel montenegro , Tero Kivinen Subject: Re: [IPsec] Next Header field in WESP header 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, 12 May 2009 15:41:26 -0000 If we elect to keep the next header field, to help middle boxes quickly locate header fields of interest to them, then we MUST require the recipient of each message to do a (well-defined) consistency check on the packet, for the reasons I cited in SF. Steve From ssmurthy.nittala@freescale.com Tue May 12 09:05: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 358BC3A6F37 for ; Tue, 12 May 2009 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuPFy+iRJ9mI for ; Tue, 12 May 2009 09:05:33 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 81DEE3A6D96 for ; Tue, 12 May 2009 09:05:29 -0700 (PDT) Received: from de01smr01.freescale.net (de01smr01.freescale.net [10.208.0.31]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id n4CG6x2P003396 for ; Tue, 12 May 2009 09:07:00 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id n4CG6wma024880 for ; Tue, 12 May 2009 11:06:59 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D31B.ACB97773" Date: Tue, 12 May 2009 21:34:33 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C02F87F@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IV in ESP packets for DES and 3DES methods Thread-Index: AcnTGGDoLfzdy1bSSyeYCQh/E22jaQAAvYMl References: <200905120704.n4C74bYZ029918@az33smr01.freescale.net> From: "Murthy N Srinivas-B22237" To: "Stephen Kent" X-Brightmail-Tracker: AAAAAQAAAWE= Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 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, 12 May 2009 16:05:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D31B.ACB97773 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there a new draft/rfc posted with the change incorporated? =20 -ns murthy ________________________________ From: ipsec-bounces@ietf.org on behalf of Stephen Kent Sent: Tue 5/12/2009 8:39 PM To: Murthy N Srinivas-B22237 Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 2405 is out of date. Its recommendation re using the last 8 octets of ciphertext from the previous packet has been replaced with one of using a randomly-generated IV for each packet. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C9D31B.ACB97773 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPsec] IV in ESP packets for DES and = 3DES methods=0A= =0A= =0A= =0A=
=0A=
Is there a = new draft/rfc posted with the change incorporated?
=0A=
 
=0A=
-ns murthy
=0A=
=0A= From: ipsec-bounces@ietf.org on = behalf of Stephen Kent
Sent: Tue 5/12/2009 8:39 = PM
To: Murthy N Srinivas-B22237
Cc: = ipsec@ietf.org
Subject: Re: [IPsec] IV in ESP packets for DES = and 3DES methods

=0A=
=0A=

2405 is out of date. Its recommendation re using the = last 8 octets of
ciphertext from the previous packet has been = replaced with one of
using a randomly-generated IV for each = packet.

Steve
_______________________________________________IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

------_=_NextPart_001_01C9D31B.ACB97773-- From kivinen@iki.fi Wed May 13 02:04: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 EA9BB3A6EDD for ; Wed, 13 May 2009 02:04:32 -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 imw2zIFat6+8 for ; Wed, 13 May 2009 02:04:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8923A6EA1 for ; Wed, 13 May 2009 02:04:30 -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 n4D95t52020800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 12:05:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4D95spY025669; Wed, 13 May 2009 12:05: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: <18954.36210.450711.847353@fireball.kivinen.iki.fi> Date: Wed, 13 May 2009 12:05:54 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <4A098B87.70805@sandelman.ca> References: <18933.41712.378159.694316@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F24A1FB8@NOK-EUMSG-01.mgdnok.nokia.com> <18936.14205.619538.390538@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F25151DF@NOK-EUMSG-01.mgdnok.nokia.com> <18944.6438.936229.687305@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB7727F254C36F@NOK-EUMSG-01.mgdnok.nokia.com> <18944.14495.541311.36886@fireball.kivinen.iki.fi> <20090505134635.GA17481@kebe.East.Sun.COM> <4A00AB8B.6080505@sandelman.ca> <4A098B87.70805@sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 17 min 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: Wed, 13 May 2009 09:04:33 -0000 Michael Richardson writes: > Let me draw a time-sequence diagram to explain things as I understand > them (fixed-width font alert) > > > site to site policy > policy: 1.0.0.0/8 <-> 2.0.0.0/8 > > Alice-GW Bob-GW > --Trigger--> (1.2.3.4->2.3.4.5) > (1) <====IKEv2 exchange 1==> > <***Trigger**IPsec SA**> > > (2) <====IKEv2 rekey ======> > <***second***IPsec SA**> > > (3) "POLICY CHANGE" > > (4) <====IKEv2 rekey: fail=> > (5) new trigger (1.2.3.4 -> 2.3.4.5) > (6) <====IKEv2 exchange 1==> > <***third***IPsec SA***> > 1.2.3.4/32 <-> 2.0.0.0/8 > > > The question is, what was this policy change at (3)? > Shouldn't such a policy change have caused any incompatible SAs to be > removed? Let me suggest that perhaps there are changes which are not > clearly policy changes. > > Postulate that Bob-GW also has a "road-warrior" (George) that normally > lives at Alice's site. > Normally, George lives behind Alice-GW, and uses the site to site > tunnel. When George is on the road, he uses his 1.0.0.0/8 address > (which is 1.4.5.6) (He may also bring up a tunnel with Alice-GW) > > Let's say that the event at (3) is that George brought up his tunnel > with Bob-GW. Bob now has two SAs in his SPD: > > 1. src: 2.0.0.0/8 dst: 1.4.5.6/32 STUFF. > 2. src: 2.0.0.0/8 dst: 1.0.0.0/8 STUFF. > > The SPD is nicely ordered, so traffic to George travels down the > seperate tunnel, while traffic back to Alice-site uses the original > tunnel. The George tunnel had to be inserted before #2 so that it would > have higher priority. Which means now that traffic from tunnel from Alice having 1.4.5.6 address MUST be dropped as it is coming from wrong tunnel, as there is higher priority SPD entry which says they should be coming from the other SA. For me that would mean that SPD entry #2 is bad as now not all traffic covered by the traffic selectors are not allowed to be sent over that SA (meaning it will cause black hole if Alice tries to send traffic using those addresses). Thus the decorrelated version of the SPD would be: 1. src: 2.0.0.0/8 dst: 1.4.5.6/32 STUFF. 2a. src: 2.0.0.0/8 dst: 1.0.0.0 - 1.4.5.5 STUFF. 2b. src: 2.0.0.0/8 dst: 1.4.5.7 - 1.255.255.255 STUFF. Hmm... now reading RFC4301 I found out that it says you are allowed to create such entries, as it says you can either a) send decorrelated entries as traffic selectors b) send original entry from correlated SPD c) send subset of decorrelated entries. (RFC 4301 section 4.4.1 under decorrelation). thus during rekey you can still rekey the original 1.0.0.0/8 <-> 2.0.0.0/8 tunnel and that should not change anything as the first SPD entry is still there with higher priority as #2 has. It also says something about the handling changes to the SPD: ---------------------------------------------------------------------- Handling Changes to the SPD While the System Is Running If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation SHOULD check the impact of an SPD change on extant SAs and SHOULD provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc. ---------------------------------------------------------------------- Which would indicate that RFC4301 does not actually require you to remove SAs which violate your own policy (which I did expect it to do). I.e. you can still keep SAs even when you know that some traffic coming from those SAs will be thrown away immediately when you do inbound traffic checks as the traffic selectors negotiatiated for the SA do not match the SPD entries. > Now, when Alice rekeys, is that site allowed to assert control over > George's traffic? There are many answers here. I think that there are > arguments for many things. > > Note that in this situation, (3) is not a policy change from an > administrative point of view, but simply George bringing up his tunnel. > The IP address 1.4.5.6 might not even be present in the PAD: it could > come from a certificate. If it results change to the SPD, I would consider that as a policy change, regardless of the reason of the change. -- kivinen@iki.fi From denghui02@gmail.com Wed May 13 05:55: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 BBF183A6B85 for ; Wed, 13 May 2009 05:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 T3r5X-QMJ9jI for ; Wed, 13 May 2009 05:55:19 -0700 (PDT) Received: from mail-px0-f125.google.com (mail-px0-f125.google.com [209.85.216.125]) by core3.amsl.com (Postfix) with ESMTP id 2ED413A67B6 for ; Wed, 13 May 2009 05:55:19 -0700 (PDT) Received: by pxi31 with SMTP id 31so208374pxi.29 for ; Wed, 13 May 2009 05:56: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:content-transfer-encoding; bh=HnLTMNTZ54OTIDMliXaCabxdqfqtldF4soFCEXihXFc=; b=YFNyev1vDKAqupAsqlqcGkvk0foUxaotd8UsGOAB1BLKANFP9XCLbMumhcLR9BKgm9 Tl5It9fYCH9+emRWMfyyPfkFZ8XaIZJVYYISWJ0zebn47+tEyQVPKLJ5QRAvQkzCFx3g i0rA6iv/PlcSMWvTpo7cWpHjCzmjFvORFZFwE= 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=RVQywKVAIQftFl1eShbIOnGhoBIsBDe39c2Mid/srTAhLWrkMVTNpQ2yk61/8HBqgd jr5j2PZgV6CfNw2AXQWVMj+/cglteCzYoU8+dXCSlFsQWLYtFIFfjVLIY0j2iX67/+JS 2vylmfM8YUO31bEP8EAxXOpZdhamdimzRhOUw= MIME-Version: 1.0 Received: by 10.142.246.20 with SMTP id t20mr369238wfh.232.1242219409644; Wed, 13 May 2009 05:56:49 -0700 (PDT) Date: Wed, 13 May 2009 20:56:49 +0800 Message-ID: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> From: Hui Deng To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] One question for IKE/IPsec 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, 13 May 2009 12:55:19 -0000 Dear IPsec forks, May I consult one question here: Whether we could still do IKEv2 negotiation (Authenticaiton), but not use IPsec tunnel? Thanks for your clarificaiton. Best regards, -Hui From kivinen@iki.fi Wed May 13 06:11:59 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 7FC0E3A6D0E for ; Wed, 13 May 2009 06:11:59 -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 e3CvoDhkHgE4 for ; Wed, 13 May 2009 06:11:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6AA3A6A4F for ; Wed, 13 May 2009 06:11:58 -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 n4DDD9rv011353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 16:13:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4DDD8Gr007978; Wed, 13 May 2009 16:13:08 +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: <18954.51044.315805.345174@fireball.kivinen.iki.fi> Date: Wed, 13 May 2009 16:13:08 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 18 min Cc: scott@hyperthought.com, sheila.frankel@nist.gov Subject: [IPsec] Error on RFC 4868 section 2.6.2.3 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, 13 May 2009 13:11:59 -0000 I was adding the RFC4868 test vectors to our code and noticed there is an error in the section 2.6.2.3 test vectors. The last SHA512 test vector has one extra line for the key. The key in the RFC is: Test Case AUTH512-4: Key = 0a0b0c0d0e0f10111213141516171819 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425262728292a2b2c2d2e2f30 3132333435363738393a3b3c3d3e3f40 (64 bytes) As you can clearly see the key is not 64 bytes as is said in the end, but is 80 bytes. On the other hand you can also see that the "0a0b0c0d0e0f10111213141516171819" line in the key does not match the other similar test vectors. If the test vector is changed so that key is 64 bytes from 01 to 40 then the end results given in the RFC are correct. I.e. the correct key for the AUTH512-4 test is: Test Case AUTH512-4: Key = 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425262728292a2b2c2d2e2f30 3132333435363738393a3b3c3d3e3f40 (64 bytes) -- kivinen@iki.fi From sheila.frankel@nist.gov Wed May 13 06: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 73C203A6C61 for ; Wed, 13 May 2009 06:57: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 W86HyLBpOglt for ; Wed, 13 May 2009 06:57:18 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 5A3B13A67FC for ; Wed, 13 May 2009 06:57:18 -0700 (PDT) Received: from navigation (st7.ncsl.nist.gov [129.6.54.64]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n4DDwc6U004257; Wed, 13 May 2009 09:58:41 -0400 From: "Sheila Frankel" To: "'Tero Kivinen'" , References: <18954.51044.315805.345174@fireball.kivinen.iki.fi> Date: Wed, 13 May 2009 09:58:38 -0400 Message-ID: <432263F3BB6343A1A8150CA6B0948B6D@csd893.ncsl.nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <18954.51044.315805.345174@fireball.kivinen.iki.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnTzKkQNqbwdrALRpSS1Dmy50ZhZwABY06w X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: scott@hyperthought.com Subject: Re: [IPsec] Error on RFC 4868 section 2.6.2.3 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, 13 May 2009 13:57:19 -0000 Thanks, Tero. I ran the test cases, but apparently I missed that. Do you know if there's any procedure for reporting errata in RFCs? Sheila -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Wednesday, May 13, 2009 9:13 AM To: ipsec@ietf.org Cc: sheila.frankel@nist.gov; scott@hyperthought.com Subject: Error on RFC 4868 section 2.6.2.3 I was adding the RFC4868 test vectors to our code and noticed there is an error in the section 2.6.2.3 test vectors. The last SHA512 test vector has one extra line for the key. The key in the RFC is: Test Case AUTH512-4: Key = 0a0b0c0d0e0f10111213141516171819 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425262728292a2b2c2d2e2f30 3132333435363738393a3b3c3d3e3f40 (64 bytes) As you can clearly see the key is not 64 bytes as is said in the end, but is 80 bytes. On the other hand you can also see that the "0a0b0c0d0e0f10111213141516171819" line in the key does not match the other similar test vectors. If the test vector is changed so that key is 64 bytes from 01 to 40 then the end results given in the RFC are correct. I.e. the correct key for the AUTH512-4 test is: Test Case AUTH512-4: Key = 0102030405060708090a0b0c0d0e0f10 1112131415161718191a1b1c1d1e1f20 2122232425262728292a2b2c2d2e2f30 3132333435363738393a3b3c3d3e3f40 (64 bytes) -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed May 13 08:03: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 660113A68F0 for ; Wed, 13 May 2009 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 ZVt-ARBshg4Q for ; Wed, 13 May 2009 08:03:22 -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 C9CF03A6909 for ; Wed, 13 May 2009 08:03:21 -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 n4DF4nt2053535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 08:04:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> Date: Wed, 13 May 2009 08:04:50 -0700 To: Hui Deng , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] One question for IKE/IPsec 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, 13 May 2009 15:03:23 -0000 At 8:56 PM +0800 5/13/09, Hui Deng wrote: >Dear IPsec forks, > >May I consult one question here: > >Whether we could still do IKEv2 negotiation (Authenticaiton), >but not use IPsec tunnel? You never need to use a tunnel, regardless of how it was brought up. The tunnel can just sit there, feeling lonely and abandoned, waiting for traffic. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed May 13 08:17: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 7B0CA3A6C3D for ; Wed, 13 May 2009 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 4KJeIJWcAheS for ; Wed, 13 May 2009 08:17:02 -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 665133A65A5 for ; Wed, 13 May 2009 08:17:02 -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 n4DFISvB054647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 08:18:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <432263F3BB6343A1A8150CA6B0948B6D@csd893.ncsl.nist.gov> References: <18954.51044.315805.345174@fireball.kivinen.iki.fi> <432263F3BB6343A1A8150CA6B0948B6D@csd893.ncsl.nist.gov> Date: Wed, 13 May 2009 08:18:28 -0700 To: "Sheila Frankel" , "'Tero Kivinen'" , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: scott@hyperthought.com Subject: Re: [IPsec] Error on RFC 4868 section 2.6.2.3 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, 13 May 2009 15:17:03 -0000 At 9:58 AM -0400 5/13/09, Sheila Frankel wrote: >Thanks, Tero. I ran the test cases, but apparently I missed that. Do you >know if there's any procedure for reporting errata in RFCs? See www.rfc-editor.org. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Wed May 13 08:49: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 0F1173A68DF for ; Wed, 13 May 2009 08:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 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 VswCsVOdc6hm for ; Wed, 13 May 2009 08:49:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EE3C13A68D4 for ; Wed, 13 May 2009 08:49:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 516232CC002; Wed, 13 May 2009 18:50:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1CED7200E04; Wed, 13 May 2009 18:50:34 +0300 (IDT) X-CheckPoint: {4A0AEBA3-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 n4DFoXqO001552; Wed, 13 May 2009 18:50:33 +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, 13 May 2009 18:50:33 +0300 From: Yoav Nir To: Paul Hoffman , Hui Deng , "ipsec@ietf.org" Date: Wed, 13 May 2009 18:53:35 +0300 Thread-Topic: [IPsec] One question for IKE/IPsec Thread-Index: AcnT3DRL97A47EhESC2KZsYMMxKzCAABqDCQ Message-ID: <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] One question for IKE/IPsec 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, 13 May 2009 15:49:04 -0000 Paul Hoffman wrote: >=20 > At 8:56 PM +0800 5/13/09, Hui Deng wrote: > >Dear IPsec forks, > > > >May I consult one question here: > > > >Whether we could still do IKEv2 negotiation=20 > (Authenticaiton), but not=20 > >use IPsec tunnel? >=20 > You never need to use a tunnel, regardless of how it was=20 > brought up. The tunnel can just sit there, feeling lonely and=20 > abandoned, waiting for traffic. Yes, but you can't rely on the peer not having a policy that says "all tunn= els that are idle for 30 seconds get deleted" Email secured by Check Point From paul.hoffman@vpnc.org Wed May 13 09:04: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 EF8863A6A4F for ; Wed, 13 May 2009 09:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 jhOvi+xRm5QT for ; Wed, 13 May 2009 09:04: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 DAB043A68D9 for ; Wed, 13 May 2009 09:04:40 -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 n4DG66GB059772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 09:06:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> Date: Wed, 13 May 2009 09:06:04 -0700 To: Yoav Nir , Hui Deng , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] One question for IKE/IPsec 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, 13 May 2009 16:04:42 -0000 At 6:53 PM +0300 5/13/09, Yoav Nir wrote: >Paul Hoffman wrote: >> >> At 8:56 PM +0800 5/13/09, Hui Deng wrote: >> >Dear IPsec forks, >> > >> >May I consult one question here: >> > >> >Whether we could still do IKEv2 negotiation >> (Authenticaiton), but not >> >use IPsec tunnel? >> >> You never need to use a tunnel, regardless of how it was >> brought up. The tunnel can just sit there, feeling lonely and >> abandoned, waiting for traffic. > >Yes, but you can't rely on the peer not having a policy that says "all tunnels that are idle for 30 seconds get deleted" Of course, but that's not what Hui asked. In his scenario, he should assume that the tunnel will get nuked by one side or the other either due to disuse or an active management choice. --Paul Hoffman, Director --VPN Consortium From paulmoore100@hotmail.com Wed May 13 10:31: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 9BD7B3A6915 for ; Wed, 13 May 2009 10:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=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 FsBpd2NACarP for ; Wed, 13 May 2009 10:31:15 -0700 (PDT) Received: from bay0-omc2-s34.bay0.hotmail.com (bay0-omc2-s34.bay0.hotmail.com [65.54.246.170]) by core3.amsl.com (Postfix) with ESMTP id 000373A6906 for ; Wed, 13 May 2009 10:31:14 -0700 (PDT) Received: from BAY106-DS5 ([65.54.161.94]) by bay0-omc2-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 10:32:47 -0700 X-Originating-IP: [216.112.107.99] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "paul moore" To: Date: Wed, 13 May 2009 10:32:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 13 May 2009 17:32:47.0833 (UTC) FILETIME=[D524A490:01C9D3F0] Subject: [IPsec] ike v1 IV question 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, 13 May 2009 17:31:15 -0000 How should the IV be set for an informational message that is generated during phase 1? I see conflicting implementations and the V1 RFCs dont say (or at least dont say it clearly) Specific example is when doing a cert auth phase1 and the responder rejects the cert, the responder sends a informational notify to the initiator. What should the IV on that Inf N be? From smoonen@us.ibm.com Wed May 13 10:38: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 B21373A6AB2 for ; Wed, 13 May 2009 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.333, 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 ifLHpAtXmYYu for ; Wed, 13 May 2009 10:38:11 -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 9E7DD3A6915 for ; Wed, 13 May 2009 10:38:11 -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 n4DHZn1b009855 for ; Wed, 13 May 2009 11:35:49 -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 n4DHdZ2b164700 for ; Wed, 13 May 2009 11:39:35 -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 n4DHdZ03016975 for ; Wed, 13 May 2009 11:39:35 -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 n4DHdZ7T016965 for ; Wed, 13 May 2009 11:39:35 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: CEF9CBC5:553ACFF6-852575B5:005E9922; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Wed, 13 May 2009 13:39:34 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/13/2009 11:39:35, Serialize complete at 05/13/2009 11:39:35 Content-Type: multipart/alternative; boundary="=_alternative 0060FEB7852575B5_=" Subject: [IPsec] RFC 4869 questions 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, 13 May 2009 17:38:12 -0000 This is a multipart message in MIME format. --=_alternative 0060FEB7852575B5_= Content-Type: text/plain; charset="US-ASCII" I'm reviewing RFC 4869 and it seems to under-specify the attributes that are needed to achieve real interoperability: it doesn't specify whether to do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor does it specify IKEv1 lifetime and lifesize values. So I am left having to guess at what are appropriate values to use for these attributes. And once I do choose particular values for PFS and lifesize, is it still correct for me to use the RFC's suite names in reference to them? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0060FEB7852575B5_= Content-Type: text/html; charset="US-ASCII"
I'm reviewing RFC 4869 and it seems to under-specify the attributes that are needed to achieve real interoperability: it doesn't specify whether to do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor does it specify IKEv1 lifetime and lifesize values.  So I am left having to guess at what are appropriate values to use for these attributes.  And once I do choose particular values for PFS and lifesize, is it still correct for me to use the RFC's suite names in reference to them?


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0060FEB7852575B5_=-- From kent@bbn.com Wed May 13 10:48: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 3A5AE3A6FDB for ; Wed, 13 May 2009 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 8y8kNhPG53jS for ; Wed, 13 May 2009 10:48:35 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 77C783A6FF9 for ; Wed, 13 May 2009 10:47:47 -0700 (PDT) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M4IZy-0001FB-Er; Wed, 13 May 2009 13:49:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2E13B90533934A499FD727F9B353613C02F87F@zin33exm29.fsl.freescale.net> References: <200905120704.n4C74bYZ029918@az33smr01.freescale.net> <2E13B90533934A499FD727F9B353613C02F87F@zin33exm29.fsl.freescale.net> Date: Wed, 13 May 2009 13:49:14 -0400 To: "Murthy N Srinivas-B22237" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-969885538==_ma============" Cc: ipsec@ietf.org Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods 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, 13 May 2009 17:48:36 -0000 --============_-969885538==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:34 PM +0530 5/12/09, Murthy N Srinivas-B22237 wrote: >Is there a new draft/rfc posted with the change incorporated? > >-ns murthy DES is deprecated, so I would not expect a revised RFC on that. AES is strongly preferred over 3DES, so there is little incentive to rev that doc, although it makes more sense than for DES. Steve --============_-969885538==_ma============ Content-Type: text/html; charset="us-ascii" RE: [IPsec] IV in ESP packets for DES and 3DES methods
At 9:34 PM +0530 5/12/09, Murthy N Srinivas-B22237 wrote:
Is there a new draft/rfc posted with the change incorporated?
 
-ns murthy

DES is deprecated, so I would not expect a revised RFC on that.  AES is strongly preferred over 3DES, so there is little incentive to rev that doc, although it makes more sense than for DES.

Steve
--============_-969885538==_ma============-- From g_e_montenegro@yahoo.com Wed May 13 12:23: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 DB7FB3A6A95 for ; Wed, 13 May 2009 12:23:49 -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 tfP+ocoG1ATC for ; Wed, 13 May 2009 12:23:49 -0700 (PDT) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id EEC953A6972 for ; Wed, 13 May 2009 12:23:48 -0700 (PDT) Received: (qmail 49452 invoked by uid 60001); 13 May 2009 19:25:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242242719; bh=rY7Zw4AOLq7h3QjYTPN5vZi9s2Tp5Gd6NnTiDAiOSG0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ehZlJ0TxNVsNo0668SJel/oXB4PI3A4Xge1Eb4X5I6pNbanDJDOIZW3APZ+sR245EwJvjWoSy1j35fs8Ez+seFGG/dZMpftkfpXhUE18GAw/QdhGEdXlgAEKxpXheuFTcUg9GIcyQJUCnzuOWHOE+TZ/IiZJ29/frdXDgXQzKeI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=48sbblxZLPfe85H8KgMhQcIVoAt2rNhAu6lAye89zFXRJlKKDJ4IUfx5sP6HBouaPNxkkpjzhQOOEuUs/7RjVa7NFXIkV7K+CTBtJqa5OQfcTHZ/xF0FGEBzyVRk8t3YDV88lFPS0AdybaHSexs89/xDOjIAi7imt3VNvCjaolo=; Message-ID: <223656.42022.qm@web82603.mail.mud.yahoo.com> X-YMail-OSG: 3AMny8gVM1n9J.Yy1F8ADmpYDAm.BreGL0QC4Z47y3t_ypphIgSHWYz96gn4sOkhF9Zz4DDorI9.muPhILpqskBIn4L1WJ78A.zRLvM94brcNbxyBbX1FaEy24ixZ5A1hHaIH_usaFSJe.5o1YDsd4qnj0zkmp9v40tvh0UToTsMDF8ZG7LnbCgKWkmh9QwVCJ1mGXsB874JbZ8Y8G59mWhmZ1ldBXEWMxm9OG9DX.XFDjvJgigXY.7_nRA76WceOp3lQUwiNZ5ajovL8ZOF1_wtIl6k_TMA7.XA4o5XysVyloJS1avbKYn07NQalHXb_yGdygr6afI6.R9TPx4- Received: from [131.107.0.82] by web82603.mail.mud.yahoo.com via HTTP; Wed, 13 May 2009 12:25:19 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Wed, 13 May 2009 12:25:19 -0700 (PDT) From: gabriel montenegro To: Stephen Kent , "Bhatia, Manav \(Manav\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Next Header field in WESP header 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, 13 May 2009 19:23:49 -0000 We agree, and tried to capture that in the current version at:=0Ahttp://too= ls.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-02 =0A=0Awith text s= uch as:=0A=0A=A0=A0 Next Header, 8 bits:=A0 If using ESP-NULL, this field M= UST be=0A=A0=A0 equal to the Next Header field in the ESP trailer. If using= ESP=0A=A0=A0 in encryption mode, this field MUST be set to zero..=0A=0Aand= in the security considerations section:=0A=0A=A0=A0 ESP is end-to-end and = it will be impossible for the intermediate=0A=A0=A0 devices to verify that = all the fields in the WESP header are=0A=A0=A0 correct. It is thus possible= to tweak the WESP header so that=0A=A0=A0 the packet sneaks past the firew= all if the fields in the WESP=0A=A0=A0 header are set to something that the= firewall will allow. The=0A=A0=A0 endpoint thus must verify the sanity of = the WESP header before=0A=A0=A0 accepting the packet. In an extreme case, s= omeone colluding with=0A=A0=A0 the attacker, could change the WESP fields b= ack to the original=0A=A0=A0 values so that the attack goes unnoticed. Howe= ver, this is not a=0A=A0=A0 new problem and it already exists IPSec.=0A=0AP= erhaps we need more details on what exactly we mean by "the=0Aendpoint thus= must verify the sanity of the WESP header before accepting=0Athe packet"? = And the action to drop the offending packet?=0A=0A----- Original Message --= --=0A> From: Stephen Kent =0A> To: "Bhatia, Manav (Manav)" =0A> Cc: "ipsec@ietf.org" ; gabriel= montenegro ; Tero Kivinen =0A> S= ent: Tuesday, May 12, 2009 8:18:18 AM=0A> Subject: Re: [IPsec] Next Header = field in WESP header=0A> =0A> If we elect to keep the next header field, to= help middle boxes quickly locate =0A> header fields of interest to them, t= hen we MUST require the recipient of each =0A> message to do a (well-define= d) consistency check on the packet, for the reasons =0A> I cited in=A0 SF.= =0A> =0A> Steve=0A> _______________________________________________=0A> IPs= ec mailing list=0A> IPsec@ietf.org=0A> https://www.ietf.org/mailman/listinf= o/ipsec=0A From ynir@checkpoint.com Wed May 13 13: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 4E58F3A6BCD for ; Wed, 13 May 2009 13:50:04 -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 5PWYBM9hv6WH for ; Wed, 13 May 2009 13:50:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 58DE53A693E for ; Wed, 13 May 2009 13:50:03 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 590E4200E0E; Wed, 13 May 2009 23:51:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C799A200DFB; Wed, 13 May 2009 23:51:33 +0300 (IDT) X-CheckPoint: {4A0B322C-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 n4DKpXqO009040; Wed, 13 May 2009 23:51:33 +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, 13 May 2009 23:51:32 +0300 From: Yoav Nir To: Scott C Moonen , "ipsec@ietf.org" Date: Wed, 13 May 2009 23:51:32 +0300 Thread-Topic: [IPsec] RFC 4869 questions Thread-Index: AcnT8fPn0zgSKlvyRWqxiCCopqB26AAGbt34 Message-ID: <9FB7C7CE79B84449B52622B506C780361341113028@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] RFC 4869 questions 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, 13 May 2009 20:50:04 -0000 Scott C Moonen wrote: > > I'm reviewing RFC 4869 and it seems to under-specify the attributes that= =20 > are needed to achieve real interoperability: it doesn't specify whether t= o > do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor=20 > does it specify IKEv1 lifetime and lifesize values. So I am left having = to=20 > guess at what are appropriate values to use for these attributes. And=20 > once I do choose particular values for PFS and lifesize, is it still corr= ect=20 > for me to use the RFC's suite names in reference to them? Interesting. I hadn't noticed that. I guess the best thing is to do as in RFC 4308: " = ...The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type..." IOW it's up to the initiator whether or not to do PFS, and both configurati= ons are OK to use the suite name.=20 As for lifetimes, at least our implementation has a separate configuration = for it.=20 Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to act= ually=20 specify it in the RFC. But you are right. Especially since this is a followup to RFC 4869, they sh= ould have=20 included these parameters. = Email secured by Check Point From paul.hoffman@vpnc.org Wed May 13 14:09: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 C82163A6FF8 for ; Wed, 13 May 2009 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 coxy0rcMdwMZ for ; Wed, 13 May 2009 14:09: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 9B9A63A6FE6 for ; Wed, 13 May 2009 14:09:42 -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 n4DLB9w4083980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2009 14:11:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FB7C7CE79B84449B52622B506C780361341113028@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C780361341113028@il-ex01.ad.checkpoint.com> Date: Wed, 13 May 2009 14:11:07 -0700 To: Yoav Nir , Scott C Moonen , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] RFC 4869 questions 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, 13 May 2009 21:09:43 -0000 At 11:51 PM +0300 5/13/09, Yoav Nir wrote: >Scott C Moonen wrote: >> >> I'm reviewing RFC 4869 and it seems to under-specify the attributes that >> are needed to achieve real interoperability: it doesn't specify whether to >> do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor >> does it specify IKEv1 lifetime and lifesize values. So I am left having to >> guess at what are appropriate values to use for these attributes. And >> once I do choose particular values for PFS and lifesize, is it still correct >> for me to use the RFC's suite names in reference to them? > >Interesting. I hadn't noticed that. > >I guess the best thing is to do as in RFC 4308: >" ...The initiator of this > exchange MAY include a new Diffie-Hellman key; if it is included, it > MUST be of type..." > >IOW it's up to the initiator whether or not to do PFS, and both configurations >are OK to use the suite name. That was my intention in RFC 4308; I cannot speak for the authors of RFC 4869. >As for lifetimes, at least our implementation has a separate configuration for it. >Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually >specify it in the RFC. Fully disagree. "Negotiated" in IKEv1 is the wrong word: the responder either accepts what the initiator says, or stops. Most IKEv1 systems require that lifetimes match exactly; that's why I had to include section 2.3 in RFC 4308. Having said that, it is fine for a profile not to list lifetimes explicitly; it just means that the two sides still have to agree to lifefimes out-of-band. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Wed May 13 21:59: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 4D85B3A6AC8 for ; Wed, 13 May 2009 21:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 2ARlNKbfh3Q4 for ; Wed, 13 May 2009 21:59:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5612E3A69E7 for ; Wed, 13 May 2009 21:59:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6216029C001; Thu, 14 May 2009 08:01:19 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 12D17200E04 for ; Thu, 14 May 2009 08:01:19 +0300 (IDT) X-CheckPoint: {4A0BA4F3-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 n4E51IqO019881 for ; Thu, 14 May 2009 08:01:18 +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, 14 May 2009 08:01:18 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 14 May 2009 08:01:15 +0300 Thread-Topic: Redirect -09 comments Thread-Index: AcnUUQKW97cHVLC9RD6K6Gnsr2QH0A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@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_003E_01C9D46A.27EF35E0" MIME-Version: 1.0 Subject: [IPsec] Redirect -09 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: Thu, 14 May 2009 04:59:49 -0000 ------=_NextPart_000_003E_01C9D46A.27EF35E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003F_01C9D46A.27EF35E0" ------=_NextPart_001_003F_01C9D46A.27EF35E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, While preparing to progress the draft to AD review, I reread it once again. Here are a few comments. Although not all are nits, none of them should block the document now. Thanks, Yaron Not-quite-nits: General: a long way back we discussed loop avoidance, but this never made its way into the draft. The document implicitly allows multiple redirections in sequence. We should specify somewhere that the client MUST have a threshold value X (possibly 1), where it is willing to redirect at most X times in sequence. This is meant to deal with faulty configuration, not with active attacks. 9. I believe the last sentence "To protect against this kind of attack the redirection based on the ID should happen only after client has also authenticated himself." should read "after the *gateway* has also authenticated itself". 10. Please add at the end of the section: A specification that extends this registry MUST also define in which notification(s) the new values are allowed. Nits: 1. "connect to the IP address of the VPN gateways", change "gateways" to "gateway". 3. "In practice, this means the new gateway either", remove one "either". 6. mesage -> message 6. "presented by the client in the first IKE_AUTH exchange itself." - this text is duplicated. ------=_NextPart_001_003F_01C9D46A.27EF35E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While preparing to progress the draft to AD review, I = reread it once again. Here are a few comments. Although not all are nits, none = of them should block the document now.

 

Thanks,

         =    Yaron

 

Not-quite-nits:

 

General: a long way back we discussed loop avoidance, = but this never made its way into the draft. The document implicitly allows = multiple redirections in sequence. We should specify somewhere that the client = MUST have a threshold value X (possibly 1), where it is willing to redirect at = most X times in sequence. This is meant to deal with faulty configuration, not = with active attacks.

 

9. I believe the last sentence "To protect = against this kind of attack the redirection based on the ID should happen only after = client has also authenticated himself." should read "after the = *gateway* has also authenticated itself".

 

10. Please add at the end of the section: A = specification that extends this registry MUST also define in which notification(s) the = new values are allowed.

 

Nits:

 

1. "connect to the IP address of the VPN gateways", change "gateways" to = "gateway".

 

3. "In practice, this means the new gateway either", remove one = "either".

 

6. mesage -> message

 

6. "presented by the client in the first = IKE_AUTH exchange itself." - this text is duplicated.

------=_NextPart_001_003F_01C9D46A.27EF35E0-- ------=_NextPart_000_003E_01C9D46A.27EF35E0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNDA1MDExNVowIwYJKoZIhvcNAQkEMRYEFOKYda54B5Dv sW3h3v5j6QCw4s7vMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA jQYs/5b8eJKc+eWRUxYOd6nMP9jhxeDLjZ/TkoE2my9Q/SN2IhgBnvUJXApTDHL79eNahBb7ghkx jZYptr6XK4v/4qd0U1HNSxLVV9KLypkcNKVBnZSOuLVGRZxzyHK867xk6buLLzUAoMLqTQzguNpO 1zgmombAB1m96/1v0asLaA2ENBxn8xAEeZQLXkkZMPF0XXFFO5f9G5+JUZWooZf0qrAe5gbjPIzU 7cTAB7ZSoUMRDkXv8UAsn+wtNGCLVB4UwbjEO2+ekuF6QBAUrcX15pm8L0Twl+qW/vn4J1ypa/vP 9NgF+DcIABtWISy8FTyPSEdi1mFGtO1dbP/yywAAAAAAAA== ------=_NextPart_000_003E_01C9D46A.27EF35E0-- From ynir@checkpoint.com Wed May 13 23:24:28 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 84FE228C207 for ; Wed, 13 May 2009 23:24:28 -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 9f5T1ABG9Az5 for ; Wed, 13 May 2009 23:24:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9957C28C1EC for ; Wed, 13 May 2009 23:24:27 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E782200E0E; Thu, 14 May 2009 09:25:59 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 526E7200E04; Thu, 14 May 2009 09:25:59 +0300 (IDT) X-CheckPoint: {4A0BB8CA-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 n4E6PwqO008015; Thu, 14 May 2009 09:25: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; Thu, 14 May 2009 09:25:58 +0300 From: Yoav Nir To: Paul Hoffman , Scott C Moonen , "ipsec@ietf.org" Date: Thu, 14 May 2009 09:29:02 +0300 Thread-Topic: [IPsec] RFC 4869 questions Thread-Index: AcnUD1kWCyB0EPUEQlW2XyWuhIoTVQATEIpQ Message-ID: <9FB7C7CE79B84449B52622B506C7803613410ED819@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C780361341113028@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 Subject: Re: [IPsec] RFC 4869 questions 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, 14 May 2009 06:24:28 -0000 Paul Hoffman wrote:=20 > > >IOW it's up to the initiator whether or not to do PFS, and both=20 > >configurations are OK to use the suite name. >=20 > That was my intention in RFC 4308; I cannot speak for the=20 > authors of RFC 4869. You can't speak for them, but Scott has to figure it out. > >As for lifetimes, at least our implementation has a separate=20 > configuration for it. > >Lifetimes in IKEv1 are negotiated, so I don't believe it's=20 > necessary to=20 > >actually specify it in the RFC. >=20 > Fully disagree. "Negotiated" in IKEv1 is the wrong word: the=20 > responder either accepts what the initiator says, or stops.=20 > Most IKEv1 systems require that lifetimes match exactly;=20 > that's why I had to include section 2.3 in RFC 4308. Having=20 > said that, it is fine for a profile not to list lifetimes=20 > explicitly; it just means that the two sides still have to=20 > agree to lifefimes out-of-band. Not necessary at all. The RESPONDER-LIFETIME notification described in sect= ion 4.6.3.1 or RFC 2407 allows for a negotiation of the SA lifetime. True, = section 4.5.4 says you may also fail the negotiation or stop using the SA p= rematurely, but that would be the wrong implementation choice. Email secured by Check Point From kivinen@iki.fi Thu May 14 02:00:28 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 7277228C21C for ; Thu, 14 May 2009 02:00:28 -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 yDxSuUM34YMn for ; Thu, 14 May 2009 02:00:27 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFD928C207 for ; Thu, 14 May 2009 02:00:27 -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 n4E91a8h007785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 12:01:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4E91ZCd017907; Thu, 14 May 2009 12:01:35 +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: <18955.56815.45070.926714@fireball.kivinen.iki.fi> Date: Thu, 14 May 2009 12:01:35 +0300 From: Tero Kivinen To: gabriel montenegro In-Reply-To: <223656.42022.qm@web82603.mail.mud.yahoo.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> <223656.42022.qm@web82603.mail.mud.yahoo.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Next Header field in WESP header 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, 14 May 2009 09:00:28 -0000 gabriel montenegro writes: > Perhaps we need more details on what exactly we mean by "the > endpoint thus must verify the sanity of the WESP header before accepting > the packet"? And the action to drop the offending packet? Yes. I think we need very specific rules with MUSTs in them to say that packet MUST be dropped if ESP-NULL packet has Next header field in WESP header which do not match the real Next Header field in the end. Also final recipient MUST check that the HdrLen or TrailerLen fields in the WESP header match the negotiate SA and MUST drop the packet if they do not match. Next question is what values are used for HdrLen and TrailerLen if encrypted ESP is used. If we use real values we do leak out information, but on the other hand there is no point of giving that information out as middle nodes cannot do anything with it. Actually what are we trying to do if we send encrypted ESP with WESP wrapper. If we are just making so that we can extend the WESP header in the future, isn't the version bits enough for that? I mean if we do not know why someone would want to use WESP encoding for encrypted ESP now, why do we allow it? -- kivinen@iki.fi From yaronf@checkpoint.com Thu May 14 02:11: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 BE68128C232 for ; Thu, 14 May 2009 02:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 FgBfG+vMgdu0 for ; Thu, 14 May 2009 02:11:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3B18828C237 for ; Thu, 14 May 2009 02:10:42 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BBB9929C001; Thu, 14 May 2009 12:12:12 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6895D200E04; Thu, 14 May 2009 12:12:12 +0300 (IDT) X-CheckPoint: {4A0BDFBE-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 n4E9CBqP024604; Thu, 14 May 2009 12:12:11 +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, 14 May 2009 12:12:10 +0300 From: Yaron Sheffer To: Tero Kivinen , gabriel montenegro Date: Thu, 14 May 2009 12:12:09 +0300 Thread-Topic: [IPsec] Next Header field in WESP header Thread-Index: AcnUcqlNZY3HUlAPT8GbzitBM6jA5AAAMSig Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583EAF@il-ex01.ad.checkpoint.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> <223656.42022.qm@web82603.mail.mud.yahoo.com> <18955.56815.45070.926714@fireball.kivinen.iki.fi> In-Reply-To: <18955.56815.45070.926714@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_0063_01C9D48D.34A5AD00" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Next Header field in WESP header 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, 14 May 2009 09:11:13 -0000 ------=_NextPart_000_0063_01C9D48D.34A5AD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. So yes, we use WESP for encrypted traffic to get: - Extensibility (with the 8-bit Flags field). - A single protocol that can do both cases. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Thursday, May 14, 2009 12:02 > To: gabriel montenegro > Cc: ipsec@ietf.org; Bhatia, Manav (Manav); Stephen Kent > Subject: Re: [IPsec] Next Header field in WESP header > > gabriel montenegro writes: > > Perhaps we need more details on what exactly we mean by "the > > endpoint thus must verify the sanity of the WESP header before accepting > > the packet"? And the action to drop the offending packet? > > Yes. I think we need very specific rules with MUSTs in them to say > that packet MUST be dropped if ESP-NULL packet has Next header field > in WESP header which do not match the real Next Header field in the > end. Also final recipient MUST check that the HdrLen or TrailerLen > fields in the WESP header match the negotiate SA and MUST drop the > packet if they do not match. > > Next question is what values are used for HdrLen and TrailerLen if > encrypted ESP is used. If we use real values we do leak out > information, but on the other hand there is no point of giving that > information out as middle nodes cannot do anything with it. > > Actually what are we trying to do if we send encrypted ESP with WESP > wrapper. If we are just making so that we can extend the WESP header > in the future, isn't the version bits enough for that? I mean if we do > not know why someone would want to use WESP encoding for encrypted ESP > now, why do we allow it? > -- > 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_0063_01C9D48D.34A5AD00 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNDA5MTIwOVowIwYJKoZIhvcNAQkEMRYEFCRsdzo+X7pX RcdjS29c8PEZFfxJMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA bPZ+Czu9KRkvzCX8N/YrMVuIgPg0kaNxxuNVWmRWwsJOMJEQnCulz38dDIprHQriQ/T4NTUTHjCp DCJm00U7TFEwS6BRJB2gILT+dfxXeg9mrCBq1kzBDDeCaYC2rCleMi25tiMunTLHT15SgYQI7LIb fWaApNup/LjSKvDKsPANB3PAkhCSAkTlZUOZwKlvgp/TXN0vkuPsz4J8w99UkCZjqh/j+nvC0/eN 0Q5xiL1J3PlTflmvobYRfR/XomrippFsxJx9GMJvxZe/PT6NuFYxfodRQ2aZODnflw5bkbGhcdV3 07eXQaNv6If1BO+SDUoCIbznlZp+LwAYJn0gPgAAAAAAAA== ------=_NextPart_000_0063_01C9D48D.34A5AD00-- From kivinen@iki.fi Thu May 14 03:37: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 33EB23A688C for ; Thu, 14 May 2009 03:37:13 -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 3HSDZNpmuvqE for ; Thu, 14 May 2009 03:37:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F2E7A3A6904 for ; Thu, 14 May 2009 03:37: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 n4EAcOF2026371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 13:38:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4EAcMGx007097; Thu, 14 May 2009 13:38:22 +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: <18955.62622.459433.274094@fireball.kivinen.iki.fi> Date: Thu, 14 May 2009 13:38:22 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583EAF@il-ex01.ad.checkpoint.com> References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> <223656.42022.qm@web82603.mail.mud.yahoo.com> <18955.56815.45070.926714@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583EAF@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: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , gabriel montenegro , Stephen Kent Subject: Re: [IPsec] Next Header field in WESP header 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, 14 May 2009 10:37:13 -0000 Yaron Sheffer writes: > I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. > So yes, we use WESP for encrypted traffic to get: > > - Extensibility (with the 8-bit Flags field). This is future extensibility, which is needed only after we define some future extensions using this. When we define those future extensions we can also define that encrypted traffic can be used. I would rather keep this for future extension, i.e. only define the use after we find out what we want to do, as all the end nodes needs to be updated anyways before those new extensions can be used (and the intermediate nodes too perhaps). The current document is not very clear what to do if reserved bits are set. It says "On receiving a packet, these values must be checked to ensure that they are as indicated above.". This does not specify whether this is only for the final receiver (i.e. the node talking IPsec), or also all intermediate nodes, or only those intermediate nodes who actually look inside the WESP or what. It also does not specify what needs to be done if those fields are not as specified. I.e. we need more text for that, i.e. specific processing rules for a) intermediate nodes who parse WESP header, b) end IPsec entity. In some cases the dropping / passbying the packet depends on the policy. On the other hand if flags is set or version number does not match then that usually means that the format of the WESP header might be different thus it might be that intermediate nodes cannot parse header any further. > - A single protocol that can do both cases. By wasting extra 4 bytes and using protocol which might not be supported by other end. I think it is better to use plan normal ESP for encrypted traffic, but I agree that we should probably define the WESP header so that if Next Header in WESP header is 0 then contents is encrypted, and intermediate nodes MUST NOT try to parse it. I would still recommend using normal ESP for encrypted traffic... -- kivinen@iki.fi From smoonen@us.ibm.com Thu May 14 05:30: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 DB0163A7024 for ; Thu, 14 May 2009 05:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.286, 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 oNk5L9GW7uUV for ; Thu, 14 May 2009 05:30:24 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 5D5173A6F16 for ; Thu, 14 May 2009 05:30:23 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4ECTAdv016814 for ; Thu, 14 May 2009 06:29:10 -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 n4ECVn5M238542 for ; Thu, 14 May 2009 06:31:50 -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 n4ECVnoW003053 for ; Thu, 14 May 2009 06:31:49 -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 n4ECVnM9003047 for ; Thu, 14 May 2009 06:31:49 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 1907302E:A78A84A6-852575B6:0044376F; 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 05/14/2009 08:31:30 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 05/14/2009 08:31:30 AM, Serialize complete at 05/14/2009 08:31:30 AM, S/MIME Sign failed at 05/14/2009 08:31:30 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/14/2009 06:31:48, Serialize complete at 05/14/2009 06:31:48 Message-ID: Date: Thu, 14 May 2009 08:31:47 -0400 Content-Type: multipart/alternative; boundary="=_alternative 0044CD58852575B6_=" Subject: [IPsec] another RFC 4869 question 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, 14 May 2009 12:30:26 -0000 This is a multipart message in MIME format. --=_alternative 0044CD58852575B6_= Content-Type: text/plain; charset="US-ASCII" RFC 4869 makes some statements like: The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-256 [RFC4754]. That seems to me like an empty statement, since it doesn't require any particular set of choices nor does it proscribe any choice. Is it intended to proscribe the use of non-ECDSA digital signatures such as RSA, and therefore limit the options to pre-shared key and ECDSA-256? I wonder if it should read "MUST" instead? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 0044CD58852575B6_= Content-Type: text/html; charset="US-ASCII"
RFC 4869 makes some statements like:

   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

That seems to me like an empty statement, since it doesn't require any particular set of choices nor does it proscribe any choice.

Is it intended to proscribe the use of non-ECDSA digital signatures such as RSA, and therefore limit the options to pre-shared key and ECDSA-256?  I wonder if it should read "MUST" instead?


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 0044CD58852575B6_=-- From smoonen@us.ibm.com Thu May 14 05:30: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 B41253A6D7C for ; Thu, 14 May 2009 05:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 c-N637vYMk3Z for ; Thu, 14 May 2009 05:30:34 -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 EB1523A6C6C for ; Thu, 14 May 2009 05:30:31 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4ECPw9C027274 for ; Thu, 14 May 2009 06:25:58 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4ECVqwk118774 for ; Thu, 14 May 2009 06:31:55 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n4ECWG80003266 for ; Thu, 14 May 2009 06:32:16 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n4ECWG7S003263; Thu, 14 May 2009 06:32:16 -0600 In-Reply-To: <9FB7C7CE79B84449B52622B506C780361341113028@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C780361341113028@il-ex01.ad.checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: EBFA767D:A9DDB31C-852575B6:0041B756; 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 05/14/2009 08:25:03 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 05/14/2009 08:25:03 AM, Serialize complete at 05/14/2009 08:25:03 AM, S/MIME Sign failed at 05/14/2009 08:25:03 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 05/14/2009 06:31:48, Serialize complete at 05/14/2009 06:31:48 Message-ID: Date: Thu, 14 May 2009 08:31:47 -0400 Content-Type: multipart/alternative; boundary="=_alternative 00443631852575B6_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC 4869 questions 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, 14 May 2009 12:30:35 -0000 This is a multipart message in MIME format. --=_alternative 00443631852575B6_= Content-Type: text/plain; charset="US-ASCII" Yoav Nir writes: > I guess the best thing is to do as in RFC 4308: > " ...The initiator of this > exchange MAY include a new Diffie-Hellman key; if it is included, it > MUST be of type..." That makes sense philosophically, but I would like to get the RFC updated or clarified rather than assume that. > As for lifetimes, at least our implementation has a separate configuration for it. > Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually > specify it in the RFC. But that equivocates on the notion of what constitutes a "suite" when compared to RFC 4308, and it also doesn't make sense considering that lifetime and lifesize are represented alongside algorithm choice in the IKEv1 proposal. So this creates problems for implementations like ours (unlike yours) that take the natural approach of including lifetime and lifesize in their notion of a reusable suite object. We now must implement some sort of partially-defined suite object as a kind of abstract class that leaves the lifetime and lifesize undefined. That's not an elegant approach to workaround what I am hoping is just an oversight in the RFC. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yoav Nir To: Scott C Moonen/Raleigh/IBM@IBMUS, "ipsec@ietf.org" Date: 05/13/2009 04:53 PM Subject: RE: [IPsec] RFC 4869 questions Scott C Moonen wrote: > > I'm reviewing RFC 4869 and it seems to under-specify the attributes that > are needed to achieve real interoperability: it doesn't specify whether to > do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor > does it specify IKEv1 lifetime and lifesize values. So I am left having to > guess at what are appropriate values to use for these attributes. And > once I do choose particular values for PFS and lifesize, is it still correct > for me to use the RFC's suite names in reference to them? Interesting. I hadn't noticed that. I guess the best thing is to do as in RFC 4308: " ...The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type..." IOW it's up to the initiator whether or not to do PFS, and both configurations are OK to use the suite name. As for lifetimes, at least our implementation has a separate configuration for it. Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually specify it in the RFC. But you are right. Especially since this is a followup to RFC 4869, they should have included these parameters. Email secured by Check Point --=_alternative 00443631852575B6_= Content-Type: text/html; charset="US-ASCII"
Yoav Nir writes:

> I guess the best thing is to do as in RFC 4308:
> "  ...The initiator of this
>    exchange MAY include a new Diffie-Hellman key; if it is included, it
>    MUST be of type..."

That makes sense philosophically, but I would like to get the RFC updated or clarified rather than assume that.

> As for lifetimes, at least our implementation has a separate configuration for it.
> Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually
> specify it in the RFC.

But that equivocates on the notion of what constitutes a "suite" when compared to RFC 4308, and it also doesn't make sense considering that lifetime and lifesize are represented alongside algorithm choice in the IKEv1 proposal.  So this creates problems for implementations like ours (unlike yours) that take the natural approach of including lifetime and lifesize in their notion of a reusable suite object.  We now must implement some sort of partially-defined suite object as a kind of abstract class that leaves the lifetime and lifesize undefined.  That's not an elegant approach to workaround what I am hoping is just an oversight in the RFC.


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


From: Yoav Nir <ynir@checkpoint.com>
To: Scott C Moonen/Raleigh/IBM@IBMUS, "ipsec@ietf.org" <ipsec@ietf.org>
Date: 05/13/2009 04:53 PM
Subject: RE: [IPsec] RFC 4869 questions




Scott C Moonen wrote:
>
> I'm reviewing RFC 4869 and it seems to under-specify the attributes that
> are needed to achieve real interoperability: it doesn't specify whether to
> do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor
> does it specify IKEv1 lifetime and lifesize values.  So I am left having to
> guess at what are appropriate values to use for these attributes.  And
> once I do choose particular values for PFS and lifesize, is it still correct
> for me to use the RFC's suite names in reference to them?

Interesting. I hadn't noticed that.

I guess the best thing is to do as in RFC 4308:
"                                                                          ...The initiator of this
  exchange MAY include a new Diffie-Hellman key; if it is included, it
  MUST be of type..."

IOW it's up to the initiator whether or not to do PFS, and both configurations
are OK to use the suite name.

As for lifetimes, at least our implementation has a separate configuration for it.
Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually
specify it in the RFC.

But you are right. Especially since this is a followup to RFC 4869, they should have
included these parameters.
Email secured by Check Point

--=_alternative 00443631852575B6_=-- From denghui02@gmail.com Thu May 14 07:05: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 4B85228C113 for ; Thu, 14 May 2009 07:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 gU+gkI7PLCBr for ; Thu, 14 May 2009 07:05:31 -0700 (PDT) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by core3.amsl.com (Postfix) with ESMTP id 654AE28C105 for ; Thu, 14 May 2009 07:05:31 -0700 (PDT) Received: by pzk15 with SMTP id 15so576829pzk.29 for ; Thu, 14 May 2009 07:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8oM0KldmNs+tx47yL9vWsSnUfuaf7bIpP8ifVdj9zmY=; b=CEduxSamrPXPqnKuqX2+edGPbTbGcqLEwBrFlFnqw6Cg4QMI+lRlRjUWWwwFSCRJK4 eRCn1JUc4FtjxHuCr/BqZ+yn9iQIOqY/NAa2H9M90ttn+vOzr1YFpXSmbGZ4zOc4gjrb eWNckgNIuUnivRnQaLgMgaYRZPysRwzZX5gGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UE4VwUlpngvxoMSMfj+G1DSDjBUjFZfvQOjJn5Vm0LQHLB9gNQ7nV5ncMeiuwYzp7O tUQXAySyjJIvfIZA2r8d1f9OK+/vtYiRPkt0UCxa4BBVoUCFmLIQtEeqfeqheZ5hW7lU tMyG5N+GKcR2bqBjRTJtCKRIviTwdsJ7hz+p0= MIME-Version: 1.0 Received: by 10.142.44.11 with SMTP id r11mr738117wfr.240.1242310022055; Thu, 14 May 2009 07:07:02 -0700 (PDT) In-Reply-To: References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> Date: Thu, 14 May 2009 22:07:01 +0800 Message-ID: <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> From: Hui Deng To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] One question for IKE/IPsec 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, 14 May 2009 14:05:32 -0000 Thanks Paul and Yoav, excuse me for late reply. Tunnel waitting for traffic means that all traffic have to go through this tunnel anyhow. the scenario I described is that after IKE procedure, but all the traffic will not go through this Ipsec tunnle since they are point to point connection. Many thanks for your advice. -Hui 2009/5/14 Paul Hoffman : > At 6:53 PM +0300 5/13/09, Yoav Nir wrote: >>Paul Hoffman wrote: >>> >>> At 8:56 PM +0800 5/13/09, Hui Deng wrote: >>> >Dear IPsec forks, >>> > >>> >May I consult one question here: >>> > >>> >Whether we could still do IKEv2 negotiation >>> (Authenticaiton), but not >>> >use IPsec tunnel? >>> >>> You never need to use a tunnel, regardless of how it was >>> brought up. The tunnel can just sit there, feeling lonely and >>> abandoned, waiting for traffic. >> >>Yes, but you can't rely on the peer not having a policy that says "all tunnels that are idle for 30 seconds get deleted" > > Of course, but that's not what Hui asked. In his scenario, he should assume that the tunnel will get nuked by one side or the other either due to disuse or an active management choice. > > --Paul Hoffman, Director > --VPN Consortium > From paul.hoffman@vpnc.org Thu May 14 08:49: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 F08F528C2E1 for ; Thu, 14 May 2009 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 B-NYFrIzDkpd for ; Thu, 14 May 2009 08:49:58 -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 DCCD328C2E9 for ; Thu, 14 May 2009 08:49:57 -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 n4EFpIvK058724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 08:51:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> Date: Thu, 14 May 2009 08:51:17 -0700 To: Hui Deng From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] One question for IKE/IPsec 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, 14 May 2009 15:49:59 -0000 At 10:07 PM +0800 5/14/09, Hui Deng wrote: >Tunnel waitting for traffic means that all traffic have to go through >this tunnel anyhow. Correct. >the scenario I described is that after IKE procedure, but all the >traffic will not go through this Ipsec tunnle since they are point to >point connection. I am deeply confused. Why would point-to-point traffic not go through a tunnel that has the appropriate traffic selectors? Where else would the traffic go? --Paul Hoffman, Director --VPN Consortium From ken.grewal@intel.com Thu May 14 09:09:59 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 BE0B028B23E for ; Thu, 14 May 2009 09:09:59 -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 W3OgmhvkwiDQ for ; Thu, 14 May 2009 09:09:58 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id C853628C148 for ; Thu, 14 May 2009 09:09:58 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 14 May 2009 09:01:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,195,1241420400"; d="scan'208";a="515544820" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 14 May 2009 09:10:33 -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, 14 May 2009 10:10:56 -0600 From: "Grewal, Ken" To: Tero Kivinen , Yaron Sheffer Date: Thu, 14 May 2009 10:10:50 -0600 Thread-Topic: [IPsec] Next Header field in WESP header Thread-Index: AcnUgCtIQvXtoXf8SbmNaOs6tZFxKQALXKlw Message-ID: References: <18935.5198.554334.837387@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9ACEC58FB@il-ex01.ad.checkpoint.com> <4A00ABA9.4090201@sandelman.ca> <7C362EEF9C7896468B36C9B79200D83503604B5B50@INBANSXCHMBSA1.in.alcatel-luce nt.com> <714328.31562.qm@web82605.mail.mud.yahoo.com> <18953.15045.697978.618223@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D83503604B5E8C@INBANSXCHMBSA1.in.alcatel-luce nt.com> <223656.42022.qm@web82603.mail.mud.yahoo.com> <18955.56815.45070.926714@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583EAF@il-ex01.ad.checkpoint.com> <18955.62622.459433.274094@fireball.kivinen.iki.fi> In-Reply-To: <18955.62622.459433.274094@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: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , gabriel montenegro , Stephen Kent Subject: Re: [IPsec] Next Header field in WESP header 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, 14 May 2009 16:09:59 -0000 I agree in the most part. From other comments, it appears that the Next Hea= der is providing a useful function and if we are keeping it anyway, then th= e Next Header value of zero also provide a useful function (i.e. payload pr= otocol is opaque, hence data is encrypted).=20 I also agree that the text for packet handling by intermediate nodes and ul= timate recipients could be improved and we need explicit verbiage (with MUS= Ts) to describe the behavior.=20 Perhaps it would be useful to get an early next rev of the draft out with t= hese changes to ensure that we have the correct verbiage in place... I will send out a separate summary of where we are with the open ticket ite= ms.=20 >Yaron Sheffer writes: >> I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted >WESP. >> So yes, we use WESP for encrypted traffic to get: >> >> - Extensibility (with the 8-bit Flags field). > >This is future extensibility, which is needed only after we define >some future extensions using this. When we define those future >extensions we can also define that encrypted traffic can be used. > >I would rather keep this for future extension, i.e. only define the >use after we find out what we want to do, as all the end nodes needs >to be updated anyways before those new extensions can be used (and the >intermediate nodes too perhaps). > >The current document is not very clear what to do if reserved bits are >set. It says "On receiving a packet, these values must be checked to >ensure that they are as indicated above.". This does not specify >whether this is only for the final receiver (i.e. the node talking >IPsec), or also all intermediate nodes, or only those intermediate >nodes who actually look inside the WESP or what. It also does not >specify what needs to be done if those fields are not as specified. > >I.e. we need more text for that, i.e. specific processing rules for a) >intermediate nodes who parse WESP header, b) end IPsec entity. In some >cases the dropping / passbying the packet depends on the policy. On >the other hand if flags is set or version number does not match then >that usually means that the format of the WESP header might be >different thus it might be that intermediate nodes cannot parse header >any further. > >> - A single protocol that can do both cases. > >By wasting extra 4 bytes and using protocol which might not be >supported by other end. I think it is better to use plan normal ESP >for encrypted traffic, but I agree that we should probably define the >WESP header so that if Next Header in WESP header is 0 then contents >is encrypted, and intermediate nodes MUST NOT try to parse it. > >I would still recommend using normal ESP for encrypted traffic... >-- >kivinen@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From rsjenwar@gmail.com Thu May 14 21:41: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 C6C2D3A6358 for ; Thu, 14 May 2009 21:41:43 -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.038, 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 SRPnX9XLQ0OU for ; Thu, 14 May 2009 21:41:42 -0700 (PDT) Received: from mail-px0-f125.google.com (mail-px0-f125.google.com [209.85.216.125]) by core3.amsl.com (Postfix) with ESMTP id E83E03A6A25 for ; Thu, 14 May 2009 21:41:23 -0700 (PDT) Received: by pxi31 with SMTP id 31so836295pxi.29 for ; Thu, 14 May 2009 21:42:56 -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=AoYWNc/kID1B281TUZw4zMhljKm/Qy3uouxnxqBzmGs=; b=sMbAfGcGvJLXmq1uGTErN5ZCSyKjL+q1BtOm8QdX3P1AAh3WTaS6N2m5u2eCLS5s6v JeY9KQZh4986vPw2tX3IAuCZu9FTZC53u8Hs5o62qNeICiF2jOBp64L5YUmTiHRQj8zG UNvBLEdcHFea0ybxzIYFq3xkI7pPFCosd/zq4= 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=o0wjni6EYdWcv20biyMXYX3y8pDibloyH8aMF5XJ9h6zaeedGumiaCjE1ju1HUJ73U gh5maTvKBnuzNJrvLpqYAoOgonkOV2dcyNX4etSBIde3pK6HJ+aLriF5T9J8DuLbEzwB KFWq/vxrUVbWiY5Cx2wU4xYybIypnNaVhfZkw= MIME-Version: 1.0 Received: by 10.142.125.4 with SMTP id x4mr955153wfc.75.1242362575137; Thu, 14 May 2009 21:42:55 -0700 (PDT) In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@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> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> Date: Fri, 15 May 2009 10:12:55 +0530 Message-ID: <7ccecf670905142142n79733e87kc61c99ecc277bf96@mail.gmail.com> From: raj singh To: Yoav Nir Content-Type: multipart/alternative; boundary=000e0cd2287cf92dcb0469ec13b7 Cc: "ipsec@ietf.org" , Michael Richardson 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: Fri, 15 May 2009 04:41:43 -0000 --000e0cd2287cf92dcb0469ec13b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yoav, If check for mandatory payloads per exchange type is MUST, if it fails we MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft ? Putting it clearly in the draft make more sense and avoids many confusions. Thanks, Raj On Wed, May 6, 2009 at 7:24 PM, Yoav Nir wrote: > Hi Michael > > > Let me suggest a situation where perhaps I would like to > > bring up an IKE_SA and not a CHILD_SA: it might be for just > > sending initial contact, and perhaps even a DELETE. > > > > I sometimes move quickly from being "outside" my IPsec > > gateway/firewall (such as being on wireless), to being wired > > behind the gateway, where I do not need IPsec. The DPD > > doesn't kick off fast enough, and my traffic goes to where I > > am no longer. It would be nice to bring up the IKE_SA (or... > > haha, resume it), just so that I can send a delete and/or > > initial_contact. > > A far more common situation is when I'm "outside", not moving anywhere, and > I want to connect. I haven't even opened my mail client yet, or launched > the browser (because those thing hate it when the VPN client changes routing > to addresses they are trying to reach). > > The reason I want to connect before everything else, is that connecting > involves some effort (typing the PKCS#12 password, entering a username and > password, copying the OTP from the cellphone to the computer...). I want to > get this over with, but there's still no packet to derive selectors from. > > With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't > do Main Mode without attempting Quick Mode. > > > Seems like to do this, once needs to include a > > known-to-be-unacceptable CHILD_SA proposal. > > Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed > even if the piggy-backed CHILD_SA fails. > > Now I would never suggest that anyone use a traffic selectors type from the > private range (241-255) which is almost guaranteed to fail... > > Yoav > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000e0cd2287cf92dcb0469ec13b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

If check for mandatory payloads per exchange type is MUST, = if it fails we MUST return INVALID_SYNTAX, why we are not saying it explici= tly in the draft ? Putting it clearly in the draft make more sense and avoi= ds many confusions.

Thanks,
Raj


On Wed, May 6, 200= 9 at 7:24 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Michael

> Let me suggest a situation where perhaps I would like to
> bring up an IKE_SA and not a CHILD_SA: it might be for just
> sending initial contact, and perhaps even a DELETE.
>
> I sometimes move quickly from being "outside" my IPsec
> gateway/firewall (such as being on wireless), to being wired
> behind the gateway, where I do not need IPsec. =C2=A0The DPD
> doesn't kick off fast enough, and my traffic goes to where I
> am no longer. =C2=A0It would be nice to bring up the IKE_SA (or...
> haha, resume it), just so that I can send a delete and/or
> initial_contact.

A far more common situation is when I'm "outside", not = moving anywhere, and I want to connect. =C2=A0I haven't even opened my = mail client yet, or launched the browser (because those thing hate it when = the VPN client changes routing to addresses they are trying to reach).

The reason I want to connect before everything else, is that connecting inv= olves some effort (typing the PKCS#12 password, entering a username and pas= sword, copying the OTP from the cellphone to the computer...). I want to ge= t this over with, but there's still no packet to derive selectors from.=

With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can= 9;t do Main Mode without attempting Quick Mode.

> Seems like to do this, once needs to include a
> known-to-be-unacceptable CHILD_SA proposal.

Actually it doesn't have to be acceptable, as the IKE_AUTH will s= ucceed even if the piggy-backed CHILD_SA fails.

Now I would never suggest that anyone use a traffic selectors type from the= private range (241-255) which is almost guaranteed to fail...

Yoav
Email secured by Check Point
_______________________________________________

--000e0cd2287cf92dcb0469ec13b7-- From rsjenwar@gmail.com Fri May 15 02:32: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 67C753A6AF3 for ; Fri, 15 May 2009 02:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.028, 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 AJ09r7vnNRyO for ; Fri, 15 May 2009 02:32:50 -0700 (PDT) Received: from mail-pz0-f117.google.com (mail-pz0-f117.google.com [209.85.222.117]) by core3.amsl.com (Postfix) with ESMTP id 535963A63C9 for ; Fri, 15 May 2009 02:32:50 -0700 (PDT) Received: by pzk15 with SMTP id 15so940002pzk.29 for ; Fri, 15 May 2009 02:34: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=XL7p1ITTIrNyracKMb01QWyfryOmu48UHoZ8TccZiCY=; b=q9w8FoAIPLiod0KrMNrMwzau23JxmWc2kPjYvWt91VYEraDKWtEFVI1ms6dCfxkLvv WFUGdPcHqoodtRVukyJded1iT0jjBuiAQmx2VF9ffsyyOUjv14MNQLe0/agcdTf8WB0T VG0dKKwKN/G1dLEHup5J4LTvBiAmsIHx6grmw= 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=Uk6d8MbKc7LY77tWQeFxspKgB9rEBg+Lk8rh61HTnWNlxUWI3YYDwK5eLqTsMHdmoe es1BzVHuaGRM9oX8ZoXOT6Y240zHtwrz4Xab+Qz6LBPivlOU5qEgIT9lyVbFYKlJvnpW 7QOCA3AdURYdNunhWundqtoxDN45btaEbs798= MIME-Version: 1.0 Received: by 10.142.13.14 with SMTP id 14mr1014565wfm.108.1242380062162; Fri, 15 May 2009 02:34:22 -0700 (PDT) In-Reply-To: <7ccecf670905142142n79733e87kc61c99ecc277bf96@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <7ccecf670905142142n79733e87kc61c99ecc277bf96@mail.gmail.com> Date: Fri, 15 May 2009 15:04:22 +0530 Message-ID: <7ccecf670905150234m7acc9db8i1290062949d2bd50@mail.gmail.com> From: raj singh To: Yoav Nir Content-Type: multipart/alternative; boundary=000e0cd174884802080469f026fe Cc: "ipsec@ietf.org" , Michael Richardson 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: Fri, 15 May 2009 09:32:51 -0000 --000e0cd174884802080469f026fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Team, One more question. The INVALID_SYNTAX notify in response to missing payload in IKE_AUTH should be send encrypted using DH keys or unencrypted ? Thanks, raj On Fri, May 15, 2009 at 10:12 AM, raj singh wrote: > Hi Yoav, > > If check for mandatory payloads per exchange type is MUST, if it fails we > MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft > ? Putting it clearly in the draft make more sense and avoids many > confusions. > > Thanks, > Raj > > > > On Wed, May 6, 2009 at 7:24 PM, Yoav Nir wrote: > >> Hi Michael >> >> > Let me suggest a situation where perhaps I would like to >> > bring up an IKE_SA and not a CHILD_SA: it might be for just >> > sending initial contact, and perhaps even a DELETE. >> > >> > I sometimes move quickly from being "outside" my IPsec >> > gateway/firewall (such as being on wireless), to being wired >> > behind the gateway, where I do not need IPsec. The DPD >> > doesn't kick off fast enough, and my traffic goes to where I >> > am no longer. It would be nice to bring up the IKE_SA (or... >> > haha, resume it), just so that I can send a delete and/or >> > initial_contact. >> >> A far more common situation is when I'm "outside", not moving anywhere, >> and I want to connect. I haven't even opened my mail client yet, or >> launched the browser (because those thing hate it when the VPN client >> changes routing to addresses they are trying to reach). >> >> The reason I want to connect before everything else, is that connecting >> involves some effort (typing the PKCS#12 password, entering a username and >> password, copying the OTP from the cellphone to the computer...). I want to >> get this over with, but there's still no packet to derive selectors from. >> >> With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't >> do Main Mode without attempting Quick Mode. >> >> > Seems like to do this, once needs to include a >> > known-to-be-unacceptable CHILD_SA proposal. >> >> Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed >> even if the piggy-backed CHILD_SA fails. >> >> Now I would never suggest that anyone use a traffic selectors type from >> the private range (241-255) which is almost guaranteed to fail... >> >> Yoav >> Email secured by Check Point >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --000e0cd174884802080469f026fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team,

One more question.
The INVALID_SYNTAX notify in response= to missing payload in IKE_AUTH should be send encrypted using DH keys or u= nencrypted ?

Thanks,
raj

On Fri= , May 15, 2009 at 10:12 AM, raj singh <rsjenwar@gmail.com> wrote:
Hi Yoav,

I= f check for mandatory payloads per exchange type is MUST, if it fails we MU= ST return INVALID_SYNTAX, why we are not saying it explicitly in the draft = ? Putting it clearly in the draft make more sense and avoids many confusion= s.

Thanks,
Raj



On Wed, May 6, 2009 at 7:24 = PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Michael

> Let me suggest a situation where perhaps I would like to
> bring up an IKE_SA and not a CHILD_SA: it might be for just
> sending initial contact, and perhaps even a DELETE.
>
> I sometimes move quickly from being "outside" my IPsec
> gateway/firewall (such as being on wireless), to being wired
> behind the gateway, where I do not need IPsec. =C2=A0The DPD
> doesn't kick off fast enough, and my traffic goes to where I
> am no longer. =C2=A0It would be nice to bring up the IKE_SA (or...
> haha, resume it), just so that I can send a delete and/or
> initial_contact.

A far more common situation is when I'm "outside", not = moving anywhere, and I want to connect. =C2=A0I haven't even opened my = mail client yet, or launched the browser (because those thing hate it when = the VPN client changes routing to addresses they are trying to reach).

The reason I want to connect before everything else, is that connecting inv= olves some effort (typing the PKCS#12 password, entering a username and pas= sword, copying the OTP from the cellphone to the computer...). I want to ge= t this over with, but there's still no packet to derive selectors from.=

With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can= 9;t do Main Mode without attempting Quick Mode.

> Seems like to do this, once needs to include a
> known-to-be-unacceptable CHILD_SA proposal.

Actually it doesn't have to be acceptable, as the IKE_AUTH will s= ucceed even if the piggy-backed CHILD_SA fails.

Now I would never suggest that anyone use a traffic selectors type from the= private range (241-255) which is almost guaranteed to fail...

Yoav
Email secured by Check Point
_______________________________________________


--000e0cd174884802080469f026fe-- From kivinen@iki.fi Fri May 15 05:04: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 CBC073A6C95 for ; Fri, 15 May 2009 05:04:34 -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 PaLL6kRNLgtS for ; Fri, 15 May 2009 05:04:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AF7A93A6A5D for ; Fri, 15 May 2009 05:04: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 n4FC5u6q008298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 15:05:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4FC5tr6003887; Fri, 15 May 2009 15:05:55 +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: <18957.23203.511228.330249@fireball.kivinen.iki.fi> Date: Fri, 15 May 2009 15:05:55 +0300 From: Tero Kivinen To: raj singh In-Reply-To: <7ccecf670905150234m7acc9db8i1290062949d2bd50@mail.gmail.com> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <7ccecf670905142142n79733e87kc61c99ecc277bf96@mail.gmail.com> <7ccecf670905150234m7acc9db8i1290062949d2bd50@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Michael Richardson , 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: Fri, 15 May 2009 12:04:34 -0000 raj singh writes: > The INVALID_SYNTAX notify in response to missing payload in IKE_AUTH should > be send encrypted using DH keys or unencrypted ? As it is clear that other end is not following the specification, i.e. there is bug on the other end, there is no need to think that much what you should do in that case. That situation never happens in normal case, so use the easiest way out. For me that is silently destroy the IKE SA without sending any error codes back. There is debug prints indicating the problem (but nothing for release build). There is no point of thinking what to do in situations that only happens during interop testing events when testing against broken implementations... Just make sure your implementation cleanly clears the situation (i.e. does not crash, or read uninitialized buffers etc) and thats it. -- kivinen@iki.fi From denghui02@gmail.com Fri May 15 05:08:28 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 ADC693A68FA for ; Fri, 15 May 2009 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 UaHSjV85ocRs for ; Fri, 15 May 2009 05:08:28 -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 EBCC53A6768 for ; Fri, 15 May 2009 05:08:27 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1145086wff.31 for ; Fri, 15 May 2009 05:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YBhJtFu9rtc8ZZ7CaeqvYEXWNpju0wVQuDLcgW/4zSY=; b=SGi/aMalvB1O1usQNs9a2gBW8Ecq7VvRqJxBHVBZ7fcm3zYL3GXqh1zMNE4K1A1YIy kWFXhHp6ba8Q4CvtZ5oZGo4hUgT4kiZvnm/VNyu/Ijjdk2RrCJi0Wc54mVEYBXDpQBiP PZmhhk072nUfjc14/fJ7+Rtsa2p7cxhj9IvOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GxMzR+1xUs2jhXRewIV/wfiK1fPc4/X7HneCxLtmSzdbn1cLzvyrv2uBbkGNeDS5Zx qTf+D4pzYwRQi+t8kzme/zu4kaHD5EhSxOkMEPueW9yAz4/FtucCTTGnHrC8YTRxcdT9 rAbS/DwepLcgTPjIYeCfC5Pd0bSoZ8dct4avE= MIME-Version: 1.0 Received: by 10.142.254.2 with SMTP id b2mr1064311wfi.323.1242389400144; Fri, 15 May 2009 05:10:00 -0700 (PDT) In-Reply-To: References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> Date: Fri, 15 May 2009 20:10:00 +0800 Message-ID: <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.com> From: Hui Deng To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] One question for IKE/IPsec 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, 15 May 2009 12:08:28 -0000 You are right, after IKE phase 1, IPsec SA will be setup, traffic selector will be used Here our requirement is, we still create the IKE SA, but not create IPsec SA. the reason for such kind of strange usage is that IKE is already mandated there. the left is whether it is necessary to use IPsec since the connections are already physically secured. Excuse for such strange scenario. -Hui 2009/5/14 Paul Hoffman : > At 10:07 PM +0800 5/14/09, Hui Deng wrote: >>Tunnel waitting for traffic means that all traffic have to go through >>this tunnel anyhow. > > Correct. > >>the scenario I described is that after IKE procedure, but all the >>traffic will not go through this Ipsec tunnle since they are point to >>point connection. > > I am deeply confused. Why would point-to-point traffic not go through a tunnel that has the appropriate traffic selectors? Where else would the traffic go? > > --Paul Hoffman, Director > --VPN Consortium > From ken.grewal@intel.com Fri May 15 07:17: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 ED3B23A6DB1 for ; Fri, 15 May 2009 07:17:06 -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 2b96FUJJvZJb for ; Fri, 15 May 2009 07:17:06 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 286933A68FA for ; Fri, 15 May 2009 07:17:06 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 15 May 2009 07:12:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,199,1241420400"; d="scan'208";a="457544527" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga002.fm.intel.com with ESMTP; 15 May 2009 07:13:05 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 15 May 2009 08:18:38 -0600 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 15 May 2009 08:18:37 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Fri, 15 May 2009 08:18:34 -0600 Thread-Topic: IPsecME traffic visibility open item summary Thread-Index: AcnVVhUrSaQuAtqPQpCQtNjiQJg5JwAEM9GA Message-ID: References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.com> In-Reply-To: <1d38a3350905150510m3e2402fblfd13be56c6ca3894@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: [IPsec] IPsecME traffic visibility open item summary 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, 15 May 2009 14:17:07 -0000 All,=20 In an attempt to get consensus and closure on some of the open tickets for = traffic visibility, I am providing the following summary. I look forward to= your feedback... #84: Wesp scope and applicability to encrypted data. Agreed that we will us= e Next Header value of zero to denote packet payload is encrypted. Should b= e closed? #85: units for header / trailer len. Updated in rev 02 - Gabriel is owner a= nd needs to update / close ticket. #88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's co= mment on updating reference to 4306 from 3947 - will address in next rev. #89: Version handling - added some text, but need to add additional text o= n how this is treated by intermediate devices, as well as recipients - see = discussion on ML. #90: Shorter WESP negotiation using notifications - added this to rev02 - a= ll agree that this is the right approach? #91: Next Header field should not be optional for ESP-NULL. Added text to r= ev 02. #92: Clarify how to treat the flags. This is similar to #89 and will clarif= y further in next rev.=20 #93: Next header to provide value of tunneled packet. Some comments on ML i= ndicate that Next Header value in WESP should be same as Next Header value = in ESP trailer. This provides consistency and aids easy validation by recip= ient - need to add text to indicate consistency between tunnel / transport = mode. #104: Handling malformed fields in WESP header. This is similar to Next hea= der corruption and will add text to ensure recipient validates these as per= suggestions on ML. Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of WES= P header. Rationale was to place flags first, so any packet format changes = in the future can be accommodated by checking the flags and then inferring = the subsequent formatting. Offline comment prefers the flags to be at end o= f WESP header, as per rev-01 of draft. Any preference from others? Raise a = separate ticket for this? Thanks, Ken From mcr@marajade.sandelman.ca Fri May 15 07:34: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 A5C5C28C40B for ; Fri, 15 May 2009 07:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 m1EC32b0nrPq for ; Fri, 15 May 2009 07:34:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B449D28C431 for ; Fri, 15 May 2009 07:33:25 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id E293C341FB; Fri, 15 May 2009 14:34:58 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id F29974E811; Fri, 15 May 2009 10:34:57 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <18957.23203.511228.330249@fireball.kivinen.iki.fi> References: <7ccecf670904212100o5ee2fe2dydb4bfdba2f414b4b@mail.gmail.com> <99043b4a0904212337w11be053cg480f80592a6c513e@mail.gmail.com> <99043b4a0904212338l74e47c3ftae1b7a14aa8db5b6@mail.gmail.com> <7ccecf670904212351n6494a683x87384b409d14d9c2@mail.gmail.com> <9FB7C7CE79B84449B52622B506C780361338597890@il-ex01.ad.checkpoint.com> <4A009310.2020904@sandelman.ca> <9FB7C7CE79B84449B52622B506C780361338598109@il-ex01.ad.checkpoint.com> <7600.1241614739@marajade.sandelman.ca> <9FB7C7CE79B84449B52622B506C7803613385981A8@il-ex01.ad.checkpoint.com> <7ccecf670905142142n79733e87kc61c99ecc277bf96@mail.gmail.com> <7ccecf670905150234m7acc9db8i1290062949d2bd50@mail.gmail.com> <18957.23203.511228.330249@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 10:34:57 -0400 Message-ID: <7281.1242398097@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca 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: Fri, 15 May 2009 14:34:42 -0000 >>>>> "Tero" =3D=3D Tero Kivinen writes: >> The INVALID_SYNTAX notify in response to missing payload in >> IKE_AUTH should be send encrypted using DH keys or unencrypted ? Tero> As it is clear that other end is not following the Tero> specification, i.e. there is bug on the other end, there is Tero> no need to think that much what you should do in that Tero> case. That situation never happens in normal case, so use the Tero> easiest way out. I agree with the general principle. However, a log entry would be good, as there will be people with broken implementations (i.e. "bugs") out there trying to determine what is going on, and they won't always be sitting at a table next to you. --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ From paul.hoffman@vpnc.org Fri May 15 08:24: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 AE7D43A68F9 for ; Fri, 15 May 2009 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 SOqf+2PY2FuN for ; Fri, 15 May 2009 08:24:36 -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 5241E3A6889 for ; Fri, 15 May 2009 08:24:35 -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 n4FF9OIX057334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 08:09:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.com> Date: Fri, 15 May 2009 08:09:23 -0700 To: Hui Deng From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] One question for IKE/IPsec 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, 15 May 2009 15:24:36 -0000 At 8:10 PM +0800 5/15/09, Hui Deng wrote: >You are right, after IKE phase 1, IPsec SA will be setup, >traffic selector will be used > >Here our requirement is, we still create the IKE SA, but not create IPsec SA. >the reason for such kind of strange usage is that IKE is already mandated there. >the left is whether it is necessary to use IPsec since the connections >are already physically secured. You can run IKE and then immediately delete the IPsec / Child SA but leave the IKE SA up. This should probably pass your odd requirements. >Excuse for such strange scenario. Many of us have seen worse... --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Fri May 15 08:39: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 542EA3A6B71 for ; Fri, 15 May 2009 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 FphM5dx0lEEn for ; Fri, 15 May 2009 08:39:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B5BF43A6D3B for ; Fri, 15 May 2009 08:39:53 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A8C7829C001; Fri, 15 May 2009 18:41:26 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4EA66200E00; Fri, 15 May 2009 18:41:26 +0300 (IDT) X-CheckPoint: {4A0D8C6D-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 n4FFfOqO023825; Fri, 15 May 2009 18:41:25 +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, 15 May 2009 18:41:24 +0300 From: Yaron Sheffer To: "Grewal, Ken" , "ipsec@ietf.org" Date: Fri, 15 May 2009 18:41:21 +0300 Thread-Topic: IPsecME traffic visibility open item summary Thread-Index: AcnVVhUrSaQuAtqPQpCQtNjiQJg5JwAEM9GAAAMk1lA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584004@il-ex01.ad.checkpoint.com> References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.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; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000A_01C9D58C.BDC630F0" MIME-Version: 1.0 Subject: Re: [IPsec] IPsecME traffic visibility open item summary 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, 15 May 2009 15:39:55 -0000 ------=_NextPart_000_000A_01C9D58C.BDC630F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Ken, Tero mentioned that two more fields must be zero when the payload is encrypted. Is this covered by any of the open issues? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Grewal, Ken > Sent: Friday, May 15, 2009 17:19 > To: ipsec@ietf.org > Subject: [IPsec] IPsecME traffic visibility open item summary > > All, > In an attempt to get consensus and closure on some of the open tickets for > traffic visibility, I am providing the following summary. I look forward > to your feedback... > > #84: Wesp scope and applicability to encrypted data. Agreed that we will > use Next Header value of zero to denote packet payload is encrypted. > Should be closed? > > #85: units for header / trailer len. Updated in rev 02 - Gabriel is owner > and needs to update / close ticket. > > #88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's > comment on updating reference to 4306 from 3947 - will address in next > rev. > > #89: Version handling - added some text, but need to add additional text > on how this is treated by intermediate devices, as well as recipients - > see discussion on ML. > > #90: Shorter WESP negotiation using notifications - added this to rev02 - > all agree that this is the right approach? > > #91: Next Header field should not be optional for ESP-NULL. Added text to > rev 02. > > #92: Clarify how to treat the flags. This is similar to #89 and will > clarify further in next rev. > > #93: Next header to provide value of tunneled packet. Some comments on ML > indicate that Next Header value in WESP should be same as Next Header > value in ESP trailer. This provides consistency and aids easy validation > by recipient - need to add text to indicate consistency between tunnel / > transport mode. > > #104: Handling malformed fields in WESP header. This is similar to Next > header corruption and will add text to ensure recipient validates these as > per suggestions on ML. > > Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of > WESP header. Rationale was to place flags first, so any packet format > changes in the future can be accommodated by checking the flags and then > inferring the subsequent formatting. Offline comment prefers the flags to > be at end of WESP header, as per rev-01 of draft. Any preference from > others? Raise a separate ticket for this? > > > Thanks, > Ken > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_000A_01C9D58C.BDC630F0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNTE1NDEyMVowIwYJKoZIhvcNAQkEMRYEFIGO6inmLNzg uvgdjIZXNUuXkLfDMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ToyfBvXbvZxnQo1ubnt+0K+f71MBs+gFDZL7T3uf8IZBzsrPuzKXF5QOMLmiHIr8+06nxkcFXUQ9 g7WCOXMMK1UefZe0hRKMJgU8kqFIScrRDn0POK9rZYfvaA22SPiY7Wjru/QEI/eVemjp8/PZx/JF 194ugaZjKWaSkZB5nLPJMvrilABQ85t9tcCSstKCHHBORnnnCFkdO0WE5+ZIWr1caN59+OpOwcS+ 01rnniL3TQyw25OWb9ySiPfx7JKa2T3hAqs09hMW9O+50M61Lg4+N/5T76L8sEaJyOrrBFIrqyV0 e5o9FBjwcQnvpQF8sxwhE0P9XO5sFiZrnttPmAAAAAAAAA== ------=_NextPart_000_000A_01C9D58C.BDC630F0-- From root@core3.amsl.com Fri May 15 09: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 6D4AB28C106; Fri, 15 May 2009 09: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: <20090515163001.6D4AB28C106@core3.amsl.com> Date: Fri, 15 May 2009 09:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-04.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, 15 May 2009 16: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 : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-ietf-ipsecme-ikev2-resumption-04.txt Pages : 27 Date : 2009-05-15 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. 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. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach requires passing opaque data from the IKEv2 responder to the IKEv2 initiator, which is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but recommendations are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-04.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-resumption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-15092449.I-D@ietf.org> --NextPart-- From ken.grewal@intel.com Fri May 15 10:22: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 273063A70E3 for ; Fri, 15 May 2009 10:22: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 XJwa3LCL0kQn for ; Fri, 15 May 2009 10:22:29 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 1D2A23A6D35 for ; Fri, 15 May 2009 10:22:29 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 15 May 2009 10:13:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,200,1241420400"; d="p7s'?scan'208";a="412792338" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 15 May 2009 10:31:42 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Fri, 15 May 2009 11:23:59 -0600 From: "Grewal, Ken" To: Yaron Sheffer , "ipsec@ietf.org" Date: Fri, 15 May 2009 11:23:57 -0600 Thread-Topic: IPsecME traffic visibility open item summary Thread-Index: AcnVVhUrSaQuAtqPQpCQtNjiQJg5JwAEM9GAAAMk1lAAA5RxUA== Message-ID: References: <1d38a3350905130556i2f454fd4nc779eb660dce02e7@mail.gmail.com> <9FB7C7CE79B84449B52622B506C7803613410ED7E8@il-ex01.ad.checkpoint.com> <1d38a3350905140707t46fdea05r6ef1b1cbf53d6c9@mail.gmail.com> <1d38a3350905150510m3e2402fblfd13be56c6ca3894@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584004@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584004@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_0129_01C9D547.412B7090" MIME-Version: 1.0 Subject: Re: [IPsec] IPsecME traffic visibility open item summary 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, 15 May 2009 17:22:30 -0000 ------=_NextPart_000_0129_01C9D547.412B7090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Yaron - I will capture this as part of the text on packet handling and field validation. Thanks, - Ken >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf@checkpoint.com] >Sent: Friday, May 15, 2009 8:41 AM >To: Grewal, Ken; ipsec@ietf.org >Subject: RE: IPsecME traffic visibility open item summary > >Hi Ken, > >Tero mentioned that two more fields must be zero when the payload is >encrypted. Is this covered by any of the open issues? > >Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Grewal, Ken >> Sent: Friday, May 15, 2009 17:19 >> To: ipsec@ietf.org >> Subject: [IPsec] IPsecME traffic visibility open item summary >> >> All, >> In an attempt to get consensus and closure on some of the open tickets >for >> traffic visibility, I am providing the following summary. I look forward >> to your feedback... >> >> #84: Wesp scope and applicability to encrypted data. Agreed that we will >> use Next Header value of zero to denote packet payload is encrypted. >> Should be closed? >> >> #85: units for header / trailer len. Updated in rev 02 - Gabriel is owner >> and needs to update / close ticket. >> >> #88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's >> comment on updating reference to 4306 from 3947 - will address in next >> rev. >> >> #89: Version handling - added some text, but need to add additional text >> on how this is treated by intermediate devices, as well as recipients - >> see discussion on ML. >> >> #90: Shorter WESP negotiation using notifications - added this to rev02 - >> all agree that this is the right approach? >> >> #91: Next Header field should not be optional for ESP-NULL. Added text to >> rev 02. >> >> #92: Clarify how to treat the flags. This is similar to #89 and will >> clarify further in next rev. >> >> #93: Next header to provide value of tunneled packet. Some comments on ML >> indicate that Next Header value in WESP should be same as Next Header >> value in ESP trailer. This provides consistency and aids easy validation >> by recipient - need to add text to indicate consistency between tunnel / >> transport mode. >> >> #104: Handling malformed fields in WESP header. This is similar to Next >> header corruption and will add text to ensure recipient validates these >as >> per suggestions on ML. >> >> Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of >> WESP header. Rationale was to place flags first, so any packet format >> changes in the future can be accommodated by checking the flags and then >> inferring the subsequent formatting. Offline comment prefers the flags to >> be at end of WESP header, as per rev-01 of draft. Any preference from >> others? Raise a separate ticket for this? >> >> >> Thanks, >> Ken >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0129_01C9D547.412B7090 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCTCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAA AAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIy MjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9 x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJ wyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtf p8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP 2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gEC AwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoER ghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGs oIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFs JTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy bDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUy MENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7soc oJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1 kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOS IF2VUmueAmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98k k3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIF9zCC BN+gAwIBAgIKG5+jTgAAAAAg/jANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgM0EwHhcNMDgwNjAyMTU1MzQxWhcNMTEwNjAyMTU1MzQxWjA7MRQwEgYDVQQDEwtHcmV3 YWwsIEtlbjEjMCEGCSqGSIb3DQEJARYUa2VuLmdyZXdhbEBpbnRlbC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC4FCPKjpfz6Mt/j1HuGDmHHXcamuS7gQlfSOQy+phBM4G2Jqw+ oYdOmEj3FadVI6osyhOShSj7mvFE+2UkDyEeIAD1LJrjJHC03jkl5Ll1YrxeNpYN/EMlSCtZZ2iW hd6M0uk+e408Zx2lD06ju+EJ2uNZ4Hux6COGT0cnm8oeL2Lr0eRUM/SdqOGw/LM3btEg6WUfN2MJ 3NeE7TvPifTPSQMMAh7mBzW2YUNem4Cj4uq+vacrn0zEijuh3/wCsn8M7GF1uDBjv7WM9jB/P+lD yCA9hOPxsD+4++AtAkDYm/DAUvarOa3jSAOXPv1PBLexJru6J3a30h1ZbHT1AX9bAgMBAAGjggLg MIIC3DALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFDjNfXcVsj96VG4IIV5BNTJmL9nAMDwGCSsGAQQB gjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4HevTmV8EMCAWQCAQYwHwYD VR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCBtYZUaHR0 cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2lj JTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9y ZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAz QS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwu Y29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDApBgkr BgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAkBgorBgEE AYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAorkt9OOF3L7PME5cQ/2ZXtVbS07RUTBsu+nuHQygUbgYt0sUsnL0G+CA +fu+2R8RrLKvFSsCdkw8FHi+DSaIuYXxQkof+B8GN/9AJ+Xt2zf1Y36ILLoBdwKAwG2GmVEngUoc 0FQQZ9n3GB7DSIK0wKXNwWILJSlnHW0nq5j1k3zP/pmpWe/xv10UGL/otML5weJl0BUDkSoxMES9 Zzi0/Ph4/vENFnZwvbzrLbxi5/wZLsD3KK9PofcAEqXi4z33QIW4Thd8IQzc+UzvRDXS1On+DZyH RbGt9/7GAwfVoFlswIb+/yGds/LuBTxUsVe1d1MRrmeTBniv4UL9Dt2jRjCCBj4wggUmoAMCAQIC Chue2YYAAAAAIP0wDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVs IENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNB MB4XDTA4MDYwMjE1NTI0M1oXDTExMDYwMjE1NTI0M1owOzEUMBIGA1UEAxMLR3Jld2FsLCBLZW4x IzAhBgkqhkiG9w0BCQEWFGtlbi5ncmV3YWxAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA9OP+3itCo/qwJlycjkVscHNGVD6syIQkohfFYGbEwgXDmZ11Mjnfly9kIKmb qJi4AmQLbzxiCNLhze/iWE9oS9q7oTron00id0Jq8RFugV0exfAeZxpsZORofjcq5gpUUAGcMONT 0e8CS9JcQ+X9imcanwXgIpmWs6w5L0j49Lnx3Q5chY3RNp3TZJZlQ5XNVw68ZTj5KBzLRsJGdym9 vMKKvzgkyQVDswbFvnl/AdM2A9X0SLzdmmCOuIxXMLxClqEQfjWq7oVq0U4j7eGk+RkP0Phj02xP qP+VOmXCU8AEAVIO/809uKvPjK8rSEEIybKEb+s/8jWtlw1bH3FyTQIDAQABo4IDJzCCAyMwCwYD VR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIA gDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUznBDWAHsnnyH0lGMsHGgDuEq7HYwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlnhLnZQYeE/04CAWQC AQkwHwYDVR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCB tYZUaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVs LmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjAzQS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMu aW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNp YyUyMElzc3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD BDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEALND1Kg3D0peyUCD/XDB7cpsOWB8zf6omdTwotvEUWZo+KTxB xP5jW3wg++RRfjm5/NoSxJDzEYUTIByV8wI/qlGPPMnFu8MePB3YazYj5UPmgAQzgNTZfKj4UNgG R80voebkkzRBiFsa3j/dd6XHdAf7B+Rsl4ryUzSb87CkAdJVsEadHgjDM+Ft56oumvWzl+v7JWCk BmGPAlUnJGbpREoqWvesP5nGChYh77GYvHDRrSMgpFJ/x30V91BHwEQgSOPPccvf6OZqUJuSc7zT ElztMjoPIL9hjxNsz45KlkEk28siciKUwq2Jx0lnWJiVSL1svhV2DlXSUvn2a4VGWTGCA0EwggM9 AgEBMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQD EyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobn6NOAAAAACD+MAkGBSsOAwIa BQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNTE3 MjM1NlowIwYJKoZIhvcNAQkEMRYEFL0ffllVJRq9bhAWH07Y/et1gM7zMGcGCSqGSIb3DQEJDzFa MFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkG A1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRl cm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobntmGAAAAACD9MHUGCyqGSIb3DQEJEAILMWagZDBW MQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVs IEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ECChue2YYAAAAAIP0wDQYJKoZIhvcNAQEBBQAE ggEAKD5LagsqfvvmXwmVDfiJAd5XZTj+V+rjUmzrLQ6TqpZ4abfNiROi6B1mprXnsZrNA9jgFXT7 VniVsuQ3QH4oMkdbtXfenD0ocAKb8OHDPVJaUQKkIFoWIdIBGtY1Bi5BLM9n4tj8ErphAKwLKXtR H4omiWia+DIAPfD+mZ0tO+4xkpovgwHrOr2m53iXIWPQHDW1uwW+djQxQ6qpiI0f+wbWshCw3lIx fHxEO+dleTGH7jUWZ/WuAx5StdTtWKTqrPnUYFi/OZAdXG+sWvVqaERpFYnzebm3dCIOMW8F+QB7 KPjQyz4FFoJ+caFYi+OuVLYZx/+n9rlImGwzsoXxygAAAAAAAA== ------=_NextPart_000_0129_01C9D547.412B7090-- From paul.hoffman@vpnc.org Fri May 15 13:05: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 51F923A6D3F for ; Fri, 15 May 2009 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDfabEHpYAaS for ; Fri, 15 May 2009 13:05:21 -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 211C128C160 for ; Fri, 15 May 2009 13:05:20 -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 n4FK6plZ080348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 May 2009 13:06:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090515163001.6D4AB28C106@core3.amsl.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> Date: Fri, 15 May 2009 13:06:27 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.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, 15 May 2009 20:05:22 -0000 Greetings again. There has been almost no discussion on the -03 draft, and Yaron has made some small changes in the -04. As we discussed at the interim WG meeting, we would like to advance this before Stockholm. Therefore, this is the beginning of the two-week WG Last Call, which will end May 29. The current document is at . Even if you have not read the document before now, please do so. Having fresh eyes on the document often brings up important issues. Send any comments to the list, even if they are as simple as "I read it and it seems fine". We would like to gauge how much support there is or isn't for this protocol. --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Fri May 15 14:24: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 04F143A6924 for ; Fri, 15 May 2009 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.043, 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 j6jJXnVSuhjr for ; Fri, 15 May 2009 14:24:12 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id AFF423A680A for ; Fri, 15 May 2009 14:24:12 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4FLPkf3006828 for ; Fri, 15 May 2009 21:25:46 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n4FLPjna023740 for ; Fri, 15 May 2009 17:25:45 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4FLIFga006295 for ; Fri, 15 May 2009 17:18:15 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4FLIEsm006293 for ipsec@ietf.org; Fri, 15 May 2009 17:18:14 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Fri, 15 May 2009 17:18:14 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090515211814.GG1292@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [IPsec] Anyone have a 4868-compilant HMAC-SHA-{384, 512} for AH/ESP to test? 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, 15 May 2009 21:24:15 -0000 I'm discovering interoperability bugs between OpenSolaris and other platforms in the SHA-2 space, mostly around SHA-384 and SHA-512. Does anyone have an implementation that we can run some quick manually-keyed tests against? Thanks, Dan From vijay@wichorus.com Fri May 15 14:29: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 577E63A6D29 for ; Fri, 15 May 2009 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.137, 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 OXrKjCPrwyGH for ; Fri, 15 May 2009 14:29:07 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 6BA813A6C4F for ; Fri, 15 May 2009 14:29:07 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) 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 ; Fri, 15 May 2009 21:30:40 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 15 May 2009 14:30:39 -0700 From: Vijay Devarapalli To: Yaron Sheffer , "ipsec@ietf.org" Message-ID: Thread-Topic: [IPsec] Redirect -09 comments Thread-Index: AcnUUQKW97cHVLC9RD6K6Gnsr2QH0ABU2Gpr In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Redirect -09 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: Fri, 15 May 2009 21:29:08 -0000 Hi Yaron, On 5/13/09 10:01 PM, "Yaron Sheffer" wrote: > Hi, > > While preparing to progress the draft to AD review, I reread it once again. > Here are a few comments. Although not all are nits, none of them should block > the document now. > > Thanks, > Yaron > > Not-quite-nits: > > General: a long way back we discussed loop avoidance, but this never made its > way into the draft. The document implicitly allows multiple redirections in > sequence. We should specify somewhere that the client MUST have a threshold > value X (possibly 1), where it is willing to redirect at most X times in > sequence. This is meant to deal with faulty configuration, not with active > attacks. I added the following text to the Security Considerations section. The client could end up getting redirected multiple times in a sequence, either because of wrong configuration or a DoS attack. The client could even end up in a loop with two or more gateways redirecting the client to each other. This could deny service to the client. To prevent this, the client should be configured not to accept more a certain number of redirects within a short time period. This should be configurable on the client. Freel free to modify the text. > 9. I believe the last sentence "To protect against this kind of attack the > redirection based on the ID should happen only after client has also > authenticated himself." should read "after the *gateway* has also > authenticated itself". Hmm.. This is about revealing information about the user. So I don't see how this can be avoided if the gateway is authenticating itself. > 10. Please add at the end of the section: A specification that extends this > registry MUST also define in which notification(s) the new values are allowed. > > Nits: > > 1. "connect to the IP address of the VPN gateways", change "gateways" to > "gateway". > > 3. "In practice, this means the new gateway either", remove one "either". > > 6. mesage -> message > > 6. "presented by the client in the first IKE_AUTH exchange itself." - this > text is duplicated. Fixed all of the above. Thanks. Vijay From paulmoore100@hotmail.com Fri May 15 15:31: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 2BA8728C18F for ; Fri, 15 May 2009 15:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 nOnMzXmuOkvk for ; Fri, 15 May 2009 15:31:51 -0700 (PDT) Received: from bay0-omc1-s34.bay0.hotmail.com (bay0-omc1-s34.bay0.hotmail.com [65.54.246.106]) by core3.amsl.com (Postfix) with ESMTP id 65E123A6B6F for ; Fri, 15 May 2009 15:31:51 -0700 (PDT) Received: from BAY106-DS4 ([65.54.161.93]) by bay0-omc1-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 15:33:25 -0700 X-Originating-IP: [65.55.161.23] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable From: "Paul Moore " To: "Paul Hoffman " , "denghui02@gmail.com " Date: Fri, 15 May 2009 22:33:25 +0000 X-OriginalArrivalTime: 15 May 2009 22:33:25.0444 (UTC) FILETIME=[29392840:01C9D5AD] Cc: "ipsec@ietf.org " , "ynir@checkpoint.com " Subject: Re: [IPsec] One question for IKE/IPsec 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, 15 May 2009 22:31:52 -0000 With racoon you can use racoonctll to launch a phase1 without a phase2 ------Original Message------ From: Paul Hoffman To: denghui02@gmail.com Cc: ipsec@ietf.org Cc: ynir@checkpoint.com Sent: May 15, 2009 8:09 AM Subject: Re: [IPsec] One question for IKE/IPsec At 8:10 PM +0800 5/15/09, Hui Deng wrote: >You are right, after IKE phase 1, IPsec SA will be setup, >traffic selector will be used > >Here our requirement is, we still create the IKE SA, but not create IPsec= SA. >the reason for such kind of strange usage is that IKE is already mandated= there. >the left is whether it is necessary to use IPsec since the connections >are already physically secured. =20 You can run IKE and then immediately delete the IPsec / Child SA but leave= the IKE SA up. This should probably pass your odd requirements. =20 >Excuse for such strange scenario. =20 Many of us have seen worse... =20 --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 Sent via BlackBerry by AT&T From yaronf@checkpoint.com Sat May 16 14:35: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 9D0D33A6835 for ; Sat, 16 May 2009 14:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 PKKnJGTZpppl for ; Sat, 16 May 2009 14:35:38 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 362693A6C85 for ; Sat, 16 May 2009 14:35:33 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6DB1630C002; Sun, 17 May 2009 00:37:07 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 21EA5200E0D; Sun, 17 May 2009 00:37:07 +0300 (IDT) X-CheckPoint: {4A0F313F-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 n4GLb6qO023847; Sun, 17 May 2009 00:37: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; Sun, 17 May 2009 00:37:06 +0300 From: Yaron Sheffer To: Vijay Devarapalli , "ipsec@ietf.org" Date: Sun, 17 May 2009 00:37:04 +0300 Thread-Topic: [IPsec] Redirect -09 comments Thread-Index: AcnUUQKW97cHVLC9RD6K6Gnsr2QH0ABU2GprADHjkGA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@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; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0043_01C9D687.999026E0" MIME-Version: 1.0 Subject: Re: [IPsec] Redirect -09 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, 16 May 2009 21:35:39 -0000 ------=_NextPart_000_0043_01C9D687.999026E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Vijay, Regarding loop avoidance, please use RFC 2119, capitalized should's. Regarding identity protection, I now realize I don't understand the relevant paragraph. The text is: Redirecting based on the unauthenticated identities might leak out information about the user when active attacker can get information to which gateway user was redirected to. If redirection is based on some internal information of the user, it might leak information to attacker about the user which might not available otherwise. To protect against this kind of attack the redirection based on the ID should happen only after client has also authenticated himself. If the information leak you are worried about is simply the name/address of the redirected-to gateway, then this is available to a passive attacker as well, by simply observing the client's next message. Or were you thinking specifically of an attacker sitting next to the gateway? Also note that the last sentence contradicts our choice to allow redirects at the first IKE_AUTH response (for EAP). Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Saturday, May 16, 2009 0:31 > To: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Redirect -09 comments > > Hi Yaron, > > On 5/13/09 10:01 PM, "Yaron Sheffer" wrote: > > > Hi, > > > > While preparing to progress the draft to AD review, I reread it once > again. > > Here are a few comments. Although not all are nits, none of them should > block > > the document now. > > > > Thanks, > > Yaron > > > > Not-quite-nits: > > > > General: a long way back we discussed loop avoidance, but this never > made its > > way into the draft. The document implicitly allows multiple redirections > in > > sequence. We should specify somewhere that the client MUST have a > threshold > > value X (possibly 1), where it is willing to redirect at most X times in > > sequence. This is meant to deal with faulty configuration, not with > active > > attacks. > > I added the following text to the Security Considerations section. > > The client could end up getting redirected multiple times in a > sequence, either because of wrong configuration or a DoS attack. The > client could even end up in a loop with two or more gateways > redirecting the client to each other. This could deny service to the > client. To prevent this, the client should be configured not to > accept more a certain number of redirects within a short time > period. This should be configurable on the client. > > Freel free to modify the text. > > > 9. I believe the last sentence "To protect against this kind of attack > the > > redirection based on the ID should happen only after client has also > > authenticated himself." should read "after the *gateway* has also > > authenticated itself". > > Hmm.. This is about revealing information about the user. So I don't see > how > this can be avoided if the gateway is authenticating itself. > > > 10. Please add at the end of the section: A specification that extends > this > > registry MUST also define in which notification(s) the new values are > allowed. > > > > Nits: > > > > 1. "connect to the IP address of the VPN gateways", change "gateways" to > > "gateway". > > > > 3. "In practice, this means the new gateway either", remove one > "either". > > > > 6. mesage -> message > > > > 6. "presented by the client in the first IKE_AUTH exchange itself." - > this > > text is duplicated. > > Fixed all of the above. Thanks. > > Vijay > > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0043_01C9D687.999026E0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNjIxMzcwNFowIwYJKoZIhvcNAQkEMRYEFP8pGLVWaHnU m/0k8+YyigXelwT6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Le72CH4KiY49OzK3b6FUsuSkpzt9ERwvOwPHcpSmDeIq9FgkN76kjxYQP2uUS3LL7IomZmVQahYS n6twH6XFWMyf/jW3o0k8qo3UQ3ClUe9h3OxWuOl3rWHhpKLMpRbfS+/7ypTIEfyHE6oOpRAV/Qbq PXbSyQB4Qmw8v/tOxDuHIQHIc+YtbxPAZsPAFw6N87EuN64R2ZG0H8qVzkl8KYAqJHisYsFeFM6F IsypYqS8UQzM1tFwLe12DYnsBKht5MBbulVJ5tSBQhVsFuXF37LhcLF3bRgDtmxAyV1Um0RrshCT i6YdlCbnh3sTSVN3hsqa31YV53tpdoR+3TabCAAAAAAAAA== ------=_NextPart_000_0043_01C9D687.999026E0-- From ynir@checkpoint.com Sun May 17 06:15: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 C2C653A6BF1 for ; Sun, 17 May 2009 06:15:45 -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 RaZzHSYuPLQp for ; Sun, 17 May 2009 06:15:36 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CF9D13A6BEF for ; Sun, 17 May 2009 06:15:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0675F200E10; Sun, 17 May 2009 16:17:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A977A200DFB for ; Sun, 17 May 2009 16:17:09 +0300 (IDT) X-CheckPoint: {4A100D8C-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 n4HDH8qO027423 for ; Sun, 17 May 2009 16:17:09 +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, 17 May 2009 16:17:08 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Sun, 17 May 2009 16:17:08 +0300 Thread-Topic: Question regarding VID payload Thread-Index: AQHJ1vHHL6WeKHSWp0asl8mDdMUPUQ== Message-ID: <9FB7C7CE79B84449B52622B506C78036134111302A@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: [IPsec] Question regarding VID 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: Sun, 17 May 2009 13:15:45 -0000 Hi all I've just noticed that section 3.12 of the bis draft has the following text= : Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given "magic numbers" out of the Future Use range by IANA, and the requirement to use a Vendor ID will go away. This seems like a weird requirement, and in fact hasn't been in use so far.= Neither the individual extensions nor the extensions currently created by = this WG define any Vendor IDs.=20 The more common procedure is to announce support for the extension using a = notification (private at first and later from IANA) and not use any VendorI= D at all. This is supported by section 3.10: "Notify payloads with status t= ypes MAY be added to any message and MUST be ignored if not recognized." How would people feel about demoting this MUST to a MAY ?= Email secured by Check Point From yaronf@checkpoint.com Sun May 17 07: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 5BD713A6DC0 for ; Sun, 17 May 2009 07:44:45 -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 k+vacspQYdda for ; Sun, 17 May 2009 07:44:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 605033A6CE3 for ; Sun, 17 May 2009 07:44:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9F6C830C002; Sun, 17 May 2009 17:46:13 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 52063200E06 for ; Sun, 17 May 2009 17:46:13 +0300 (IDT) X-CheckPoint: {4A10226B-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 n4HEkCqO016659 for ; Sun, 17 May 2009 17:46:12 +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, 17 May 2009 17:46:12 +0300 From: Yaron Sheffer To: Yoav Nir , "ipsec@ietf.org" Date: Sun, 17 May 2009 17:46:08 +0300 Thread-Topic: Question regarding VID payload Thread-Index: AQHJ1vHHL6WeKHSWp0asl8mDdMUPUZAaStWw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584187@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036134111302A@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036134111302A@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_01C9D717.5A7CFC90" MIME-Version: 1.0 Subject: Re: [IPsec] Question regarding VID 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: Sun, 17 May 2009 14:44:45 -0000 ------=_NextPart_000_0000_01C9D717.5A7CFC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav, If we don't require a VID, what's there to prevent a conflict between two vendors' private notifications, with the recipient misinterpreting the sender's notification? Note that we never required private notification numbers to be picked at random, so conflict are likely to occur. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Sunday, May 17, 2009 16:17 > To: ipsec@ietf.org > Subject: [IPsec] Question regarding VID payload > > Hi all > > I've just noticed that section 3.12 of the bis draft has the following > text: > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > that gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA, and the requirement to > use a Vendor ID will go away. > > This seems like a weird requirement, and in fact hasn't been in use so > far. Neither the individual extensions nor the extensions currently > created by this WG define any Vendor IDs. > > The more common procedure is to announce support for the extension using a > notification (private at first and later from IANA) and not use any > VendorID at all. This is supported by section 3.10: "Notify payloads with > status types MAY be added to any message and MUST be ignored if not > recognized." > > How would people feel about demoting this MUST to a MAY ? > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0000_01C9D717.5A7CFC90 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxNzE0NDYwNVowIwYJKoZIhvcNAQkEMRYEFOzVaLRFEBBc BBpOcRYo9ef5vWBvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA tnRmZIkpBgVRONQgD1kWZj3KfWCwJzJSyQ5zjXx4HHKrxu9I3YRt4Eu2bz8vUIxz1JC53Yebi1FG nlgrZIqQkUzAp3G1ChUVrvOa3RCLZKMwbasqwO1CqD7tUmJoX9B/KPC+gBdqoG7kjGrbY8aiI5r8 uqS/a5xV9BwcVjGZj7auGTdvLV6q6wfKd4s4jmKN68JdNIRCgkCqOwMctznxGBZ1014Fb6SE6qzY gPM9LegijJ7muiyeP6cHxVi84LMbFUD/6Ai5rQ02vg+TWNOfTYN01XnGU4Su2OUghIDMkWgzhci8 vLHcYXrVbngc/BjSspzRNftLcCDirUkBhDrmcgAAAAAAAA== ------=_NextPart_000_0000_01C9D717.5A7CFC90-- From ynir@checkpoint.com Sun May 17 08:03:38 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 BF2C83A6B92 for ; Sun, 17 May 2009 08:03:38 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJa01LSNOiHX for ; Sun, 17 May 2009 08:03:37 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1242572618-22294-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8F0A43A687B for ; Sun, 17 May 2009 08:03:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 98B7A30C001; Sun, 17 May 2009 18:05:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 35670200E00 for ; Sun, 17 May 2009 18:05:10 +0300 (IDT) 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 n4HF59qO020509 for ; Sun, 17 May 2009 18:05:09 +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, 17 May 2009 18:05:09 +0300 From: Yoav Nir To: Yaron Sheffer , "ipsec@ietf.org" Date: Sun, 17 May 2009 18:05:08 +0300 Message-ID: <9FB7C7CE79B84449B52622B506C78036134114A7B3@il-ex01.ad.checkpoint.com> Subject: Re: [IPsec] Question regarding VID 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: Sun, 17 May 2009 15:03:38 -0000 This is a multi-part message in MIME format... ------------=_1242572618-22294-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1242572618-22294-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8F0A43A687B for ; Sun, 17 May 2009 08:03:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 98B7A30C001; Sun, 17 May 2009 18:05:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 35670200E00 for ; Sun, 17 May 2009 18:05:10 +0300 (IDT) X-CheckPoint: {4A1026DC-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 n4HF59qO020509 for ; Sun, 17 May 2009 18:05:09 +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, 17 May 2009 18:05:09 +0300 Content-Type: multipart/mixed; boundary="_000_9FB7C7CE79B84449B52622B506C78036134114A7B3ilex01adcheck_" From: Yoav Nir To: Yaron Sheffer , "ipsec@ietf.org" Date: Sun, 17 May 2009 18:05:08 +0300 Subject: Re: Question regarding VID payload Thread-Topic: Question regarding VID payload Thread-Index: AcnXAN4QlWD+XAtkRnicImnU+UJXkA== Message-ID: <9FB7C7CE79B84449B52622B506C78036134114A7B3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <9FB7C7CE79B84449B52622B506C78036134114A7B3@il-ex01.ad.checkpoint.com> acceptlanguage: en-US MIME-Version: 1.0 --_000_9FB7C7CE79B84449B52622B506C78036134114A7B3ilex01adcheck_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5qGU54ml4p2l4oGz5r2u5qG05rmp4oGn5r2054Cg5pWy5pW255Gu5oSg5oyg5rmv5rGm5o2p4rG0 5oig55G155Cg5oWo4oG05pWz55Gj5r2p4oGu54Gz5o2l5pmp5o2p5rGh56Ws54iK5pml54ml4oGz 5r204oig54mX55Gp54ml4oGz5pmv5KSg55Gu54ml5pWu4rW054mk5pmh54204rii5LCg5r2v5qWr 5p2u55Cg54mo55Wv5qGn55Cg5pWo5KSg55Gu54ml5pWu4Km054mE5pmh542055Cg5oWo4oG056Gl 5pW05pGu5KSg5JWL44m24oCs5r2u5pWu54yg56Wh54yg5rWv55Gl5qWo5p2u5rCg5q2p4rGl4oig 54214oGl5r2u5qW05qWm5oWj5qW05rmv55CK54G54oGl45yx45Ss45i04oCs5rmh4oGk54Gz5o2l 5pmp4oG555Wz54Gw54mv4oG05qW35qG05Zig5JGJ55ig5rGh5pW15pSK5oix45y15oWh45S044C3 44iy44i15oS25oi245C044Cz5pGi5piy44Gh44Cx4oix4KiK5qGU56Wl5oSg5rGs5qig54214oG0 5oWo5pW25oSg5rig55Gv5pmp5o2p55Gh5r2p4oGu5oWw5rG55oWv4oGk5qW35qG055Cg54G54oGl 5ZCi5IWC5oig4oG55IWJ5IWO4oCi5rmh4Kmk5qG355Gh55ml54ml55Cg5pWo4oG55r2k5pig54mv 5qSg55Gu54ml54Gv55Cg542l54205ryg4oGy5r2m4oGy5o2h55W05rGh5qSg55Gu54ml54Gv5qSg 4oGu5qG04oGl5qWm5rGl4Kmk5pWy5oWt5rmp4oGz5rm154Gz5o2l5pmp5pWp4rmk4KiK5r2T55yg 4oGl5qGz55Wv5pGs5pSg55Gp5pWo4oGy5rml5r2j54m15p2h4oGl55Gz5pm14oGm5qWs5pWr55Cg 5pWo5oSg5r2i5pW25qSg4oGu4rWJ542E5ryg4oGy5rGl5pWz55yg4Kml5qGz55Wv5pGs5rig55Gv 54yg5pWw5qWj56Wm5qSg4oG05rmp55Cg5pWo5oig542p5pCg5o2v5rW15rml4rm04KiK4oGJ5r2k 4p2u4oG05qG05rmp4oGr5qG054ml4p2l4oGz55ml5rml5oSg54Cg5r2y5pWj55Wk5pWy55Cg4oGv 5pWn4oG05rmh5KSg5LmB4oGB542h5qWz5rmn5pWt55Gu5oig5pml54mv4Kml5qG04oGl54mk5pmh 4oG05r2n542l55Cg4oGv5oWs55Gz5oyg5rGh4rGs5ryg4oGy5r2054ig5rWl55mv4oGl4oGh5qG3 5rGv4oGl5oWw5rG55oWv4oGk54mm5rWv55Cg5pWo54yg5pWw4Kmj542h54Cg54mh4oG05pmv5ISg 5ZGV45GI4rC45oig55G15KSg5oyg55Wv5pGs5oig4oGl54m35rmv4oGn5rmv55Cg5qWo4rmz4riu 4KiK5rmP5Yyg5rm14oCs44Cy46Sw44Ct4rS145yx5oSg4oG045yx45C64oC244Cr44Cw4rCw5aSg 54mh5rmv5Yyg5pWo5pmm54ml55yg5r2y5pW04Ki64oC+5qWI5aSg5oWv4rG247iK4Kig4oC+5pmJ 55yg4oGl5r2k4p2u4oG05pWy55Wx54mp4oGl4oGh5KWW4rGE55yg5oWo4p204oGz5qG054ml4oGl 5r2054Cg5pWy5pW255Gu5oSg5oyg5rmv5rGm5o2p4oG05pWi55205pWl4oGu55204Kmv4oC+5pW2 5pGu54mv4p2z54Cg5qWy5oW25pW05rig55Gv5pmp5o2p55Gh5r2p542u4oCs5qW35qG055Cg5pWo 54ig5o2l54Gp5pWp55Gu5rSg542p5rmp5pW054Gy5pWy5qW05p2u55Cg5pWo47iK54yg5rml5pWk 4p2y4oGz5r2u5qW05qWm5oWj5qW05rmv4oC/5r2O5pW055Cg5oWo4oG05pW35rig55ml54ml54ig 54Wl5qW15pWy4oGk54mw55mp55Gh4oGl5r2u5qW05qWm5oWj5qW05rmv47iK5rig5rW15pWi542y 55Cg4oGv5pWi54Cg5o2p5pWr4oGk55Gh54ig5rmh5r2k4rGt54yg4oGv5r2j5pmu5qWs55Gj5oSg 5pWy5rCg5q2p5rGl4oG55r205ryg5o2j54m14Kiu4oC+47iK5ZCg5oWo5q2u4rGz47iK4KSg5oWZ 5r2y4Kmu4oC+47iK47ig4rSg4rSt4rSt54mP5p2p5rmp5rGh5LSg542l5oWz5pWn4rSt4rSt4Kit 4oC+4oC+54mG5rWv4oC654Gp5pWz4rWj5r2i5rm15pWj5IGz5pWp5pm05ryu5p2y5ayg5oWt5rGp 5r205qS6542w5o2l5oit55Wv5o2u542l5qWA55Gl4rmm54mv5bWn5Lyg4oGu5pWC5oWo5pms5Lyg 4Kmm4oC+4oC+5r2Z55mh5Lig54mp47iK47ig5Yyg5rml46m05Yyg5rm15oWk4rG55LSg56Wh44Sg 4rC344ig44Cw4oC545ix44S64Ki34oC+4oC+5r2U4oC654Gp5pWz5IGj5pWp5pm05ryu5p2y47iK 47ig5Yyg5om15pWq55Gj4oC65KWb542Q5o2l4oGd55WR542l5qW05rmv54ig5p2l54mh5qWk5p2u 5Zig5JGJ54Cg56Wh5r2s5pGh47iK47ig4Kig4oC+4oC+5qWI5oSg5rGs47iK47ig4Kig4oC+4oC+ 4p2J5pW25qig54214oG05r2u5qW05pWj4oGk5qG055Gh54yg5o2l5qW05rmv44yg44Su4oCy5pmv 55Cg5pWo5oig542p5pCg5oWy55Gm5qCg542h55Cg5pWo5pig5rGv5r2s5qW35p2u47iK47ig55Cg 56Gl46m047iK47ig4Kig4oC+4oC+4oCg5Zyg5qWy5pW0542y5ryg4oGm5rmJ5pW05rmy55Gl5JCt 5oWy55Gm4oGz5qG34oGv5qW35qGz55Cg4oGv56Gl5pW05pGu55Cg5qWo4oGz54mw55Gv5o2v5rGv 5LSg5Y2V4KmU4oC+4oC+4oCg5pCg5pml5rmp4oGl4oGh5pWW5pGu54mv5KSg4oGE5oWw5rG55oWv 4oGk5r205oSg5rmu55Wv5o2u4oGl5qG04oGl5omh5rGp55Gp4oG55r205qSg54Gt5pWs5pWt55Gu 55Cg5pWo47iK47ig4oCg4oCg56Gl5pW0542u5r2p4oGu5rmp55Cg5pWo5KSg55Gu54ml5pWu4rW0 54mE5pmh4rm04oCg55GJ5qSg4oGz56Gl5pWw55Gj5pGl55Cg5oWo4oG05rmJ5pW05rmy55Gl5JCt 5oWy55Gm4Kmz4oC+4oC+4oCg55Cg5oWo4oG05oWn5rmp5oSg5o2j54Gl5oW05o2u4oGl5rmh4oGk 54mh4oGl55Gz5rmh5oWk5pGy56mp5pGl55yg5rGp4oGs5pWi5pyg55mp5rml4oig5oWt5qWn4Kmj 4oC+4oC+4oCg5rig5rW15pWi542y4oCi55Wv4oG05pmv55Cg5pWo5Jig55G154m14oGl542V4oGl 5oWy5p2u4oGl56Wi5KSg5LmB4rGB5oSg5pGu55Cg5pWo54ig54Wl5qW15pWy5pWt55Gu55Cg4Kmv 4oC+4oC+4oCg55Sg5pWz5oSg5Zig5rml5r2k4oGy5JGJ55yg5rGp4oGs5r2n5oSg5oW34rm547iK 47ig4Kig4oC+4oC+5qGU542p54yg5pWl542t5rCg5q2p4oGl4oGh5pW354mp4oGk5pWy55Wx54mp 5rWl5rml4rG05oSg5pGu5qSg4oGu5oWm55Gj5qCg542h4p2u4oG05pWi5rml5qSg4oGu54214oGl 5r2z47iK47ig5pig54mh4oCu5pWO55Gp5pWo4oGy5qG04oGl5rmp5qWk5qW255Wk5rGh5pSg55G4 5rml5qWz5rmv4oGz5r2u4oGy5qG04oGl56Gl5pW0542u5r2p542u5oyg54m15pWy55Gu56Ws47iK 47ig5oyg5pWy55Gh5pGl5oig4oG55qG0542p5Zyg4oGH5pWk5qWm5pWu5oSg56Wu5Zig5rml5r2k 4oGy5JGJ4rmz47iK47ig4Kig4oC+4oC+5qGU4oGl5r2t5pWy5oyg5rWv5r2t4oGu54mw5o2v5pGl 54m14oGl542p55Cg4oGv5rmh5r2u5rm15pWj54yg54G15r2w55Gy5pig54mv55Cg5pWo5pSg55G4 5rml5qWz5rmv55Sg5qWz5p2u5oSg47iK47ig5rig55Gv5pmp5o2p55Gh5r2p4oGu54Co5qWy5oW2 5pW05oSg4oG05qWm542y4oG05rmh4oGk5oWs5pW04oGy54mm5rWv5KSg5LmB4qWB5oSg5pGu5rig 55Gv55Sg5pWz5oSg56Wu47iK47ig5Zig5rml5r2k5KWy4oGE55Gh5oSg5rGs4oCu5qGU542p5qSg 4oGz55Wz54Gw54mv5pW04oGk56Wi54yg5o2l5qW05rmv44yg44Su46iw4oig5r2O5qW056Wm54Cg 56Wh5r2s5pGh4oGz5qW35qG047iK47ig54yg5oW055W04oGz56W05pWw4oGz5IWN4oGZ5pWi5oSg 5pGk5pGl55Cg4oGv5rmh4oG55pWt542z5p2h4oGl5rmh4oGk5ZWN5ZGT5oig4oGl5p2p5r2u5pWy 4oGk5pmp5rig55Gv47iK47ig54ig5o2l5p2v5qWu5pW64rmk4Kii4oC+4oC+47iK47ig5KCg552v 55yg55Wv5pGs54Cg5r2l5rGw4oGl5pWm5rGl5oSg5r2i55G15pCg5rWl55Gv5rmp4oGn5qG0542p 5LSg5Y2V4oGU5r205oSg5LSg5aWB47yg47iK47ig5JSg5oWt5rGp54yg5o2l54m15pGl5oig4oG5 5qGD5o2l4oGr5r2Q5rmp4Km04oC+4oC+5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f 5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f4Kmf4oC+4oC+5YGJ5pWz4oGj5oWt 5rGp5rmp4oGn5qWs55Gz47iK47ig5KSg542Q5o2l5qWA55Gl4rmm54mv4Kmn4oC+4oC+55Go54G0 46mz4ryv55234rm35pWp5pm05ryu5p2y5rSv5qWh5rWs5rmh5rCv542p5qW05pmu4r2v54Gp5pWz 4Kmj4oC+4oC+47iK47ig5Yyg5oWj5rmu5pGl5oig4oG55qGD5o2l4oGr5r2Q5rmp4oG05r2U5oW0 4oGs5pWT55Wj5qWy56W05Jyg55Gh552l56Wh4Kiu4oC+5qWI5aSg5oWv4rG247iK4Kig4oC+5pmJ 55yg4oGl5r2k4p2u4oG05pWy55Wx54mp4oGl4oGh5KWW4rGE55yg5oWo4p204oGz5qG054ml4oGl 5r2054Cg5pWy5pW255Gu5oSg5oyg5rmv5rGm5o2p4oG05pWi55205pWl4oGu55204Kmv4oC+5pW2 5pGu54mv4p2z54Cg5qWy5oW25pW05rig55Gv5pmp5o2p55Gh5r2p542u4oCs5qW35qG055Cg5pWo 54ig5o2l54Gp5pWp55Gu5rSg542p5rmp5pW054Gy5pWy5qW05p2u55Cg5pWo47iK54yg5rml5pWk 4p2y4oGz5r2u5qW05qWm5oWj5qW05rmv4oC/5r2O5pW055Cg5oWo4oG05pW35rig55ml54ml54ig 54Wl5qW15pWy4oGk54mw55mp55Gh4oGl5r2u5qW05qWm5oWj5qW05rmv47iK5rig5rW15pWi542y 55Cg4oGv5pWi54Cg5o2p5pWr4oGk55Gh54ig5rmh5r2k4rGt54yg4oGv5r2j5pmu5qWs55Gj5oSg 5pWy5rCg5q2p5rGl4oG55r205ryg5o2j54m14Kiu4oC+47iK5ZCg5oWo5q2u4rGz47iK4KSg5oWZ 5r2y4Kmu4oC+47iK47ig4rSg4rSt4rSt54mP5p2p5rmp5rGh5LSg542l5oWz5pWn4rSt4rSt4Kit 4oC+4oC+54mG5rWv4oC654Gp5pWz4rWj5r2i5rm15pWj5IGz5pWp5pm05ryu5p2y5ayg5oWt5rGp 5r205qS6542w5o2l5oit55Wv5o2u542l5qWA55Gl4rmm54mv5bWn5Lyg4oGu5pWC5oWo5pms5Lyg 4Kmm4oC+4oC+5r2Z55mh5Lig54mp47iK47ig5Yyg5rml46m05Yyg5rm15oWk4rG55LSg56Wh44Sg 4rC344ig44Cw4oC545ix44S64Ki34oC+4oC+5r2U4oC654Gp5pWz5IGj5pWp5pm05ryu5p2y47iK 47ig5Yyg5om15pWq55Gj4oC65KWb542Q5o2l4oGd55WR542l5qW05rmv54ig5p2l54mh5qWk5p2u 5Zig5JGJ54Cg56Wh5r2s5pGh47iK47ig4Kig4oC+4oC+5qWI5oSg5rGs47iK47ig4Kig4oC+4oC+ 4p2J5pW25qig54214oG05r2u5qW05pWj4oGk5qG055Gh54yg5o2l5qW05rmv44yg44Su4oCy5pmv 55Cg5pWo5oig542p5pCg5oWy55Gm5qCg542h55Cg5pWo5pig5rGv5r2s5qW35p2u47iK47ig55Cg 56Gl46m047iK47ig4Kig4oC+4oC+4oCg5Zyg5qWy5pW0542y5ryg4oGm5rmJ5pW05rmy55Gl5JCt 5oWy55Gm4oGz5qG34oGv5qW35qGz55Cg4oGv56Gl5pW05pGu55Cg5qWo4oGz54mw55Gv5o2v5rGv 5LSg5Y2V4KmU4oC+4oC+4oCg5pCg5pml5rmp4oGl4oGh5pWW5pGu54mv5KSg4oGE5oWw5rG55oWv 4oGk5r205oSg5rmu55Wv5o2u4oGl5qG04oGl5omh5rGp55Gp4oG55r205qSg54Gt5pWs5pWt55Gu 55Cg5pWo47iK47ig4oCg4oCg56Gl5pW0542u5r2p4oGu5rmp55Cg5pWo5KSg55Gu54ml5pWu4rW0 54mE5pmh4rm04oCg55GJ5qSg4oGz56Gl5pWw55Gj5pGl55Cg5oWo4oG05rmJ5pW05rmy55Gl5JCt 5oWy55Gm4Kmz4oC+4oC+4oCg55Cg5oWo4oG05oWn5rmp5oSg5o2j54Gl5oW05o2u4oGl5rmh4oGk 54mh4oGl55Gz5rmh5oWk5pGy56mp5pGl55yg5rGp4oGs5pWi5pyg55mp5rml4oig5oWt5qWn4Kmj 4oC+4oC+4oCg5rig5rW15pWi542y4oCi55Wv4oG05pmv55Cg5pWo5Jig55G154m14oGl542V4oGl 5oWy5p2u4oGl56Wi5KSg5LmB4rGB5oSg5pGu55Cg5pWo54ig54Wl5qW15pWy5pWt55Gu55Cg4Kmv 4oC+4oC+4oCg55Sg5pWz5oSg5Zig5rml5r2k4oGy5JGJ55yg5rGp4oGs5r2n5oSg5oW34rm547iK 47ig4Kig4oC+4oC+5qGU542p54yg5pWl542t5rCg5q2p4oGl4oGh5pW354mp4oGk5pWy55Wx54mp 5rWl5rml4rG05oSg5pGu5qSg4oGu5oWm55Gj5qCg542h4p2u4oG05pWi5rml5qSg4oGu54214oGl 5r2z47iK47ig5pig54mh4oCu5pWO55Gp5pWo4oGy5qG04oGl5rmp5qWk5qW255Wk5rGh5pSg55G4 5rml5qWz5rmv4oGz5r2u4oGy5qG04oGl56Gl5pW0542u5r2p542u5oyg54m15pWy55Gu56Ws47iK 47ig5oyg5pWy55Gh5pGl5oig4oG55qG0542p5Zyg4oGH5pWk5qWm5pWu5oSg56Wu5Zig5rml5r2k 4oGy5JGJ4rmz47iK47ig4Kig4oC+4oC+5qGU4oGl5r2t5pWy5oyg5rWv5r2t4oGu54mw5o2v5pGl 54m14oGl542p55Cg4oGv5rmh5r2u5rm15pWj54yg54G15r2w55Gy5pig54mv55Cg5pWo5pSg55G4 5rml5qWz5rmv55Sg5qWz5p2u5oSg47iK47ig5rig55Gv5pmp5o2p55Gh5r2p4oGu54Co5qWy5oW2 5pW05oSg4oG05qWm542y4oG05rmh4oGk5oWs5pW04oGy54mm5rWv5KSg5LmB4qWB5oSg5pGu5rig 55Gv55Sg5pWz5oSg56Wu47iK47ig5Zig5rml5r2k5KWy4oGE55Gh5oSg5rGs4oCu5qGU542p5qSg 4oGz55Wz54Gw54mv5pW04oGk56Wi54yg5o2l5qW05rmv44yg44Su46iw4oig5r2O5qW056Wm54Cg 56Wh5r2s5pGh4oGz5qW35qG047iK47ig54yg5oW055W04oGz56W05pWw4oGz5IWN4oGZ5pWi5oSg 5pGk5pGl55Cg4oGv5rmh4oG55pWt542z5p2h4oGl5rmh4oGk5ZWN5ZGT5oig4oGl5p2p5r2u5pWy 4oGk5pmp5rig55Gv47iK47ig54ig5o2l5p2v5qWu5pW64rmk4Kii4oC+4oC+47iK47ig5KCg552v 55yg55Wv5pGs54Cg5r2l5rGw4oGl5pWm5rGl5oSg5r2i55G15pCg5rWl55Gv5rmp4oGn5qG0542p 5LSg5Y2V4oGU5r205oSg5LSg5aWB47yg47iK47ig5JSg5oWt5rGp54yg5o2l54m15pGl5oig4oG5 5qGD5o2l4oGr5r2Q5rmp4Km04oC+4oC+5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f 5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f5b2f4Kmf4oC+4oC+5YGJ5pWz4oGj5oWt 5rGp5rmp4oGn5qWs55Gz47iK47ig5KSg542Q5o2l5qWA55Gl4rmm54mv4Kmn4oC+4oC+55Go54G0 46mz4ryv55234rm35pWp5pm05ryu5p2y5rSv5qWh5rWs5rmh5rCv542p5qW05pmu4r2v54Gp5pWz 4Kmj4oC+4oC+47iK47ig5Yyg5oWj5rmu5pGl5oig4oG55qGD5o2l4oGr5r2Q5rmp4oG05r2U5oW0 4oGs5pWT55Wj5qWy56W05Jyg55Gh552l56Wh4Kiu --_000_9FB7C7CE79B84449B52622B506C78036134114A7B3ilex01adcheck_ Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 Content-Type: application/ms-tnef; name="winmail.dat" eJ8+IiRlAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEJgAEAIQAAADQ3NDY4QjIz NzRBNjRBNDlBMzdDNjU3REEwMzZDOTNDABgHAQ2ABAACAAAAAgACAAEFgAMADgAAANkHBQARAA8A BQAIAAAAEgEBIIADAA4AAADZBwUAEQAPAAUACAAAABIBAQiABwAYAAAASVBNLk1pY3Jvc29mdCBN YWlsLk5vdGUAMQgBBIABACMAAABSZTogUXVlc3Rpb24gcmVnYXJkaW5nIFZJRCBwYXlsb2FkAEkM AQOQBgDkHQAAKwAAAAIBfwABAAAARwAAADw5RkI3QzdDRTc5Qjg0NDQ5QjUyNjIyQjUwNkM3ODAz NjEzNDExNEE3QjNAaWwtZXgwMS5hZC5jaGVja3BvaW50LmNvbT4AAAIBCRABAAAAIxcAAB8XAADb RwAATFpGdX29ExVhAApmYmlkBAAAY2NgcGc5MzYA/gNDdHhleHQB9wKkA+MCAGMCaArAc2V0MTM0 3iAHbQKDAFARPTIKgAa0LQKAfQqACMg7CWIxOX4yCbQWggoyFoECgBVyKucJsAnwBJBhdAWyDlAD YERzbwGAIEV4EbFuuxhABlJ2BJAXxgIQcgDA+nQIUG4aQRAQBcAFoBt0NGQgA1IgEBIXwlx2yQiQ d2sLgGQ1HWME8BsHQBeAMApxGAJia20Ma3MBkAAgIEJNX8BCRUdJTn0K+wvyIwEwAAAnQkQhoERC XSGgQQFAIbABQHUeoTiENT8MYDgzMDcjEI0hsDMhoQBQJ0U4IaCiRh3wJzlDIiE3IyFsMjkjASQg NCRRI8E56kUhoDckgUMlACaQJfJVJbFCJbFBJME5JrFF6yPCI8FDJbFEJfIkwiIRqjkiETQkgUQm MUUOsNMisBIgODAjgTkkAiaxZyejIdEnojVGIaEscUF7JjAjMjgq8icyFqAnkzjvIdEr4ivhIzIy KvImMSAAmySRLeFDJ7IkgThBKgd3JpAmMSICQjCSJIEiQja/L9IwkiRBIkYjRSWmQSQB9kMssiJR QTNSJ7I0wjOc+y/CIoM4AcEjgSemIkUnE/ZBLHAqkTYOoDgyNYIscW5FMNExgiliNBagKpE49x6g IxEWgDQzQCryK/IkAu45LMMkoDFRNyISLDUiQ9skAT2iODqyJEFFK/k5Y8ciEDffOO4yNjc6Jimi rzrtLB8tJSOyOD1xRCSBHkYpcig0QVYisDc3M945PDIlQEFgIxIyOhMjtrc5ZSIwMNE2JIEyAjcr 8u9LRSWiJ2Y/ojkkQSniPeb6OTDRRUqCS0I9cCqSS3DfQbI1BimySBElMTNKCk3C2yoyPXFCJEEr IjUlsVIm2ykmK2JGOTImMUMAUFEl/SKwNElBPDIOoElAVmNBcPc6IUm2JLI5ObElMS9PMFivIzES IEGyWUVCIhFELeH9OuJGJbBGRyyyJMEkNkFwr0VxVXFIwDyAMSOBRj8y/yWxMYYnIyb1T3ErE17R VgL+M1FiUyNIEg6gSHRJ0FDwv0kTIvBilCLwYZMiUUVAsudg4lwxYXE2NGKkSPI2JPsw0TCCNjNS XyJeImXhI3HHIzAmYFXSMjU3KuIhxr81Mj1iKCYpo1LyJEFEPzL/UMZceVlCJzUoJ1SyOzInsn9S 8jCdLhMpci6sMYIsokT9IlFEZqJTMizyWJRc3kBn21U7MjNDO7JDcDBXwys0f1pldmJ3l0mEQ2BX 2UNgNu8q4iQzb/k5IjU9cjj1QG7/WnUuk0cSKDVb5SQkK/VCKv0yAkNv9T6jZqIrckTlKKK/LOU6 IlVhJpBaQ3ajQiTB/17SfnNpgjGVfz+ATYYVLwb/JDVRJlKnKbJcMXnVJqdTMv8nsiTGI1Qkskpz WQ8wpDlj3yTAO9JXQ2jFK+I4JMEm4u5EWFRhkyaxNCTCP3VHw/8t4SciS/M2BXzIdqQkwiXy/y5i JEEmopXiMEKJSSejKXL/JII7sSUxZZFNpD/yMdI1xf9AqSgXJaI64m0niCsqkXuA+1qjMNE3OvKC zIp1LYeRRv950V6Skj+TRW4uSzaD4YZD/1KjUrIwkiQGLuQtUyTEmn/vKydmoltyJjFGJrEwAlui /ymiNTKVpTvSWKJotSUhT+P/fbUispkyLRYkPyVAZhJ0B/8iXyNke1WVpmo3JjUlo2mC/z1yLeI/ ciayJrVFVSMyYZO/J3KD9KcGWEJBZqYSNYlT/2jQnkWUc03CLmIkwiSCgsT/J5crJjMGW+ahZYkN Om0tF/8uYiISgca2DVMyPjWqwyi1fzGFKpIBwHFigsw0d7CROP9TcmmCR1KE5FWWJTBHAHoZ/ymj fRJRRHGfcqxb45vVJ2b/msqkXUNRe4C5miY2JzKJUv9GZTd2eeDEtEuCQTJhgMaw/Z3DM0GTKy1B Vyimkr93Bv++yFtiKSUlJikmQGdNxKuz/16RO9J48JApNgUhwmATjWT/SbVlw0mCVhBlgGKVYYKd 4v9I4FXoKBYtFVYJaACsdN7gf2Wl2zNl4d4TEiBWwkbzRv+ChTICKSbc55sVW2M7Mjj1f5FFs+dH RUNRSXVTYKGlRd8uIuTFcpYqolbTNTNArAT/q/PqJkvClnKRXa0/LUO1d/+OIjUCKjKRl8hVQVJe YNNk/9OwyhLoRSymHqAeoSMYsA7/iYYlvybPJ98o7yn5RlZrQvtbMi3hNEC2T4EvFf2FQ1L/2zLq JvklR8Vb162iZhP4Jf9Ns/miJAE6AEcobi9vP3BL/2aEcuNJ5HOfzV3GhjAWjeL/YKL5ZbvHIhJm ZthW+KFHR/+N4iHR+JdTtj39QOfspEsn/5Wn+WKuoK2TSYMjXFIvUz//2Ka5EJCWDhlFX0ZlVLJt +f97T8aGLLJrBf3C+JVYdrCD/zFRsfMr9XBhUS8VTxZfEXv/BFaqxv0GO2N8GLZm/Qb4Fv8xBpoF HodwNcZ3WBTvWMSR/542S3G2Z5Y2MVFHQpmGTTP/pSJtufjTTsyKZ1p195aCtf/lYxqSlqVDUXai 6hURtzNz/9zybLZLQtTixJFJA+ym49P/1AOiErP1Q1KsdDTK7IFkUP/TVLkQnbVP4jvWvxRbsq6h /0XSp0bEB/nQirC5lrwVVrD/tsg77TQisUM0tOolsIJwov9MtblC09MLWaCh7AFWsK/D75wWjWW0 dXZhNAIE+WX4kvu8g2lBNr91aTJwYl+Ti/X/+hJp8/em+eJe4maifJJZhu+mIruSksWOEkQHJqoS +eL/dFXWUY/DrlN+xS8CNdOUyP9Ys6A2bLZaAlH5edHtSOoX/wbihOJ7Ui3RphJq8vHWOm3/3Nur g0fAZYLc3iJk2sPsMP88Iz715XKT85nSsNLkQc9j/z0y2sLjxeLB4gTVIGMUixD/rAPpwEIfkLRw 8kRPRVTe8P/1sEf/SQ9YX9zntMEis/li/x/WYvfzI6/DtMJM+MhSPKPfAmKkJbwDIwwKN0Owkm7C X+VG2oKTghBVtTI13bEx//NgV2ACKV1mBxNDQg0SK6L/On3tG+oesveCQhOSdA91H/+w47lzAFcn ckxygkLhJyDv/0cmy8YI2SoTElYK1iMOt3H33pPtEdPSQaYi+SIbZafP/6jfqeUDYiZFOwAQJOhy ucb/g3760ncHBqWwgwhVEEVnD/8ZJ9ah6xFaVne/eM9ChOLQ/7iiAuYC5RinJgXFB5klUDTvDjii JVAn82A1wkaGOfWr//xkILOKhqHmJo2NBA44+iX/2f71tR8GBNeqWcmSXOq7Af+9sT8Sj1+QY6nH vNWvGcgp/7HySeIA37hkrKLVU8pfy2z/96X6FveSxAJOLfcXvkwKwv84w0s1+ZPhIzHr9iMPEtah /kb2sqcCaOa7mRDPOn2QRP+QNpp+B1UGxlKXPfWxv9Ul/7E3HCULw1BzA5AIAkMze6Hfv6ba8u1E kGP5kjcwUq9E/xQ66xLOtS63c3Mf1Rlvk4//lJ+Vr5a1/3Fhj7x6wK/nFf8NmfoWMzYLQ+WChgL9 Uqr8/yrVHobQp9el+aLYVSsTW/T31oT4oRqSOHNGr4Xoc0s0//Wi09InZy3RY0AfaBLGgnL/JTJK ptpzMZFVEBvQxZ+QRf8kfyWMkDK6w040fAeDDxFl/zdAO5L5hA8VWiLN5lExjTL/rFaGBYr29yb7 IetRuHdXYv9cJR6g92J21puOCd4dL/i4/7D//07GLgJhg7b9gvoWcPX/ErjvdfWxNGJxdtFf0mQr U/+7UsmWx2L8YbwC9eGyr47//1kmSmINRhJH/hQK84JyME3/o54aplf1zPYPVTZTRvJX9P/YdBKY XFNjUuM+vXlS0yKC/7dVv6OHDBOzQoN8JSd2EtX//f17l6xlH9Kl0mctiPbNaP9cgFLmDBYTFlJ0 OEKr3j31/2/3foHTgk4jPjhTQ12j1ZL/I0YPltQWUnQUeQkfIJi03/+16LWHb3KI8jO1+ei5FZ/i /1yQBR8USxWWKhK/5oR1Mbf/fob0tZC1pnJk113yIga6FP3JezhXMuwP7R/o4rwCIWP/8e/y//QH q1b2Ip2iL8YUVv9DtSVWA0eddZ5n0Obd//TU35mcztZ8h0a8f2dDTbJE8v+/MmsS1ZJRMYj2USaD fw0f/w4v5OTqhg6WcIWpZRbP2Ab/nedUIjAC+wKdtRkTti1yAv+RCYXz7nKbBTY2fBUdNtmH/8F4 zLnPU0oymwQQZ1EyJrj/4a96EFcgcbLjPje+6n8eTP82rx8/IEWmANCQI1Smo372/3bOBzX0Lr19 U9PLUsiSXvL/MMVA934V4UR/b4B/gYxaUf+8ILrD1NZism1JFlP28nIP/3McD4aKhavWi39StssW pVL/D1misvuCvvSXFWSB6NDxkv9sAXGy2QbjOggmwCkrva42/+c3e6L6wuFCCezMuR7yepL/7qKk wxnmq3jw03yVGFU/9/84xTe9W4/lN1M1fMLAIn5z7xtSBsKjcSGhN+2iggGgn9siH6YANI2i6yM0 u5Ludf+qZuOzC1JYNSAzu5I0QsvY/Z2iRJ4ye6Ko8alqMLLdZv+Fd/uFneejOMWBGr6fX4ug73Cy qN59p4VyQ/EiRBCmov9yT8PQ92C6wtVGrUdSvRTW/xlfrlT2Ip6jUzSrUqRCVqO/LwKjNeix7aIj nKqiQR8C/4rvi/+ND44fjy+QP5FPkl//k2+Uf5UC1jLFj6qQ2VL1df/rMatSYKKDLnvNCwM+Ys5k +4GfuIZF2VI1AlM2yVJ7Ff/Dk6YBPdOlleiwHGIjjTgz/3Wlx5FVkYLQ99JVIF+g+EP/XWHdECGE msMxBRhSaOHdk/427rIwwWhj9PK2IpsSuxX7LbLO1kNTMj5iG1VTpoDh/xJCVRFVoMQTomIvApg1 1k//ch9NlUyTz2J4kicy2FKFv/+Gz4ffmfnBdVaysHXLQe9X/+WG2oIooju1XoVK0Z0wAZL/S9fn gl1iWLTooe2T87Weg/9L4h1BUmLPU8fh/HIXFBb0/yMra3OfsO5HBDpKowD8+f/f+Rj32JzyfdAh czPi0O45/8eWAOAA4QE0D7Iax9OU4Lf/fzVYJua6JyLntnjGFFY0Nv9M035BOTUBXnPTMYYghDri /8216KzJN/13oBUA4rLDdeb/O78SdDe/OM852xPGByJV4v9anTEvbg6rWtUC57b041my/6lmCpUS VqtTKaXm81O2NcX/MT2tloQYM0YcxADTVOIPjP9Tlx03rzVTrvOxmsNWtRJX/zFFxOYBZviW1JXH EWMQLcL/xuTaaAAyHYKbEqiiaqwoVv/rwzKFt6IRaeUv5j9UCeIF/9SG+3MsggHlPpVi3gHXWDX/ 1gZd0R1i7rdL5W4HLEVKZ/28UDcqhlLhK7enJapVmvvvtLLKR8jWMMFFSbJcoi8C/3hUGkd/NQay wYJ+MurCKdb/uevh5wOjrrJ0pQDzdyH8Av/DI7zWxACC5tNCfyN9gYmB/8WjrU+CVEhgpBALZFLg C+j/WVMt8mmW3fbCAiSyfbYbQ/9W8l0iSbJk0jDADA650paP/1lUb1JCdSQBtaOrbcPggTD/ssJ5 Ri09X+Gi4LLDpO+l/P9ewk4CmR7Hx56SbxJv0p3a92iy1NJ05UIOotdWVvKen/+fq7SjBgPhhTq2 7RJwEgZW/2uSIimggb14ukewdevDlSL/CMK+csIVra+utjNEosMpXn8s80N2vFEMU33JMnNbIUX/ xyHD4RYDDVOqowhTBMGi4P9Vcrxg/DJVEUuACAOBMBJP/7RmFF8VZnOAX4AYLxk/KI//rqej4iNV YqYzGMNTFhOdnH/C4gzTWDKpJlb5y0ZuBkP/70KvsnAS0tZ1ouCFSWWCkf9NEJjTWD9ZTAqevUu6 Tkxe70QvRT9VcsWQNV5C0If3ov9vEnhSauLM1fE9F1ZRttkJ//pDUr9Tz1TaVhMT4+uV2X7/aKWp R3pHXSL2dQsw4FR0k/9v0mH12brLAkc31tXvM9iF/+B1Nz/pV8pRu0EqhkfvSP//rPQwIIqi0xbT FejX9jUC5f/CcrqDIGTeaFEy1NUgk33Q/jX9M1Y8xdvMlPDjWrbBEf/TQvauXTTeaMpV2XebEvzU /8YS7zbVB7kxsdNZtH2viYD/feJfj2CTekfVknucwrjrs3+mk9EenRQEwYFSwfPYckT970FED6K7 1U42fzyvlx5d/8dH2QS/F83Cg3pQckwTAhv32PPfQspRRu9ComI5FtTW/4Uy4Q8KvGB0YGZqrteF 1vb/IsfeBYHvnRWBZ+xV2/Mgo/+jANgyE2O4stGRwgGkQ710e2CT1QI3AIJ/dORqu0JD/9GSOZiw F+lftBVj72T/Zg//ZxLPoTG/jKqQ39hRGmbeBf/KRgNm23NP8rUEew6oVe62/z+lvxbVA93F+0Ms JHUkwRH9A6I4Q3Z/tVdifXW1ZveX//jhM3DvmOL2UqL1YhrW/nP/FDGsX2A59K/1vGBiivMeZP/M t1M/UUU64AvC1PTfRQQi/54W0ZFdYr8mVjVbJsdWUTH/u4GIpyeSLFW/MHjiRwZrvv/aDu1fyOiB L89+ll5CMbSm/82yykZBJeLov6VMQS/SQab/oY+ilNcDi4KZxqkCzJGMMv/GEYLfXy84BhqS3XZP p85E/x2DUqIAfXPO6tYoJZ0m34X/JAOlAigkqKTiyCyDM4Kzbv+NqSMDLCKHhY/TVzzj47mD/5hV 96bjBc4tS8d8lS3idgL/W71ZJp2YLLAjFtxG40YipP8IcnwO3gVAJ/7Bo7IeUw5o/yNzLdNQclD2 38akRiKk5Kn/2U/wyIUPhhiFtwLiWSID5f/KGIlFA2IswNVP5HvlxhpS/5AWVKUB5062xOVg5Xai NQfvLiLyNopEmas4J2K8P71P/7kSjDLxk8Ifwy/EN66GHZL/bdL/9uSGE+X1htN3baVul/+hFq4v xQRpzJ8GTLcW7E+X/kMd4gFCLeKpglBydcFZJv8hVlOv3U/eX7UUurbexkC1/3mV5v+oNm4XJFIA MssybeX/6UOGXUIyYTkQE76iazUGZv9MRe1mqbeRqJzpGtMaYms0/+CXdcL26LHfSkAnUEHis27/ B+66r+58Bt/vb/B1OrCgwP/zhHbTTyZG/tdlxF6NrSQD/5uCmMIvIgD1ESdORbF0T5//UK9RvCqB dGCK86UGMuI9ef/mgyviQj9DTN+2WrV8Bluv/yLmm0Z54t+JcuLLso8k36X/NLG5AMHCPDFB4qk2 s2rYVv+QWfvtfma3Z0eCpQKxctoc/5zp7yLX0ldidPPqFnuowQP/TMXohRAnCPUH7Su/tWcjZX9M 8pBS6vPrglLyc6Hx0TffvdLzUXDP8k8bEDRd0rtT/jSLwr6lepZ1M/lSKGWGQ++LwiRinAht0kRu Yh0SUvH/eZp1sq2WVafLtW4Xc2iVsX/q7m+P8oBA4nkOTddVokP/wVIUQHbSQn++EMeQivKldv99 dyLt5Qbpj36EI5KjMyNk/2NSdHIm0/8yc2W44b3S88z9etJB7zJbH1wvXT9eT19f/2BvYX9ij2Of ZK9lMqZilb//k7CpgsWlu2FMYjDSU15L/d8FYw6SnpRRzxMWRamCtLL/I2aZgktFk8MTEQ4DdcWm cP/skvO9noNF1ZERJcFTAMgC/yVQ39DIc5uBrUDxtGrzATX3qDLqQSbDNr7icEE4k7Uy36RC7AKL Rf3inwZDI2IOkv/rhSPWURGSciVBJdDUo6ui//8yaGWmf0JPHcUx088iSML/92IkIlXvVv9YD2op kaUm4v+ApZtxv4e1tqqy+NIL5S61/xMBshCYchwHk1KbgijkZnEh4MF9fQ0KiqAAHwBCAAEAAAAS AAAAWQBvAGEAdgAgAE4AaQByAAAAAAAfAGUAAQAAACgAAAB5AG4AaQByAEAAYwBoAGUAYwBrAHAA bwBpAG4AdAAuAGMAbwBtAAAAHwBkAAEAAAAKAAAAUwBNAFQAUAAAAAAAAgFBAAEAAABcAAAAAAAA AIErH6S+oxAZnW4A3QEPVAIAAACAWQBvAGEAdgAgAE4AaQByAAAAUwBNAFQAUAAAAHkAbgBpAHIA QABjAGgAZQBjAGsAcABvAGkAbgB0AC4AYwBvAG0AAAAfABoMAQAAABIAAABZAG8AYQB2ACAATgBp AHIAAAAAAB8AHwwBAAAAKAAAAHkAbgBpAHIAQABjAGgAZQBjAGsAcABvAGkAbgB0AC4AYwBvAG0A AAAfAB4MAQAAAAoAAABTAE0AVABQAAAAAAACARkMAQAAAFwAAAAAAAAAgSsfpL6jEBmdbgDdAQ9U AgAAAIBZAG8AYQB2ACAATgBpAHIAAABTAE0AVABQAAAAeQBuAGkAcgBAAGMAaABlAGMAawBwAG8A aQBuAHQALgBjAG8AbQAAAAsAQDoBAAAAHwAaAAEAAAASAAAASQBQAE0ALgBOAG8AdABlAAAAAAAD APE/CQQAAAsAQDoBAAAAAwD9P+QEAAACAQswAQAAABAAAABHRosjdKZKSaN8ZX2gNsk8AwAXAAEA AABAADkAAGrs3QDXyQFAAAgwKycQ3gDXyQEDADYAAAAAAAIBRwABAAAANAAAAGM9dXM7YT0gO3A9 Q2hlY2sgUG9pbnQ7bD1JTC1FWDAxLTA5MDUxNzE1MDUwOFotMTg4MgAfAHAAAQAAAD4AAABRAHUA ZQBzAHQAaQBvAG4AIAByAGUAZwBhAHIAZABpAG4AZwAgAFYASQBEACAAcABhAHkAbABvAGEAZAAA AAAAAgFxAAEAAAAWAAAAAcnXAN4QlWD+XAtkRnicImnU+UJXkAAAHwA1EAEAAACOAAAAPAA5AEYA QgA3AEMANwBDAEUANwA5AEIAOAA0ADQANAA5AEIANQAyADYAMgAyAEIANQAwADYAQwA3ADgAMAAz ADYAMQAzADQAMQAxADQAQQA3AEIAMwBAAGkAbAAtAGUAeAAwADEALgBhAGQALgBjAGgAZQBjAGsA cABvAGkAbgB0AC4AYwBvAG0APgAAAAAACwDyEAEAAAAfAPMQAQAAAFIAAABSAGUAJQAzAEEAIABR AHUAZQBzAHQAaQBvAG4AIAByAGUAZwBhAHIAZABpAG4AZwAgAFYASQBEACAAcABhAHkAbABvAGEA ZAAuAEUATQBMAAAAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAABAAAcwvHb/3QDXyQEfAPg/AQAA ABIAAABZAG8AYQB2ACAATgBpAHIAAAAAAAIB+T8BAAAAXQAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1DSEVDSyBQT0lOVC9PVT1JTCBBRE1JTklTVFJBVElWRSBHUk9VUFMvQ049UkVD SVBJRU5UUy9DTj1ZTklSAAAAAB8A+j8BAAAAEgAAAFkAbwBhAHYAIABOAGkAcgAAAAAAAgH7PwEA AABdAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUNIRUNLIFBPSU5UL09VPUlMIEFE TUlOSVNUUkFUSVZFIEdST1VQUy9DTj1SRUNJUElFTlRTL0NOPVlOSVIAAAAAAwAZQAAAAAADABpA AAAAAAMADTT5PwAAAgEUNAEAAAAQAAAAVJShwCl/EBulhwgAKyolFx8APQABAAAACgAAAFIAZQA6 ACAAAAAAAB8ANwABAAAARgAAAFIAZQA6ACAAUQB1AGUAcwB0AGkAbwBuACAAcgBlAGcAYQByAGQA aQBuAGcAIABWAEkARAAgAHAAYQB5AGwAbwBhAGQAAAAAAB8AAICGAwIAAAAAAMAAAAAAAABGAQAA AB4AAABhAGMAYwBlAHAAdABsAGEAbgBnAHUAYQBnAGUAAAAAAAEAAAAMAAAAZQBuAC0AVQBTAAAA HwAAgIYDAgAAAAAAwAAAAAAAAEYBAAAAIAAAAHgALQBtAHMALQBoAGEAcwAtAGEAdAB0AGEAYwBo AAAAAQAAAAIAAAAAAAAAAwDeP+n9AABsOQ== --_000_9FB7C7CE79B84449B52622B506C78036134114A7B3ilex01adcheck_-- ------------=_1242572618-22294-1-- From ynir@checkpoint.com Sun May 17 08:32: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 357F128C169 for ; Sun, 17 May 2009 08:32:49 -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 5a9A5cI82mtC for ; Sun, 17 May 2009 08:32:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 05DB93A6E3D for ; Sun, 17 May 2009 08:32:44 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 80AE9200E10; Sun, 17 May 2009 18:34:18 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4071E200E00 for ; Sun, 17 May 2009 18:34:18 +0300 (IDT) X-CheckPoint: {4A102DAF-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 n4HFYHqO026663 for ; Sun, 17 May 2009 18:34:17 +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, 17 May 2009 18:34:17 +0300 From: Yoav Nir To: Yaron Sheffer , "ipsec@ietf.org" Date: Sun, 17 May 2009 18:34:16 +0300 Thread-Topic: Question regarding VID payload Thread-Index: AQHJ1vHHL6WeKHSWp0asl8mDdMUPUZAaStWwgAAPsoU= Message-ID: <9FB7C7CE79B84449B52622B506C78036134111302D@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036134111302A@il-ex01.ad.checkpoint.com>, <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584187@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5584187@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] Question regarding VID 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: Sun, 17 May 2009 15:32:49 -0000 OK. I won't use Evolution's MAPI plug-in any more... The section is addressed specifically to I-D writers.=20 All I-Ds that I've seen don't have text that says "use notification type XX= XXX until IANA assigns something else, and in the meantime, use Vendor ID e= 1b57aa457022526a6b4430bd2fa0101" I don't think it's even acceptable to have a VID in the I-D and then remove= it in AUTH48, nor can you get an IANA assignment before last call. I could= be wrong on this. Either we allow or even encourage text like the above (and this much editin= g in AUTH48), or else we shouldn't mandate this for document writers. Maybe= for implementors. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hi Yoav, If we don't require a VID, what's there to prevent a conflict between two vendors' private notifications, with the recipient misinterpreting the sender's notification? Note that we never required private notification numbers to be picked at random, so conflict are likely to occur. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Sunday, May 17, 2009 16:17 > To: ipsec@ietf.org > Subject: [IPsec] Question regarding VID payload > > Hi all > > I've just noticed that section 3.12 of the bis draft has the following > text: > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > that gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA, and the requirement to > use a Vendor ID will go away. > > This seems like a weird requirement, and in fact hasn't been in use so > far. Neither the individual extensions nor the extensions currently > created by this WG define any Vendor IDs. > > The more common procedure is to announce support for the extension using = a > notification (private at first and later from IANA) and not use any > VendorID at all. This is supported by section 3.10: "Notify payloads with > status types MAY be added to any message and MUST be ignored if not > recognized." > > How would people feel about demoting this MUST to a MAY ? > Email secured by Check Point > _______________________________________________ > 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 From martin@strongswan.org Mon May 18 01:12: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 2F3253A6A3F for ; Mon, 18 May 2009 01:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfCuf7ZiS5S1 for ; Mon, 18 May 2009 01:12:28 -0700 (PDT) Received: from zaes.ch (zaes.ch [213.133.111.41]) by core3.amsl.com (Postfix) with ESMTP id 3AE8E3A6C79 for ; Mon, 18 May 2009 01:12:28 -0700 (PDT) Received: from [152.96.15.212] by zaes.ch with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1M5y3j-0002zb-RR; Mon, 18 May 2009 10:18:55 +0200 From: Martin Willi To: Dan McDonald In-Reply-To: <20090515211814.GG1292@sun.com> References: <20090515211814.GG1292@sun.com> Content-Type: text/plain Date: Mon, 18 May 2009 10:13:55 +0200 Message-Id: <1242634435.4786.17.camel@martin.hsr.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-RPR-Rewrite: reverse-path rewritten by zaes.ch Cc: ipsec@ietf.org Subject: Re: [IPsec] Anyone have a 4868-compilant HMAC-SHA-{384, 512} for AH/ESP to test? 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, 18 May 2009 08:12:34 -0000 Hi Dan, > I'm discovering interoperability bugs between OpenSolaris and other platforms > in the SHA-2 space, mostly around SHA-384 and SHA-512. The Linux kernel implements an outdated truncation length for SHA256 only. But we successfully tested the SHA2 family against other vendors using this patch [1]. > Does anyone have an implementation that we can run some quick manually-keyed > tests against? Carol uses SHA256 in our blowfish test scenario [2]. Best regards, Martin [1]http://kerneltrap.org/mailarchive/linux-kernel/2008/6/5/2039114 [2]http://www.strongswan.org/uml/testresults43/openssl/alg-blowfish/ From kivinen@iki.fi Mon May 18 01:59: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 F1AF428C24C for ; Mon, 18 May 2009 01:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rHUZPJ6RnDj for ; Mon, 18 May 2009 01:59:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BD32728C16A for ; Mon, 18 May 2009 01:59:19 -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 n4I90ixV010392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2009 12:00:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4I90hBg002530; Mon, 18 May 2009 12:00:43 +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: <18961.9147.517601.464692@fireball.kivinen.iki.fi> Date: Mon, 18 May 2009 12:00:43 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@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: "ipsec@ietf.org" , Vijay Devarapalli Subject: Re: [IPsec] Redirect -09 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, 18 May 2009 08:59:21 -0000 Yaron Sheffer writes: > Regarding identity protection, I now realize I don't understand the relevant > paragraph. The text is: > > Redirecting based on the unauthenticated identities might leak out > information about the user when active attacker can get information > to which gateway user was redirected to. If redirection is based on > some internal information of the user, it might leak information to > attacker about the user which might not available otherwise. To > protect against this kind of attack the redirection based on the ID > should happen only after client has also authenticated himself. > > If the information leak you are worried about is simply the name/address of > the redirected-to gateway, Yes. > then this is available to a passive attacker as > well, by simply observing the client's next message. Not without client. I.e. this is to prevent probing attack. I.e. attacker gets employee list of email addresses for some company. He guesses that company uses email addresses as identities in IKEv2, and knows there is two GWs finance and development where all IKE connections will be redirected to when employee connects to the primary server. Attacker now simply makes IKEv2 connections to the primary server and claims to be user xxx@example.com, where xxx is the first email address of the list. If primary server does redirection before authenticating the client, the attacker will get information to which GW this specific user xxx@example.com was forwarded to, i.e. he knows whether xxx@example.com is part of the finance departement or part of the development departement. This allows attacker new information which was not available for him beforehand, and will leave no trace to the company, as those connections to primary server are just normal redirected connections, and primary server will never notice that none of those connections actually resulted new connection to be taken to that server where they were redirecteed to. This is leaking information and for some reason some companies are very keen on keeping such information private, and if the company is such then it needs to make sure it does redirection only on the last IKE_AUTH response. If company does not care about the issue, it can redirect during IKE_SA_INIT or during first IKE_AUTH message. > Or were you thinking > specifically of an attacker sitting next to the gateway? No. > Also note that the last sentence contradicts our choice to allow redirects > at the first IKE_AUTH response (for EAP). It does not contradict, it says that if you want to keep that information secret then you should not redirect during first IKE_AUTH (for EAP). If you do not care about that information then feel free to redirect at any time... -- kivinen@iki.fi From kivinen@iki.fi Mon May 18 02:13: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 EAD433A6C8A for ; Mon, 18 May 2009 02:13:50 -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 Ij57jyIZHw6W for ; Mon, 18 May 2009 02:13:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A98AB28C27B for ; Mon, 18 May 2009 02:13:48 -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 n4I9FLhF003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 May 2009 12:15:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4I9FLfH006627; Mon, 18 May 2009 12:15: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: <18961.10025.673428.152130@fireball.kivinen.iki.fi> Date: Mon, 18 May 2009 12:15:21 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C78036134111302A@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C78036134111302A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: "ipsec@ietf.org" Subject: [IPsec] Question regarding VID 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, 18 May 2009 09:13:51 -0000 Yoav Nir writes: > Hi all > > I've just noticed that section 3.12 of the bis draft has the following text: > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > that gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA, and the requirement to > use a Vendor ID will go away. > > This seems like a weird requirement, and in fact hasn't been in use > so far. Neither the individual extensions nor the extensions > currently created by this WG define any Vendor IDs. I haven't seen any extension which has been already in use on the net for IKEv2 yet. All the documents we define here in the WG do NOT usually require vendor ID as we do not have any numbers allocated to them yet (i.e. all numbers are "TBA by IANA"). The problem with IKEv1 was that there was vendor A making extension U, which allocated number X from registry F. This registry was IANA registry, but the vendor didn't officially register those numbers, but still put the numbers to the actual products. Then when WG decided to allocate same number X from the same registry we had overlapping numbers allocated from the same registry. For this we created the private use numbers. Use of private use numbers MUST include sending the vendor ID to indicate whose private numbers you are using, so if vendor A is using private number Y, and vendor B is using same private number Y for something else, the other end can know from vendor IDs which number space is used. > The more common procedure is to announce support for the extension > using a notification (private at first and later from IANA) and not > use any VendorID at all. This is supported by section 3.10: "Notify > payloads with status types MAY be added to any message and MUST be > ignored if not recognized." I do not think notification payloads are good for that as even those require registration, and private numbers notifications cannot really be used as they still need Vendor ID payload which tells whose private numebrs they are. Notification payloads are fine for final end result of the protocol, i.e they can be used to indicate support of certain extensions (i.e. MOBIKE_SUPPORTED etc). Notification payloads cannot be used during the development phase of the protocol, i.e. when someone wants take draft-ietf-ipsecme-ikev2-resumption-04 draft now and wants to put it out as a product, which means he needs to allocate the numbers TBA1-5 himself, as IANA will not allocate them before the draft goes forward. So if he picks private numbers for TBA1-5, and adds his own Vendor ID, and then he can use this "private" version of the extension even before it goes forward. I.e. Vendor ID is only required after the draft is in such state that it can be implemented, i.e. after the TBA values are written there, but before IANA has officially allocated them. > How would people feel about demoting this MUST to a MAY ? I think it MUST be kept as MUST. -- kivinen@iki.fi From yaronf@checkpoint.com Mon May 18 05:56: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 264473A694A for ; Mon, 18 May 2009 05:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 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 sfnvKUc20fc1 for ; Mon, 18 May 2009 05:56:36 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 543193A6FAF for ; Mon, 18 May 2009 05:56:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4C54430C001; Mon, 18 May 2009 15:58:10 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F1F86200DFB; Mon, 18 May 2009 15:58:09 +0300 (IDT) X-CheckPoint: {4A115A8F-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 n4ICw9qO009825; Mon, 18 May 2009 15:58:09 +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, 18 May 2009 15:58:08 +0300 From: Yaron Sheffer To: Tero Kivinen Date: Mon, 18 May 2009 15:58:05 +0300 Thread-Topic: [IPsec] Redirect -09 comments Thread-Index: AcnXlyX3HKqd9wwIQS2eDE4QYyPFygAIOk+w Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B55842E5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@il-ex01.ad.checkpoint.com> <18961.9147.517601.464692@fireball.kivinen.iki.fi> In-Reply-To: <18961.9147.517601.464692@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_0031_01C9D7D1.6E624340" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Vijay Devarapalli Subject: Re: [IPsec] Redirect -09 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, 18 May 2009 12:56:37 -0000 ------=_NextPart_000_0031_01C9D7D1.6E624340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, I find the attack laughable. But anyway, if it takes 5 paragraphs to explain this one paragraph, I guess better clarification is in order. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, May 18, 2009 12:01 > To: Yaron Sheffer > Cc: Vijay Devarapalli; ipsec@ietf.org > Subject: Re: [IPsec] Redirect -09 comments > > Yaron Sheffer writes: > > Regarding identity protection, I now realize I don't understand the > relevant > > paragraph. The text is: > > > > Redirecting based on the unauthenticated identities might leak out > > information about the user when active attacker can get information > > to which gateway user was redirected to. If redirection is based on > > some internal information of the user, it might leak information to > > attacker about the user which might not available otherwise. To > > protect against this kind of attack the redirection based on the ID > > should happen only after client has also authenticated himself. > > > > If the information leak you are worried about is simply the name/address > of > > the redirected-to gateway, > > Yes. > > > then this is available to a passive attacker as > > well, by simply observing the client's next message. > > Not without client. I.e. this is to prevent probing attack. > > I.e. attacker gets employee list of email addresses for some company. > He guesses that company uses email addresses as identities in IKEv2, > and knows there is two GWs finance and development where all IKE > connections will be redirected to when employee connects to the > primary server. > > Attacker now simply makes IKEv2 connections to the primary server and > claims to be user xxx@example.com, where xxx is the first email > address of the list. If primary server does redirection before > authenticating the client, the attacker will get information to which > GW this specific user xxx@example.com was forwarded to, i.e. he knows > whether xxx@example.com is part of the finance departement or part of > the development departement. > > This allows attacker new information which was not available for him > beforehand, and will leave no trace to the company, as those > connections to primary server are just normal redirected connections, > and primary server will never notice that none of those connections > actually resulted new connection to be taken to that server where they > were redirecteed to. > > This is leaking information and for some reason some companies are > very keen on keeping such information private, and if the company is > such then it needs to make sure it does redirection only on the last > IKE_AUTH response. > > If company does not care about the issue, it can redirect during > IKE_SA_INIT or during first IKE_AUTH message. > > > Or were you thinking > > specifically of an attacker sitting next to the gateway? > > No. > > > Also note that the last sentence contradicts our choice to allow > redirects > > at the first IKE_AUTH response (for EAP). > > It does not contradict, it says that if you want to keep that > information secret then you should not redirect during first IKE_AUTH > (for EAP). If you do not care about that information then feel free to > redirect at any time... > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0031_01C9D7D1.6E624340 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUxODEyNTgwNVowIwYJKoZIhvcNAQkEMRYEFCPG3h8P+bbp nEzyzdBLP2SVA4aVMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA NbcNxDXKkTP1/RzHWGK32oOxC66xRNPTcNeEMuVLLoFYoSSD36KRrJch2i2yu+ZhgD0NDljAaU2r yKEJF/x8drvtOu4hnB68cfWJO31Zn9NO1TPnhojY8xaIMBzHbBlWodI27R3ADlUm/bhc5bfKaokR iLXtZoGGAGZZWlphnLqQsUpOvwXVgBE41Mo7vtBOt8vgtMUdzqZeTABAfW0vo+FSljVF1+LnjjbS rvX9/kNYGt0lRDETd3+Y25O+WCycZvJfgpS3DD9cACvBufZDlV6dkACh3ZHOFYuL7LiXlrs1TIPU bGeI/DL837hEwj31wEwrwF/qvegC+OIq7KiYegAAAAAAAA== ------=_NextPart_000_0031_01C9D7D1.6E624340-- From Anil.Maguluri@lntinfotech.com Mon May 18 04:06: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 99FAE3A6CEC for ; Mon, 18 May 2009 04:06:43 -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 5cV3dikkwFrE for ; Mon, 18 May 2009 04:06:37 -0700 (PDT) Received: from mail142.messagelabs.com (mail142.messagelabs.com [216.82.249.99]) by core3.amsl.com (Postfix) with SMTP id C7BB83A6C74 for ; Mon, 18 May 2009 04:06:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Anil.Maguluri@lntinfotech.com X-Msg-Ref: server-10.tower-142.messagelabs.com!1242644873!77146212!1 X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 11555 invoked from network); 18 May 2009 11:07:54 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-10.tower-142.messagelabs.com with SMTP; 18 May 2009 11:07:54 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009051816395171-57945 ; Mon, 18 May 2009 16:39:51 +0530 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Anil Maguluri Date: Mon, 18 May 2009 16:37:52 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/18/2009 04:37:53 PM, Serialize complete at 05/18/2009 04:37:53 PM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/18/2009 04:39:51 PM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/18/2009 04:39:53 PM, Serialize complete at 05/18/2009 04:39:53 PM Content-Type: multipart/alternative; boundary="=_alternative 003D2549652575BA_=" X-Mailman-Approved-At: Mon, 18 May 2009 08:31:53 -0700 Cc: anilmaguluri@gmail.com Subject: [IPsec] Regarding the Linux IPsec Architecture 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, 18 May 2009 11:06:43 -0000 This is a multipart message in MIME format. --=_alternative 003D2549652575BA_= Content-Type: text/plain; charset="US-ASCII" Hi All, I am new to the IPsec. I am trying to understand the Linux IPsec architecture and current implementation. Please let me know any tutorial/doc is available for IPsec architecture in Linux. Thanks and Regards, Anil Kumar Maguluri ______________________________________________________________________ --=_alternative 003D2549652575BA_= Content-Type: text/html; charset="US-ASCII"
Hi All,

I am new to the IPsec. I am trying to understand the Linux IPsec architecture and
current implementation.

Please let me know any tutorial/doc is available for IPsec architecture in Linux.

Thanks and Regards,
Anil Kumar Maguluri


______________________________________________________________________
--=_alternative 003D2549652575BA_=-- From arno@natisbad.org Mon May 18 09:27: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 4B4F33A691E for ; Mon, 18 May 2009 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPEYTmAuc5dZ for ; Mon, 18 May 2009 09:27:15 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 227453A680F for ; Mon, 18 May 2009 09:27:15 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M65hk-0007Wi-3Q; Mon, 18 May 2009 18:28:44 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Anil Maguluri References: X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090518:ipsec@ietf.org::pkfki2N/WAvIPaXO:00029Dy X-Hashcash: 1:20:090518:anil.maguluri@lntinfotech.com::qmd8BVY1OURwz4NW:000000000000000000000000000000004McH X-Hashcash: 1:20:090518:anilmaguluri@gmail.com::AN1ESFfINORerrLP:0000000000000000000000000000000000000009GRs Date: Mon, 18 May 2009 18:29:21 +0200 Message-ID: <873ab2cr32.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ipsec@ietf.org, anilmaguluri@gmail.com Subject: Re: [IPsec] Regarding the Linux IPsec Architecture 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, 18 May 2009 16:27:16 -0000 Hi, Anil Maguluri writes: > I am new to the IPsec. I am trying to understand the Linux IPsec > architecture and current implementation. If you are not familiar with the theoretical aspects, you should start with RFC 4301 to get the big picture (concepts, vocabulary, ...). If you intend to spend time on dynamic keying (IKE), it may be worth looking at RFC 2367 too before (more to understand the sequence of events than anything else). > Please let me know any tutorial/doc is available for IPsec > architecture in Linux. Linux IPsec stack is implemented via Linux XFRM transformation framework (other main users are the routing cache and Mobile IPv6). There is not that much doc on the topic. The Linux kernel also provides two ways to communicate with the IPsec stack: via PF_KEY or via netlink (native access to XFRM). Anyway, You may find the following doc interesting before digging in the code: USAGI IPv6 IPsec Development for Linux : http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/SAINT2004_kanda-ipsec.pdf IPv6 IPsec and Mobile IPv6 implementation of Linux: http://ols.fedoraproject.org/OLS/Reprints-2006/miyazawa-reprint.pdf Linux IPv6 Networking: http://www.kernel.org/doc/ols/2003/ols2003-pages-507-523.pdf Linux IPv6 Stack Implementation Based on Serialized Data State Processing: http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/yoshifuji_Mar2004.pdf Side note: don't expect Linux IPsec stack to be fully in sync with what is in RFC 4301. It was developed before RFC 4301 was published. You may have to look at the old IPsec arch document: RFC 2401. Cheers, a+ From paulmoore100@hotmail.com Mon May 18 09: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 1FC5E28C2F5 for ; Mon, 18 May 2009 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_50=0.001, SARE_HEAD_XUNSENT=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU0Jj8gbNYBn for ; Mon, 18 May 2009 09:31:54 -0700 (PDT) Received: from bay0-omc2-s21.bay0.hotmail.com (bay0-omc2-s21.bay0.hotmail.com [65.54.246.157]) by core3.amsl.com (Postfix) with ESMTP id 79F2728C2CF for ; Mon, 18 May 2009 09:31:54 -0700 (PDT) Received: from BAY106-DS6 ([65.54.161.95]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 09:33:30 -0700 X-Originating-IP: [64.81.186.204] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "paul moore" In-Reply-To: To: References: X-Unsent: 1 Date: Mon, 18 May 2009 09:33:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 18 May 2009 16:33:30.0789 (UTC) FILETIME=[610B8D50:01C9D7D6] Subject: [IPsec] reposting question re IKEV1 IV 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, 18 May 2009 16:31:55 -0000 I asked this once and nobody answered - I will try again How should the IV be set for an informational message that is generated during phase 1? I see conflicting implementations and the V1 RFCs dont say (or at least dont say it clearly) Specific example is when doing a cert auth and the responder rejects the cert. The responder sends a informational notify to the initiator. What should the IV on that Inf N be? From vijay@wichorus.com Mon May 18 11:19: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 0BE413A6CAF for ; Mon, 18 May 2009 11:19:34 -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 RS7TZbyCG3mF for ; Mon, 18 May 2009 11:19:27 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id D12253A6A5A for ; Mon, 18 May 2009 11:19:26 -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: Mon, 18 May 2009 14:20:59 -0400 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect -09 comments Thread-Index: AcnUUQKW97cHVLC9RD6K6Gnsr2QH0ABU2GprADHjkGAAXjM/0A== References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B5583DFF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558402A@il-ex01.ad.checkpoint.com> From: "Vijay Devarapalli" To: "Yaron Sheffer" Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect -09 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, 18 May 2009 18:19:34 -0000 Hi Yaron, > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 > Sent: Saturday, May 16, 2009 2:37 PM > To: Vijay Devarapalli; ipsec@ietf.org > Subject: RE: [IPsec] Redirect -09 comments >=20 > Hi Vijay, >=20 > Regarding loop avoidance, please use RFC 2119, capitalized should's. Conversational English is ok sometimes. We don't always have to use SHOULDs and MUSTs. Using RFC 2119 terminology becomes important only if it affects interoperability between two nodes. In this particular case, we are talking about configuration on the client not to accept too many redirects within a short period of time. It should throw an exception which might require manual intervention. There is no need to use "SHOULD" or "MUST" here. FWIW, RFC 2460 (the main IPv6 specification) does not use "SHOULD" or "MUST" anywhere in the entire document. > Regarding identity protection, I now realize I don't=20 > understand the relevant > paragraph. The text is: >=20 > Redirecting based on the unauthenticated identities might leak out > information about the user when active attacker can get information > to which gateway user was redirected to. If redirection=20 > is based on > some internal information of the user, it might leak information to > attacker about the user which might not available otherwise. To > protect against this kind of attack the redirection based on the ID > should happen only after client has also authenticated himself. >=20 > If the information leak you are worried about is simply the=20 > name/address of > the redirected-to gateway, then this is available to a=20 > passive attacker as > well, by simply observing the client's next message. Or were=20 > you thinking > specifically of an attacker sitting next to the gateway?=20 I will let Tero respond to this. He had proposed this paragraph. I didn't see any harm in including text about this attack. Vijay >=20 > Also note that the last sentence contradicts our choice to=20 > allow redirects > at the first IKE_AUTH response (for EAP). >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > Sent: Saturday, May 16, 2009 0:31 > > To: Yaron Sheffer; ipsec@ietf.org > > Subject: Re: [IPsec] Redirect -09 comments > >=20 > > Hi Yaron, > >=20 > > On 5/13/09 10:01 PM, "Yaron Sheffer" wrote: > >=20 > > > Hi, > > > > > > While preparing to progress the draft to AD review, I=20 > reread it once > > again. > > > Here are a few comments. Although not all are nits, none=20 > of them should > > block > > > the document now. > > > > > > Thanks, > > > Yaron > > > > > > Not-quite-nits: > > > > > > General: a long way back we discussed loop avoidance, but=20 > this never > > made its > > > way into the draft. The document implicitly allows=20 > multiple redirections > > in > > > sequence. We should specify somewhere that the client MUST have a > > threshold > > > value X (possibly 1), where it is willing to redirect at=20 > most X times in > > > sequence. This is meant to deal with faulty=20 > configuration, not with > > active > > > attacks. > >=20 > > I added the following text to the Security Considerations section. > >=20 > > The client could end up getting redirected multiple times in a > > sequence, either because of wrong configuration or a DoS=20 > attack. The > > client could even end up in a loop with two or more gateways > > redirecting the client to each other. This could deny=20 > service to the > > client. To prevent this, the client should be configured not to > > accept more a certain number of redirects within a short time > > period. This should be configurable on the client. > >=20 > > Freel free to modify the text. > >=20 > > > 9. I believe the last sentence "To protect against this=20 > kind of attack > > the > > > redirection based on the ID should happen only after=20 > client has also > > > authenticated himself." should read "after the *gateway* has also > > > authenticated itself". > >=20 > > Hmm.. This is about revealing information about the user.=20 > So I don't see > > how > > this can be avoided if the gateway is authenticating itself. > >=20 > > > 10. Please add at the end of the section: A specification=20 > that extends > > this > > > registry MUST also define in which notification(s) the=20 > new values are > > allowed. > > > > > > Nits: > > > > > > 1. "connect to the IP address of the VPN gateways",=20 > change "gateways" to > > > "gateway". > > > > > > 3. "In practice, this means the new gateway either", remove one > > "either". > > > > > > 6. mesage -> message > > > > > > 6. "presented by the client in the first IKE_AUTH=20 > exchange itself." - > > this > > > text is duplicated. > >=20 > > Fixed all of the above. Thanks. > >=20 > > Vijay > >=20 > >=20 > > Scanned by Check Point Total Security Gateway. >=20 From Anil.Maguluri@lntinfotech.com Mon May 18 22:24: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 9D47B3A7091 for ; Mon, 18 May 2009 22:24:14 -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 jA8t2pMf+PsF for ; Mon, 18 May 2009 22:24:13 -0700 (PDT) Received: from mail96.messagelabs.com (mail96.messagelabs.com [216.82.254.19]) by core3.amsl.com (Postfix) with SMTP id B6E373A6838 for ; Mon, 18 May 2009 22:24:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Anil.Maguluri@lntinfotech.com X-Msg-Ref: server-2.tower-96.messagelabs.com!1242710722!55408855!1 X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 8441 invoked from network); 19 May 2009 05:25:23 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-2.tower-96.messagelabs.com with SMTP; 19 May 2009 05:25:23 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009051910571991-60691 ; Tue, 19 May 2009 10:57:19 +0530 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Anil Maguluri Date: Tue, 19 May 2009 10:55:19 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/19/2009 10:55:21 AM, Serialize complete at 05/19/2009 10:55:21 AM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/19/2009 10:57:19 AM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 05/19/2009 10:57:22 AM, Serialize complete at 05/19/2009 10:57:22 AM Content-Type: multipart/alternative; boundary="=_alternative 001DC8FB652575BB_=" Subject: [IPsec] IKEv2 Certificate Information 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, 19 May 2009 05:24:14 -0000 This is a multipart message in MIME format. --=_alternative 001DC8FB652575BB_= Content-Type: text/plain; charset="US-ASCII" Hi All, I would like to know what are the different certificates to support in IKEv2? Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message? If yes, please let me know the supported Certificates information and corresponding RFC numbers. Also please let me know IKEv2 opensource code which contains the certificates information. Thanks for your support. Regards, Anil Kumar Maguluri ______________________________________________________________________ --=_alternative 001DC8FB652575BB_= Content-Type: text/html; charset="US-ASCII"
Hi All,

I would like to know what are the different certificates to support in IKEv2?
Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message?
If yes, please let me know the supported Certificates information and corresponding
RFC numbers.

Also please let me know IKEv2 opensource code which contains the certificates
information.

Thanks for your support.

Regards,
Anil Kumar Maguluri
______________________________________________________________________
--=_alternative 001DC8FB652575BB_=-- From rsjenwar@gmail.com Mon May 18 22:56: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 E6A453A689F for ; Mon, 18 May 2009 22:56:40 -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 4VMqpyfxYA2d for ; Mon, 18 May 2009 22:56:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id DEB803A6CBB for ; Mon, 18 May 2009 22:56:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1528448rvb.49 for ; Mon, 18 May 2009 22:58: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=RvxXBpScMtsF9l+LhW7934PpcAIRoEtSOCU67OWlUYI=; b=rQX1qSPYtS4a+DStz+yMfZRW2YfHdTJGXAxrsnhxSehbi0Xf7eols4EcfqMMcV9da6 M0+yypsWb2ORpQmKVj+OxdBuk7t0xLBlPa78Nhj9mfv3BryIMH/hH95JxQ/TwnD4lbkH zNlHWeieF2jH5xgwhLYsMt3IeIHVNtTtGCyhs= 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=idb0KDUlGxvkoPpsSq+X9njBzJTWkVUusmp/QHvJdaKvLOvxKH18uE1tpmq5rAiQ+Y hVP32JwfRsKK7nEsP1ng9up4Yn7m2WMcDjfyJgTao4DW9eOuaCMES7DUYHfcxeAgGb/K E8/jJwWEKgBgRFVYrhUP72avuI7I1cBuJnxns= MIME-Version: 1.0 Received: by 10.142.58.20 with SMTP id g20mr2169797wfa.20.1242712694358; Mon, 18 May 2009 22:58:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 May 2009 11:28:14 +0530 Message-ID: <7ccecf670905182258j29a131d1k922d282a04733734@mail.gmail.com> From: Raj Singh To: Anil Maguluri Content-Type: multipart/alternative; boundary=001636e8ffd2b483a0046a3d9890 Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 Certificate Information 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, 19 May 2009 05:56:41 -0000 --001636e8ffd2b483a0046a3d9890 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Anil, Please find my reply inline. On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri < Anil.Maguluri@lntinfotech.com> wrote: > > Hi All, > > I would like to know what are the different certificates to support in > IKEv2? raj> The most commonly supported certificate forms are: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03 Section 3.6 ...... Certificate Encoding Value ---------------------------------------------------- *X.509 Certificate - Signature 4 * *Hash and URL of X.509 certificate 12* .... > Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message? raj> NO. > > If yes, please let me know the supported Certificates information and > corresponding > RFC numbers. > > Also please let me know IKEv2 opensource code which contains the > certificates > information. raj> StrongSwan and Racoon2 supports most of the features of IKEv2 http://www.strongswan.org/ http://www.racoon2.wide.ad.jp/w/ > Thanks for your support. > > Regards, > Anil Kumar Maguluri > ______________________________________________________________________ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Thanks, Raj --001636e8ffd2b483a0046a3d9890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Anil,

Please find my reply inline.

On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <<= a href=3D"mailto:Anil.Maguluri@lntinfotech.com">Anil.Maguluri@lntinfotech.c= om> wrote:

Hi All,

I would like to know what are th= e different certificates to support in IKEv2?
=C2=A0 raj> The most commonly supported certificate fo= rms are:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03
Sec= tion 3.6
......
Certificate Encoding                 Value=

      ----------------------------------------------------
            X.509 Certificate - Signature        4
      Hash an=
d URL of X.509 certificate    12

....

Is it mandatory to supp= ort CERT and CERTREQ payloads in IKE_AUTH message?
=C2=A0=C2=A0 raj> NO.

If yes, please let me know the supported Certificates information and corresponding
RFC numbers.

Also please let me know IKEv2 op= ensource code which contains the certificates
information.
=C2=A0=C2=A0 raj> StrongSwan and Racoon2 supports most= of the features of IKEv2
=C2=A0=C2=A0 http://www.strongswan.org/
=C2=A0=C2=A0 http://www.racoon2.wide.ad.jp/w/


Thanks for your support.

Regards,
Anil Kumar Maguluri
______________________________________________________________________

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

Thanks,
Raj
--001636e8ffd2b483a0046a3d9890-- From rsjenwar@gmail.com Mon May 18 23:36: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 D540F3A6778 for ; Mon, 18 May 2009 23:36:23 -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.019, 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 weQ048lK8y0T for ; Mon, 18 May 2009 23:36:22 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 3C8F228C0E3 for ; Mon, 18 May 2009 23:35:46 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so2038416wff.31 for ; Mon, 18 May 2009 23:37: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=sYv0+V7/HxyfwUDW2MyouR6tr1PzbvynAiurcShg7Pw=; b=ONaHknWpUYbnmXjvidrpgLrCBbUrtrnMK9i4eQybnjxfOdukJDTrZGYR7FlWnPsiCV zhCwQZBo0TEM76twmMWA0pNWmW1WBtZ9UcMEkw4+vMEwcPXLwp9tayR9ikke2+F65FBh +p2p0rFoMSomQL9Vb2m87Edg2vpkN4uyoh3cs= 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=UiCq5q1ap7rchN/JkgKa06b1S2XYk27IQS3ODJ+ZwH2Q0XGFTYq1qmv/xXyE0YdMXi uO8JyHo8hiDHIl7xytKTpWKI41PQnqSU35VrEtbX9O91ydH0o1dllWvQ2YH5Q9df+Sfn XgNXsKmjP3l4lhkTOP2/j9VzKYmWsIQ22Se6g= MIME-Version: 1.0 Received: by 10.143.13.16 with SMTP id q16mr2387420wfi.67.1242715040267; Mon, 18 May 2009 23:37:20 -0700 (PDT) In-Reply-To: References: <7ccecf670905182258j29a131d1k922d282a04733734@mail.gmail.com> Date: Tue, 19 May 2009 12:07:20 +0530 Message-ID: <7ccecf670905182337h59d19c9bt1db2876fd455bb89@mail.gmail.com> From: Raj Singh To: Anil Maguluri Content-Type: multipart/alternative; boundary=005045029ff8883f84046a3e24a5 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 Certificate Information 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, 19 May 2009 06:36:23 -0000 --005045029ff8883f84046a3e24a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Anil, X.509 is one authentication method like pre-shared keys for a peer to prove it's identity. So if CERT authentication method is configured in your IKEv2 policy, you know that you have send CERTREQ and generate AUTH payload based on your certificate. You can have just Pre-Shared Keys based authentication method to build VPN. Thanks, Raj On Tue, May 19, 2009 at 11:37 AM, Anil Maguluri < Anil.Maguluri@lntinfotech.com> wrote: > > Hi Raj, > > Thanks for your response. > > How IKEv2 will get the X.509 CERTIFICATE information (interface)? > is it mandatory to develop VPN based PKI system? > > Regards, > Anil Kumar Maguluri > > > > > *Raj Singh * > > 05/19/2009 11:28 AM > To > Anil Maguluri > cc > ipsec@ietf.org Subject > Re: [IPsec] IKEv2 Certificate Information > > > > > Hi Anil, > > Please find my reply inline. > > On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <* > Anil.Maguluri@lntinfotech.com* > wrote: > > Hi All, > > I would like to know what are the different certificates to support in > IKEv2? > raj> The most commonly supported certificate forms are:* > **http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03* > Section 3.6 > ...... > Certificate Encoding Value > ---------------------------------------------------- > > *X.509 Certificate - Signature 4* > *Hash and URL of X.509 certificate 12* > > .... > > > Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message? > raj> NO. > > If yes, please let me know the supported Certificates information and > corresponding > RFC numbers. > > Also please let me know IKEv2 opensource code which contains the > certificates > information. > raj> StrongSwan and Racoon2 supports most of the features of IKEv2 > *http://www.strongswan.org/* > *http://www.racoon2.wide.ad.jp/w/* > > > Thanks for your support. > > Regards, > Anil Kumar Maguluri > ______________________________________________________________________ > > _______________________________________________ > IPsec mailing list* > **IPsec@ietf.org* * > **https://www.ietf.org/mailman/listinfo/ipsec* > > Thanks, > Raj > > ______________________________________________________________________ > > ______________________________________________________________________ > --005045029ff8883f84046a3e24a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Anil,

X.509 is one authentication method like pre-shared keys for= a peer to prove it's identity.
So if CERT authentication method is = configured in your IKEv2 policy, you know that you have send CERTREQ and ge= nerate AUTH payload based on your certificate. You can have just Pre-Shared= Keys based authentication method to build VPN.

Thanks,
Raj

On Tue, May 19, 2009 a= t 11:37 AM, Anil Maguluri <Anil.Maguluri@lntinfotech.com> wrote:

Hi Raj,

Thanks for your response.

How IKEv2 will get the X.509 CER= TIFICATE information (interface)?
is it mandatory to develop VPN b= ased PKI system?

Regards,
Anil Kumar Maguluri




Raj Singh <<= a href=3D"mailto:rsjenwar@gmail.com" target=3D"_blank">rsjenwar@gmail.com>

05/19/2009 11:28 AM

To
Anil Magu= luri <Anil.Maguluri@lntinfotech.com>
cc
ipsec@ietf.org
Subject<= /div>
Re: [IPsec] IKEv2 Certifica= te Information





Hi Anil,

Please find my reply inline.
On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <Anil.Maguluri@lntinfotech.com> wrote:

Hi All,

I would like to know what are the different certificates to support in IKEv2?
=C2=A0 raj> The most commonly supported certificate forms are:
http://tools.iet= f.org/html/draft-ietf-ipsecme-ikev2bis-03 Section 3.6
......
Certificate Encoding =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Value
=C2=A0 =C2=A0 =C2=A0---------------------------------------------------- =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0X.509 Certificate - Signature =C2=A0 =C2=A0 =C2=A0 =C2=A04
=C2=A0 =C2=A0 =C2=A0Hash and URL of X.509 certificate =C2=A0 =C2=A01= 2

....
=C2=A0 =C2=A0 =C2=A0

Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message?
=C2=A0=C2=A0 raj> NO.

If yes, please let me know the supported Certificates information and corre= sponding
RFC numbers.

Also please let me know IKEv2 opensource code which contains the certificat= es
information.
=C2=A0=C2=A0 raj> StrongSwan and Racoon2 supports m= ost of the features of IKEv2
=C2=A0=C2=A0 http://www.strongswan.org/<= /a>
=C2=A0=C2=A0 http://www.racoon2.wide.ad.jp/w/=


Thanks for your support.

Regards,
Anil Kumar Maguluri
______________________________________________________________________

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

______________________________________________________________________

______________________________________________________________________

--005045029ff8883f84046a3e24a5-- From root@core3.amsl.com Tue May 19 15: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 5DB333A712B; Tue, 19 May 2009 15:00: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: <20090519220001.5DB333A712B@core3.amsl.com> Date: Tue, 19 May 2009 15:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-10.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, 19 May 2009 22: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-10.txt Pages : 14 Date : 2009-05-19 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-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-19145323.I-D@ietf.org> --NextPart-- From yaronf@checkpoint.com Tue May 19 21:59: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 B30A23A69EF for ; Tue, 19 May 2009 21:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 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 4epQLnpJ6OeT for ; Tue, 19 May 2009 21:59:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7F0FA3A68F6 for ; Tue, 19 May 2009 21:59:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8236129C001; Wed, 20 May 2009 08:01:23 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2C9B7200E00 for ; Wed, 20 May 2009 08:01:23 +0300 (IDT) X-CheckPoint: {4A138DC2-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 n4K51MqO005310 for ; Wed, 20 May 2009 08:01: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; Wed, 20 May 2009 08:01:22 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 20 May 2009 08:01:19 +0300 Thread-Topic: draft-ietf-ipsecme-ikev2-redirect-10 - PROTO write up Thread-Index: AcnYzrg9jCVi25A7Q3OuEgWjAu588wAOERCw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9B558452B@il-ex01.ad.checkpoint.com> References: <20090519220001.5DB333A712B@core3.amsl.com> In-Reply-To: <20090519220001.5DB333A712B@core3.amsl.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_00AD_01C9D921.28A749D0" MIME-Version: 1.0 Subject: [IPsec] draft-ietf-ipsecme-ikev2-redirect-10 - PROTO write up 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, 20 May 2009 04:59:49 -0000 ------=_NextPart_000_00AD_01C9D921.28A749D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I believe the document is ready for AD review. Below is the PROTO write up, comments are welcome. Thanks, Yaron Document name: Redirect Mechanism for IKEv2, draft-ietf-ipsecme-ikev2-redirect-10 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have reviewed it and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had in-depth review within the ipsecme WG. I am not aware of any non-WG reviews. I do not have any such concerns. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns, the document lies fully within the ipsecme WG's area of expertise. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no such concerns. There have been no IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is wide WG consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There have not been any such conflicts. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes, I have personally verified that. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No issues identified. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document defines a few new code points in existing registries, and one new IANA registry. There are no issues with any of them. I expect the Responsible AD to request the existing IKE/IPsec IANA expert to extend his services to the current draft. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines a redirect mechanism for IKEv2. The main use case is scalability of large deployments of remote access VPN gateways. The proposed mechanism can also be used in Mobile IPv6, where signaling is protected by IKE/IPsec, to support the home agent in redirecting the mobile node to another home agent. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document represents the consensus opinion of the ipsecme WG. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? We are not aware of any implementations. Neither do we know of relevant vendor plans. (end) ------=_NextPart_000_00AD_01C9D921.28A749D0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUyMDA1MDExOVowIwYJKoZIhvcNAQkEMRYEFPmsG+Oi1lty 4V6HDOnSJS16FsiyMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA dmrNPb61KFbIQSTEN8owdY3aIlVGY4gExszVyt4t6LidT6BxwCQCbMMBlxHJQpbd0uerkMU/Gy1e yWasNpZUY2EDrIiTvWwqPppygSGr6GGsAs80EEcp1ccmvO6uk/VQxAauFKbVbwLpRTB/SBoEmu5A MY6b2mGLNRGFxp8AzLb3cPbXJN84K4ZG606nQqwpfrHnKNeM0C5d5N+89NFYU9qe6MiytJkg+DIa rg7ewibSbEk1DHaIfBL0V3koHEbAPGn+0A3mrgPc2KU2TBcqwn4yLtqUjCzBHITvnv9+pV3e1l25 pDbE/PrhMLbjfuESyEILmDshvZA2h6X/CtbmaQAAAAAAAA== ------=_NextPart_000_00AD_01C9D921.28A749D0-- From qijun@txstate.edu Tue May 19 08:46: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 695833A68B9 for ; Tue, 19 May 2009 08:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeX6T+-0RBD1 for ; Tue, 19 May 2009 08:46:51 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 269D93A69C5 for ; Tue, 19 May 2009 08:46:51 -0700 (PDT) Received: (qmail 6681 invoked from network); 19 May 2009 15:41:48 -0000 Received: from unknown (HELO ?192.168.0.86?) (qijun@75.40.79.141 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 19 May 2009 15:41:47 -0000 X-YMail-OSG: Ivw1xkYVM1nfa3XJ6dYoFGVNgqN0w.xdEnw8.Dq.cPq8faCBRZXYhn4um1IUwgD1RGYavVkEKyYVnBBDTM07IE16wmJ9SY_KdvnvhWkvxSysWcOCCq_an3QYqI0ZuCD4jlvrK36sinlJ10Dgw2troeAzpP4XdEGLk7VEPbukc2HfnAEeSmffebacPYh4Sr6Gy05Y6MX1rEa3WC68oP3Y34JDweeJP0kFvm6zJE1V.CO.LJ83wsC_ePX___VIU.6PH88vAhodAnMSRUhd2K_XEdNwig6SZcwfhV.g_ruUXGxjVkku X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A12D339.3080205@txstate.edu> Date: Tue, 19 May 2009 10:41:45 -0500 From: Qijun Gu User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 May 2009 08:04:46 -0700 Subject: [IPsec] CFP : ICST International Workshop on Security in Emerging Wireless Communication and Networking Systems 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, 19 May 2009 15:46:51 -0000 Apologies if you have received this CFP. ===================== Call For Papers SEWCN 2009 : The First ICST International Workshop on Security in Emerging Wireless Communication and Networking Systems (http://www.cs.txstate.edu/~qg11/sewcn2009/) September 14, 2009, Athens, Greece In conjunction with SecureComm, 2009 *Sponsors Sponsored by ICST Technically co-sponsored by CREATE-NET *Scope Innovative wireless communication and networking systems have been proposed and studied in recent years, including cognitive radio networks, multi-channel multi-radio networks, cyber-physical systems, vehicle ad hoc networks, and others. The goal of this workshop is to develop and employ secure architectaures and protocols to enhance these emerging wireless systems. As these wireless systems have new features and serve new applications, they are raising new security concerns that existing security technologies may not be sufficient to tackle. Hence, these wireless systems require re-examination of current security techniques and creation of new security schemes. The design of these wireless systems also needs security as an integral part to prevent misuse of them and assure their functionality. This workshop particularly invites new ideas on security in the context of these emerging wireless communication and networking systems, including identifying new threats and new primitives for supporting secure system design. *Topics of Interest This workshop invites original technical papers that were not previously published and are not currently under review for publication elsewhere. Topics on security in emerging wireless systems include, but are not limited to the following: Vulnerabilities and threats Cross-layer design for security Security of cognitive radio Security of channel management Resilient control over network Secure neighbor and location discovery Key management Intrusion detection and response User and data privacy Anti-jamming communication Denial of service *Important Dates Submission deadline : July 1 Notification date : July 27 Camera ready submission : Aug 3 *Paper Submission and Publishing Papers should be prepared according to the LNICST format. The style template and instructions are available at http://www.springer.com/computer?SGWID=0-146-6-564009-0. Submitted papers should not exceed 9 pages in single column and should be in PDF format. All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors should not appear in the paper. Authours should submit papers to the EasyChair system at http://www.easychair.org/conferences/?conf=sewcn09. The proceeding of the workshop will be published with LNICST (Springer Lecture Notes of ICST) and distributed through an extensive global network of library consortia and appear on SpringerLink, one of the largest online scientific libraries, as well as the European Union Digital Library (EUDL), ICST's official digital library. *Workshop Chairs Qijun Gu, Texas State University-San Marcos, USA Wanyu Zang, Western Illinois University, USA Please direct any questions regarding the workshop to qijun@txstate.edu or W-Zang@wiu.edu -- -- Qijun Gu Assistant Professor Department of Computer Science Texas State University - San Marcos 601 University Dr, San Marcos, TX Phone: 512-245-3518 Fax: 512-245-8750 Web: www.cs.txstate.edu/~qg11/ From housley@vigilsec.com Wed May 20 11:31: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 80EC53A6EDD for ; Wed, 20 May 2009 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 5nvx-cSpzPPJ for ; Wed, 20 May 2009 11:31:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 9B3763A6A3E for ; Wed, 20 May 2009 11:31:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8AA8A9A4741; Wed, 20 May 2009 14:33:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id OQBfhj54biMq; Wed, 20 May 2009 14:32:53 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-96-255-70-130.washdc.fios.verizon.net [96.255.70.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E486A9A4736; Wed, 20 May 2009 14:33:00 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 May 2009 14:32:02 -0400 To: Scott C Moonen ,ipsec@ietf.org From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20090520183300.E486A9A4736@odin.smetech.net> Subject: Re: [IPsec] another RFC 4869 question 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, 20 May 2009 18:31:17 -0000 Scott:

RFC 4869 makes some statements like:

   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

That seems to me like an empty statement, since it doesn't require any particular set of choices nor does it proscribe any choice.

Pre-shared key involve a shared symmetric value.  ECDSA-256 involves a pubic-private key pair and a certificate.  Either one is acceptable for the Suite B environment.

Is it intended to proscribe the use of non-ECDSA digital signatures such as RSA, and therefore limit the options to pre-shared key and ECDSA-256?  I wonder if it should read "MUST" instead?

That is how I read it.

Russ
From ynir@checkpoint.com Thu May 21 06:56: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 D59163A6D48 for ; Thu, 21 May 2009 06:56:17 -0700 (PDT) X-Quarantine-ID: <4ysZqVig-rjr> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body 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 4ysZqVig-rjr for ; Thu, 21 May 2009 06:56:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 643613A6EFE for ; Thu, 21 May 2009 06:55:54 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 90B16200E48; Thu, 21 May 2009 16:57:21 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 41952200472; Thu, 21 May 2009 16:57:21 +0300 (IDT) X-CheckPoint: {4A155CD4-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 n4LDvKqO023667; Thu, 21 May 2009 16:57:20 +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, 21 May 2009 16:57:20 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Thu, 21 May 2009 17:00:46 +0300 Thread-Topic: I-D Action:draft-nir-ike-nochild-00.txt Thread-Index: AcnaEj0lSQtnBEc2R8iC0kkbt6q3wAACeOqQ Message-ID: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@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/mixed; boundary="_002_9FB7C7CE79B84449B52622B506C7803613410EDDE4ilex01adcheck_" MIME-Version: 1.0 Cc: Hui Deng Subject: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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, 21 May 2009 13:56:17 -0000 --_002_9FB7C7CE79B84449B52622B506C7803613410EDDE4ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Recently there's been some discussions about creating an IKE SA without chi= ld SAs (on purpose). I'm still not entirely convinced that this is necessary, but I have submitt= ed this draft, and would like to hear comments about it. Does it fill the = need that some people on this mailing list expressed? Thanks Yoav -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, May 21, 2009 3:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-nir-ike-nochild-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Childless Initiation of the IKE SA Author(s) : Y. Nir Filename : draft-nir-ike-nochild-00.txt Pages : 6 Date : 2009-05-21 This document describes an extension to the IKEv2 protocol that allows an I= KE SA to be created and authenticated without generating a child SA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =0D=0A Email secured by Check Point=0D=0A --_002_9FB7C7CE79B84449B52622B506C7803613410EDDE4ilex01adcheck_ Content-Type: message/external-body; name="draft-nir-ike-nochild-00.url" Content-Description: draft-nir-ike-nochild-00.url Content-Disposition: attachment; filename="draft-nir-ike-nochild-00.url"; size=89; creation-date="Thu, 21 May 2009 15:47:02 GMT"; modification-date="Thu, 21 May 2009 15:47:02 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1uaXItaWtlLW5vY2hpbGQtMDAudHh0DQo= --_002_9FB7C7CE79B84449B52622B506C7803613410EDDE4ilex01adcheck_-- From ynir@checkpoint.com Thu May 21 06:58: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 EEAE13A694A for ; Thu, 21 May 2009 06:58:52 -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 YuGRxzvmTJC4 for ; Thu, 21 May 2009 06:58:52 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 01CA83A63C9 for ; Thu, 21 May 2009 06:58:52 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 72E38200E48; Thu, 21 May 2009 17:00:09 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 26D80200472; Thu, 21 May 2009 17:00:09 +0300 (IDT) X-CheckPoint: {4A155D7B-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 n4LE08qO024638; Thu, 21 May 2009 17:00:08 +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, 21 May 2009 17:00:08 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Thu, 21 May 2009 17:03:33 +0300 Thread-Topic: I-D Action:draft-nir-ike-nochild-00.txt Thread-Index: AcnaEj0lSQtnBEc2R8iC0kkbt6q3wAACp1VA Message-ID: <9FB7C7CE79B84449B52622B506C7803613410EDDE6@il-ex01.ad.checkpoint.com> References: <20090521124501.DC3A33A6D5A@core3.amsl.com> In-Reply-To: <20090521124501.DC3A33A6D5A@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hui Deng Subject: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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, 21 May 2009 13:58:53 -0000 Hi all Recently there's been some discussions about creating an IKE SA without chi= ld SAs (on purpose). I'm still not entirely convinced that this is necessary, but I have submitt= ed this draft, and would like to hear comments about it. Does it fill the = need that some people on this mailing list expressed? Thanks Yoav=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, May 21, 2009 3:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-nochild-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : A Childless Initiation of the IKE SA > Author(s) : Y. Nir > Filename : draft-nir-ike-nochild-00.txt > Pages : 6 > Date : 2009-05-21 >=20 > This document describes an extension to the IKEv2 protocol=20 > that allows an IKE SA to be created and authenticated without=20 > generating a child SA. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ Email secured by Check Point From rsjenwar@gmail.com Thu May 21 11:42: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 C38023A6C83 for ; Thu, 21 May 2009 11:42:01 -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.016, 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 QZPoKAt+970o for ; Thu, 21 May 2009 11:42:00 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id AEE203A6BA9 for ; Thu, 21 May 2009 11:42:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so444785wff.31 for ; Thu, 21 May 2009 11:43:37 -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=6HaiPb95hkyDAx2P40P1NpBVqYHOpFFiI3kxC41hN8w=; b=AyGUpD6c3fAVHX+07AS4t67aYK7FzmyUUzWWWyi0U7CwJnZ3XXlPmtjrJ2+EDJmi2x 4nym10gCv6IuelB8x5ukcLT8d/+RJMi8eNObqsIe1tGG5eu1cQPSBHRC7FnGJfKLhzSY xb94r6s6+08IZ0itYQUyqq+j2sInAG4sKZaSo= 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=diHSRGYQ5yMz+TSY+zSVaTN4UlN8GGC9SzC5ypAvFVOPIEqTBPTuS0ROvQxV6pymjl V3Q9CSHwtHJFR4DRoJlsiw4bUuCdwgMzYH2Y0ghxK+47Ym5Q4QQH2yrEjyNkZVAwspWF MJ7OIZZeYEc5v1eUq9ene9miqb5ui3/6+ECC4= MIME-Version: 1.0 Received: by 10.142.81.7 with SMTP id e7mr1124891wfb.158.1242931417477; Thu, 21 May 2009 11:43:37 -0700 (PDT) In-Reply-To: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@il-ex01.ad.checkpoint.com> Date: Fri, 22 May 2009 00:13:37 +0530 Message-ID: <7ccecf670905211143k965d039u136a3eec59608bd5@mail.gmail.com> From: Raj Singh To: Yoav Nir Content-Type: multipart/alternative; boundary=001636e1fa8d9e7349046a708554 Cc: "ipsec@ietf.org" , Hui Deng Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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, 21 May 2009 18:42:01 -0000 --001636e1fa8d9e7349046a708554 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yoav, 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want to create child sa? 2. Also, please mention clearly in draft that what should be the behavior of responder if a faulty initiator sends modified IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD VID payload. 3. Also, why its a VID payload, Notify suits better. Because a third party client will want to connect to some other server. Please give justification for IKE_AUTH_NO_CHILD to be a VID. Thanks, Raj On Thu, May 21, 2009 at 7:30 PM, Yoav Nir wrote: > Hi all > > Recently there's been some discussions about creating an IKE SA without > child SAs (on purpose). > > I'm still not entirely convinced that this is necessary, but I have > submitted this draft, and would like to hear comments about it. Does it > fill the need that some people on this mailing list expressed? > > Thanks > > Yoav > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, May 21, 2009 3:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-nochild-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Childless Initiation of the IKE SA > Author(s) : Y. Nir > Filename : draft-nir-ike-nochild-00.txt > Pages : 6 > Date : 2009-05-21 > > This document describes an extension to the IKEv2 protocol that allows an > IKE SA to be created and authenticated without generating a child SA. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > > Email secured by Check Point > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001636e1fa8d9e7349046a708554 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when = we want to create child sa?
2. Also, please mention clearly in draft th= at what should be the behavior of responder if a faulty initiator sends mod= ified IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD VI= D payload.
3. Also, why its a VID payload, Notify suits better. Because a third party = client will want to connect to some other server. Please give justification= for IKE_AUTH_NO_CHILD to be a VID.

Thanks,
Raj

On Thu, May 21, 2009 at 7:30 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi all

Recently there's been some discussions about creating an IKE SA without= child SAs (on purpose).

I'm still not entirely convinced that this is necessary, but I have sub= mitted this draft, and would like to hear comments about it. =C2=A0Does it = fill the need that some people on this mailing list expressed?

Thanks

Yoav

-----Original Message-----
From: i-d-announce-bounces= @ietf.org [mailto:i-d-= announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Thursday, May 21, 2009 3:45 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-nir-ike-nochild-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A Ch= ildless Initiation of the IKE SA
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Y. Nir
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-nir= -ike-nochild-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2009-05-21

This document describes an extension to the IKEv2 protocol that allows an I= KE SA to be created and authenticated without generating a child SA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ike-nochi= ld-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/




Email secured by Check Point


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


--001636e1fa8d9e7349046a708554-- From wierbows@us.ibm.com Fri May 22 06:28: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 B3DF03A6B92 for ; Fri, 22 May 2009 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.716, 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 irm7tIBEpEpr for ; Fri, 22 May 2009 06:28:54 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id B1FB13A6B4E for ; Fri, 22 May 2009 06:28:54 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4MDP1QT013211 for ; Fri, 22 May 2009 09:25:01 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4MDUQV3250140 for ; Fri, 22 May 2009 09:30:26 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4MDUPi1020267 for ; Fri, 22 May 2009 09:30:25 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4MDUPDj020251 for ; Fri, 22 May 2009 09:30:25 -0400 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Fri, 22 May 2009 09:30:24 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/22/2009 09:30:25 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFF2DDFDA34078f9e8a93df938690918c0ABBFF2DDFDA3407" Content-Disposition: inline Subject: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 13:28:56 -0000 --0__=0ABBFF2DDFDA34078f9e8a93df938690918c0ABBFF2DDFDA3407 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for m= y peer to send me a certificate payload with a hash and URL encoding (i.e= . 12 or 13)? I do not see any language in RFC 4306 or 4945 that states the = peer MUST NOT send a certificate payload with a hash and URL encoding in thi= s case. Dave Wierbowski = --0__=0ABBFF2DDFDA34078f9e8a93df938690918c0ABBFF2DDFDA3407 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid fo= r my peer to send me a certificate payload with a hash and URL encoding= (i.e. 12 or 13)? I do not see any language in RFC 4306 or 4945 that s= tates the peer MUST NOT send a certificate payload with a hash and URL = encoding in this case.

Dave Wierbowski


= --0__=0ABBFF2DDFDA34078f9e8a93df938690918c0ABBFF2DDFDA3407-- From emre.gunduzhan@jhuapl.edu Fri May 22 07:09:53 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 6D5F53A6CE9 for ; Fri, 22 May 2009 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[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 hAVK1h2IIvWh for ; Fri, 22 May 2009 07:09:52 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id 3F99E3A6D31 for ; Fri, 22 May 2009 07:09:52 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.5119279; Fri, 22 May 2009 10:11:27 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 22 May 2009 10:11:27 -0400 From: "Gunduzhan, Emre" To: "ipsec@ietf.org" Date: Fri, 22 May 2009 10:11:26 -0400 Thread-Topic: Inconsistent usage of SA Thread-Index: Acna5zIK798UyRbbSF26A09ddlNtpg== Message-ID: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> 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_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_" MIME-Version: 1.0 Subject: [IPsec] Inconsistent usage of 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: Fri, 22 May 2009 14:11:15 -0000 --_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, I am new to this group, so I hope I am not raising an issue which was addre= ssed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came across = some inconsistent terminology which I believe also exists in RFC 4306. RFC 4301 defines a SA as a simplex "connection", and states that (section 4= .1): "To secure typical, bi-directional communication between two IPsec-enabled = systems, a pair of SAs (one in each direction) is required. IKE explicitly = creates SA pairs in recognition of this common usage requirement." However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2= bis, it seems that an SA can be used to carry traffic in both directions: " Suppose that host A has a policy whose effect is that traffic to 192.0.1.= 66 is sent via host B encrypted using AES, and traffic to all other hosts i= n 192.0.1.0/24 is also sent via B, but must use 3DES. Suppose also that ho= st B accepts any combination of AES and 3DES. If host A now proposes an SA that uses 3DES, and includes TSr containing (= 192.0.1.0-192.0.1.255), this will be accepted by host B. Now, host B can al= so use this SA to send traffic from 192.0.1.66, but those packets will be d= ropped by A since it requires the use of AES for those traffic. Even if ho= st A creates a new SA only for 192.0.1.66 that uses AES, host B may freely = continue to use the first SA for the traffic. In this situation, when prop= osing the SA, host A should have followed its own policy, and included a TS= r containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead." Because of the same issue, when RFC 4306 or draft-ietf-ipsecme-ikev2bis tal= ks about creating an IKE SA, this would imply that the IKE SA would be a si= mplex "connection". Similarly, it is not clear from RFC 4306 or draft-ietf-= ipsecme-ikev2bis whether a CREATE_CHILD_SA exchange (or, the initial IKE_AU= TH exchange) creates a single SA, i.e. a simplex "connection", or a pair of= SAs. Can someone please clarify which usage is correct? Would the workgroup cons= ider resolving this ambiguity in the revision to IKEv2? Thanks and best regards, Emre -- Emre Gunduzhan, Ph.D The Johns Hopkins University Applied Physics Laboratory Applied Information Sciences Department Communication and Networking Systems Group (VCS) --_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings,
 
I am new = to this=20 group, so I hope I am not raising an issue which was addressed earlier. I w= as=20 reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent=20 terminology which I believe also exists in RFC 4306.
 
RFC= 4301=20 defines a SA as a simplex "connection", and states that (section=20 4.1):
"To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each=20 direction) is required. IKE explicitly creates SA pai= rs in=20 recognition o= f this=20 common usage requirement."
 
However i= n=20 an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used t= o carry=20 traffic in both directions:
" Suppose that host = A has=20 a policy whose effect is that traffic to 192.0.1.66 is sent via host B= =20 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also= sent=20 via B, but must use 3DES.  Suppose also that host B accepts any combin= ation=20 of AES and 3DES.

 If host A now proposes an SA that uses 3DES, = and=20 includes TSr containing (192.0.1.0-192.0.1.255), this will be accepted= by=20 host B. Now, host B can also use this SA to send traffic from 192.0.1.66, b= ut=20 those packets will be dropped by A since it requires the use of AES for tho= se=20 traffic.  Even if host A creates a new SA only for 192.0.1.66 that use= s=20 AES, host B may freely continue to use the first SA for the traffic.  = In=20 this situation, when proposing the SA, host A should have followed its own= =20 policy, and included a TSr containing=20 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255))=20 instead."
 
Because of the same = issue, when=20 RFC 4306 or draft-ietf-ipsecme-ikev2bis talks about creating an IKE SA, thi= s=20 would imply that the IKE SA would be a simplex "connection". Similarly, it = is=20 not clear from RFC 4306 or draft-ietf-ipsecme-ikev2bis whether a CREATE_CHI= LD_SA=20 exchange (or, the initial IKE_AUTH exchange) creates a single SA, i.e. a si= mplex=20 "connection", or a pair of SAs.
 
Can someone pl= ease=20 clarify which usage is correct? Would the workgroup consider resolving this= =20 ambiguity in the revision to IKEv2?
 
Tha= nks and=20 best regards,
Emre
 
--
Emre=20 Gunduzhan, Ph.D
<= SPAN=20 lang=3Den-us>The Johns Hopkins University Applied= Physics=20 Laboratory
<= SPAN=20 lang=3Den-us>Applied Information Sciences=20 Department
Communication= and=20 Networking Systems Group (VCS)
 
 
 
--_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_-- From paul.hoffman@vpnc.org Fri May 22 08:23: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 0B03D3A7034 for ; Fri, 22 May 2009 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 vJOQFuZuN5Jl for ; Fri, 22 May 2009 08:23:34 -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 0F13F3A6EC7 for ; Fri, 22 May 2009 08:23:33 -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 n4MFP868011778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 08:25:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 22 May 2009 08:25:07 -0700 To: David Wierbowski , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 15:23:36 -0000 At 9:30 AM -0400 5/22/09, David Wierbowski wrote: >If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my peer to send me a certificate payload with a hash and URL encoding (i.e. 12 or 13)? I do not see any language in RFC 4306 or 4945 that states the peer MUST NOT send a certificate payload with a hash and URL encoding in this case. It is definitely valid to send those payloads regardless of the notify. --Paul Hoffman, Director --VPN Consortium From wierbows@us.ibm.com Fri May 22 08:50: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 416DA3A6E9F; Fri, 22 May 2009 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZvqeFRMH5b3; Fri, 22 May 2009 08:50:33 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 239FD3A6CF0; Fri, 22 May 2009 08:50:30 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4MFsWAn004896; Fri, 22 May 2009 11:54:32 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4MFq6A5200238; Fri, 22 May 2009 11:52:08 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4MFq5Zx023284; Fri, 22 May 2009 11:52:05 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4MFq52L023278; Fri, 22 May 2009 11:52:05 -0400 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Fri, 22 May 2009 11:52:03 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/22/2009 11:52:05 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 15:50:34 -0000 --0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: multipart/alternative; Boundary="1__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74" --1__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Why? Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = Paul Hoffman = = To Sent by: David = ipsec-bounces@iet Wierbowski/Endicott/IBM@IBMUS, = f.org ipsec@ietf.org = = cc = 05/22/2009 11:25 Subj= ect AM Re: [IPsec] = HTTP_CERT_LOOKUP_SUPPORTED quest= ion = = = = = = At 9:30 AM -0400 5/22/09, David Wierbowski wrote: >If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for = my peer to send me a certificate payload with a hash and URL encoding (i.e= . 12 or 13)? I do not see any language in RFC 4306 or 4945 that states the p= eer MUST NOT send a certificate payload with a hash and URL encoding in thi= s case. It is definitely valid to send those payloads regardless of the notify.= --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Why?



Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055



3D"InactivePaul Hoffman <paul.hoffman@vp= nc.org>


=
          Paul Hoffman <paul.hoffman@vpnc.org>
          Sent by: ipsec-bounces@ietf.org

          05/22/2009 11:25 AM

 =
3D=
To
3D""
David Wierbowski/Endicott/IBM@IBMUS, ipsec@ietf.org
3D=
cc
3D""
3D=
Subject
3D""
Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question=
3D=3D""

At 9:30 AM -0400 5/22/09, David Wierbowski wrote:
>If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid f= or my peer to send me a certificate payload with a hash and URL encodin= g (i.e. 12 or 13)? I do not see any language in RFC 4306 or 4945 that s= tates the peer MUST NOT send a certificate payload with a hash and URL = encoding in this case.

It is definitely valid to send those payloads regardless of the notify.=

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

= --1__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74-- --0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFF2DDFC55A748f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: image/gif; name="pic64530.gif" Content-Disposition: inline; filename="pic64530.gif" Content-ID: <2__=0ABBFF2DDFC55A748f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFF2DDFC55A748f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFF2DDFC55A748f9e8a93df938690918c0ABBFF2DDFC55A74-- From paul.hoffman@vpnc.org Fri May 22 08:56: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 CF0FE3A6C52; Fri, 22 May 2009 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 c5bVSFWCRCun; Fri, 22 May 2009 08:56:14 -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 E9D063A6A6D; Fri, 22 May 2009 08:55:55 -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 n4MFvUIl014232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 08:57:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 22 May 2009 08:57:29 -0700 To: David Wierbowski From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 15:56:14 -0000 At 11:52 AM -0400 5/22/09, David Wierbowski wrote: >Why? Because there is nothing in the document to indicate that it is invalid. HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306: Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. . . . HTTP_CERT_LOOKUP_SUPPORTED 16392 This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). Neither of those make it sound like it is required before sending type 12 or 13 certificates. --Paul Hoffman, Director --VPN Consortium From wierbows@us.ibm.com Fri May 22 09:06: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 012DD3A6B1B; Fri, 22 May 2009 09:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7ChEQXGRkWk; Fri, 22 May 2009 09:06:46 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 5245B3A6EA1; Fri, 22 May 2009 09:06:44 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4MG4FvU011927; Fri, 22 May 2009 12:04:15 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4MG8Mux209698; Fri, 22 May 2009 12:08:22 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n4MG8MsN008851; Fri, 22 May 2009 12:08:22 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n4MG8MZI008848; Fri, 22 May 2009 12:08:22 -0400 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Fri, 22 May 2009 12:08:20 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/22/2009 12:08:21 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 16:06:48 -0000 --0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: multipart/alternative; Boundary="1__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8" --1__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Paul, Thanks, but now I'm confused by an answer Tero provided to a slightly different question back in July of 2007 (subject [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to s= ee something that would disallow using those encoding types if you did not= receive the HTTP_CERT_LOOKUP_SUPPORTED. See below. > Since an implementation MUST be capable of being configured to send a= nd > accept the first two Hash and URL formats it's seems to follow that a= n > implementation also MUST support HTTP certificate lookup (making the > HTTP_CERT_LOOKUP_SUPPORTED notification extraneous). I believe the intent > is for HTTP certificate lookup support to be optional but a clarifica= tion > to that effect would be helpful. HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the other end is CONFIGURED to allow HTTP lookups for the certificates. > Assuming HTTP certificate lookup support is optional, how should an > implementation handle receipt of a CERT payload containing either of = the > Hash and URL formats (or any other unsupported encoding)? Presumably= the > implementation should ignore the certificate payload in this case. I= s > that correct? If you receive certificate payload you cannot process you can ignore it and try to see if you can still authenticate the other end. If you happen to have the certificate for the other end for some other reason (preconfiguration, cached by previous session etc) then you can authenticate the other end, if you do not have the certificate you will fail the authentication. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = Paul Hoffman = = To Sent by: David Wierbowski/Endicott/IBM@IB= MUS ipsec-bounces@iet = cc f.org ipsec@ietf.org, = ipsec-bounces@ietf.org = Subj= ect 05/22/2009 11:57 Re: [IPsec] = AM HTTP_CERT_LOOKUP_SUPPORTED quest= ion = = = = = = At 11:52 AM -0400 5/22/09, David Wierbowski wrote: >Why? Because there is nothing in the document to indicate that it is invalid= . HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306: Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. . . . HTTP_CERT_LOOKUP_SUPPORTED 16392 This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). Neither of those make it sound like it is required before sending type = 12 or 13 certificates. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Paul,

Thanks, but now I'm confused by an answer Tero provided to a slightly d= ifferent question back in July of 2007 (subject [Ipsec] Comments on dra= ft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to see = something that would disallow using those encoding types if you did not= receive the HTTP_CERT_LOOKUP_SUPPORTED. See below.

> Since an implementation MUST be capable of being configured to sen= d and
> accept the first two Hash and URL formats it's seems to follow tha= t an
> implementation also MUST support HTTP certificate lookup (making t= he
> HTTP_CERT_LOOKUP_SUPPORTED notification extraneous). I believe th= e intent
> is for HTTP certificate lookup support to be optional but a clarif= ication
> to that effect would be helpful.

HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the other end is CONFIGURED to allow HTTP lookups for the certificates.
=
> Assuming HTTP certificate lookup support is optional, how should a= n
> implementation handle receipt of a CERT payload containing either = of the
> Hash and URL formats (or any other unsupported encoding)? Presuma= bly the
> implementation should ignore the certificate payload in this case.= Is
> that correct?

If you receive certificate payload you cannot process you can ignore it and try to see if you can still authenticate the other end. If you happen to have the certificate for the other end for some other reason<= br> (preconfiguration, cached by previous session etc) then you can
authenticate the other end, if you do not have the certificate you
will fail the authentication.

Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055



3D"InactivePaul Hoffman <paul.hoffman@vp= nc.org>


=
          Paul Hoffman <paul.hoffman@vpnc.org>
          Sent by: ipsec-bounces@ietf.org

          05/22/2009 11:57 AM

 =
3D=
To
3D""
David Wierbowski/Endicott/IBM@IBMUS
3D=
cc
3D""
ipsec@ietf.org, ipsec-bounces@ietf.org
3D=
Subject
3D""
Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question=
3D=3D""

At 11:52 AM -0400 5/22/09, David Wierbowski wrote:
>Why?

Because there is nothing in the document to indicate that it is invalid= . HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306:

  Certificate payloads SHOULD be included in an exchange if
  certificates are available to the sender unless the peer has   indicated an ability to retrieve this information from elsewher= e
  using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

. . .

       HTTP_CERT_LOOKUP_SUPPORTED     &n= bsp;         16392

           This notification MAY be incl= uded in any message that can
           include a CERTREQ payload and= indicates that the sender is
           capable of looking up certifi= cates based on an HTTP-based
           URL (and hence presumably wou= ld prefer to receive
           certificate specifications in= that format).

Neither of those make it sound like it is required before sending type = 12 or 13 certificates.

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

= --1__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8-- --0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFF2DDFC459A88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: image/gif; name="pic51011.gif" Content-Disposition: inline; filename="pic51011.gif" Content-ID: <2__=0ABBFF2DDFC459A88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFF2DDFC459A88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFF2DDFC459A88f9e8a93df938690918c0ABBFF2DDFC459A8-- From paul.hoffman@vpnc.org Fri May 22 13:21: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 79BEA3A6B8D; Fri, 22 May 2009 13:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 9XLy0FUeXVWL; Fri, 22 May 2009 13:21:15 -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 DB2533A6812; Fri, 22 May 2009 13:20: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 n4MKMNAC033093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 13:22:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 22 May 2009 11:04:23 -0700 To: David Wierbowski From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 20:21:16 -0000 At 12:08 PM -0400 5/22/09, David Wierbowski wrote: >Paul, > >Thanks, but now I'm confused by an answer Tero provided to a slightly different question back in July of 2007 (subject [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to see something that would disallow using those encoding types if you did not receive the HTTP_CERT_LOOKUP_SUPPORTED. See below. I cannot speak for Tero. I can only say what is in the RFC and the current draft. Did either of the quotes I sent make it sound like one could not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received? At 5:05 PM +0300 7/19/07, Tero Kivinen wrote: >HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the >other end is CONFIGURED to allow HTTP lookups for the certificates. While that is true, a peer is not required to send it if that peer is configured to allow HTTP lookups. --Paul Hoffman, Director --VPN Consortium From wierbows@us.ibm.com Fri May 22 13:37: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 ABEF33A6B92; Fri, 22 May 2009 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-2.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aXgT5cuguLC; Fri, 22 May 2009 13:37:48 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 820693A6817; Fri, 22 May 2009 13:37:48 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n4MKRu61022306; Fri, 22 May 2009 16:27:56 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4MKdKOC257818; Fri, 22 May 2009 16:39:20 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n4MKdKgk008350; Fri, 22 May 2009 16:39:20 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n4MKdKjV008347; Fri, 22 May 2009 16:39:20 -0400 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Fri, 22 May 2009 16:39:18 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 05/22/2009 16:39:19 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 20:37:49 -0000 --0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: multipart/alternative; Boundary="1__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F" --1__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Did I say either of the quotes you sent make it sound like one could no= t sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received? I said I'm confused by Tero's previous answer which makes it sound as i= f such a restriction is implied. I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is that you= know when it is safe to use the hash and URL encoding, but it also allo= ws you to send the hash and URL encoding to a peer that may have disabled = that support via a configuration option. That doesn't seem like a good desi= gn to me, but it's certainly flexible :>). Dave Wierbowski = Paul Hoffman = = To Sent by: David Wierbowski/Endicott/IBM@IB= MUS ipsec-bounces@iet = cc f.org ipsec@ietf.org, = ipsec-bounces@ietf.org = Subj= ect 05/22/2009 02:04 Re: [IPsec] = PM HTTP_CERT_LOOKUP_SUPPORTED quest= ion = = = = = = At 12:08 PM -0400 5/22/09, David Wierbowski wrote: >Paul, > >Thanks, but now I'm confused by an answer Tero provided to a slightly different question back in July of 2007 (subject [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to se= e something that would disallow using those encoding types if you did not= receive the HTTP_CERT_LOOKUP_SUPPORTED. See below. I cannot speak for Tero. I can only say what is in the RFC and the curr= ent draft. Did either of the quotes I sent make it sound like one could not= sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received? At 5:05 PM +0300 7/19/07, Tero Kivinen wrote: >HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the >other end is CONFIGURED to allow HTTP lookups for the certificates. While that is true, a peer is not required to send it if that peer is configured to allow HTTP lookups. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Did I say either of the quotes you sent make it sound like one could= not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?<= br>
I said I'm confused by Tero's previous answer which makes it sound as i= f such a restriction is implied.

I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is that you= know when it is safe to use the hash and URL encoding, but it also all= ows you to send the hash and URL encoding to a peer that may have disab= led that support via a configuration option. That doesn't seem like a = good design to me, but it's certainly flexible :>).

Dave Wierbowski





3D"InactivePaul Hoffman <paul.hoffman@vp= nc.org>


=
          Paul Hoffman <paul.hoffman@vpnc.org>
          Sent by: ipsec-bounces@ietf.org

          05/22/2009 02:04 PM

 =
3D=
To
3D""
David Wierbowski/Endicott/IBM@IBMUS
3D=
cc
3D""
ipsec@ietf.org, ipsec-bounces@ietf.org
3D=
Subject
3D""
Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question=
3D=3D""

At 12:08 PM -0400 5/22/09, David Wierbowski wrote:
>Paul,
>
>Thanks, but now I'm confused by an answer Tero provided to a slight= ly different question back in July of 2007 (subject [Ipsec] Comments on= draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to s= ee something that would disallow using those encoding types if you did = not receive the HTTP_CERT_LOOKUP_SUPPORTED. See below.

I cannot speak for Tero. I can only say what is in the RFC and the curr= ent draft. Did either of the quotes I sent make it sound like one could= not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?<= br>
At 5:05 PM +0300 7/19/07, Tero Kivinen wrote:
>HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether t= he
>other end is CONFIGURED to allow HTTP lookups for the certificates.=

While that is true, a peer is not required to send it if that peer is c= onfigured to allow HTTP lookups.

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

= --1__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F-- --0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFF2DDFE33E9F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: image/gif; name="pic53431.gif" Content-Disposition: inline; filename="pic53431.gif" Content-ID: <2__=0ABBFF2DDFE33E9F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBFF2DDFE33E9F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFF2DDFE33E9F8f9e8a93df938690918c0ABBFF2DDFE33E9F-- From paul.hoffman@vpnc.org Fri May 22 15:46: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 29F033A6E2A for ; Fri, 22 May 2009 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 GY5VcX+FxjTR for ; Fri, 22 May 2009 15:46:14 -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 56D913A6A79 for ; Fri, 22 May 2009 15:46:05 -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 n4MMlfAO042897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 15:47:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 22 May 2009 15:47:39 -0700 To: David Wierbowski From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question 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, 22 May 2009 22:46:15 -0000 At 4:39 PM -0400 5/22/09, David Wierbowski wrote: >Did I say either of the quotes you sent make it sound like one could not sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received? Sorry, I took it as implied. >I said I'm confused by Tero's previous answer which makes it sound as if such a restriction is implied. I actually don't even take that from Tero's response, but he wasn't clear either way. >I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is that you know when it is safe to use the hash and URL encoding Yep. >, but it also allows you to send the hash and URL encoding to a peer that may have disabled that support via a configuration option. Yep. > That doesn't seem like a good design to me, but it's certainly flexible :>). Much of IKEv1 and IKEv2 are not "good design" because of too much flexibility, but the alternative is being too restrictives for many environments. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun May 24 03:07: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 CEC433A6F68 for ; Sun, 24 May 2009 03:07:17 -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 CsUgq0GKCGPL for ; Sun, 24 May 2009 03:07:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 82DBA3A6F07 for ; Sun, 24 May 2009 03:07:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 30F4A29C002; Sun, 24 May 2009 13:08:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0029E29C001; Sun, 24 May 2009 13:08:55 +0300 (IDT) X-CheckPoint: {4A191BB3-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 n4OA8sn6023447; Sun, 24 May 2009 13:08:54 +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, 24 May 2009 13:09:01 +0300 From: Yoav Nir To: Raj Singh Date: Sun, 24 May 2009 13:08:12 +0300 Thread-Topic: [IPsec] FW: I-D Action:draft-nir-ike-nochild-00.txt Thread-Index: AcnaRA+W/QutGJK1RtaCuBiQ0CyuJgCE3wQU Message-ID: <006FEB08D9C6444AB014105C9AEB133FE76A543E@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@il-ex01.ad.checkpoint.com>, <7ccecf670905211143k965d039u136a3eec59608bd5@mail.gmail.com> In-Reply-To: <7ccecf670905211143k965d039u136a3eec59608bd5@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 Cc: "ipsec@ietf.org" , Hui Deng Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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: Sun, 24 May 2009 10:07:17 -0000 Hi Raj =20 On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote: > Hi Yoav, >=20 > 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want=20 > to create child sa? =20 =20 We don't. That comes from (note careful enough) cut-and-paste. Good catch.= =20 =20 > 2. Also, please mention clearly in draft that what should be the=20 > behavior of responder if a faulty initiator sends modified=20 > IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD=20 > VID payload.=20 =20 There can be two reasons why a certain implementation has not sent the VID: 1. The responder does not support this extension. In that case, I can't spe= cify any behavior for it, and it should send an INVALID_SYNTAX. 2. It does support this extension, but the administrator has deliberately t= urned it off. In that case, I think the responder should respond exactly as= if it didn't support the extension at all, and reply with an INVALID_SYNTA= X. I'll add a line to the draft saying this explicitly. =20 > 3. Also, why its a VID payload, Notify suits better. Because a third=20 > party client will want to connect to some other server. Please give=20 > justification for IKE_AUTH_NO_CHILD to be a VID. Section 3.12 of -bis document says "A Vendor ID payload MAY announce that t= he sender is capable of accepting certain extensions to this protcol..." Using a VID has one advantage over a Notify, in that you don't need IANA to= allocate a value. With a Notify, I would not be able to get a number from = IANA until the document was ready for publication which can take over a yea= r. Implementations that want to support this would need to use a temporary = private use notify type, and then protect it with a VID payload (which woul= d not be interoperable, because every vendor would choose a different value= and VID). After the document is published, a new version of the product ca= n use a IANA-assigned notify type, but because different products are out t= here, you need to support for a long time the old private-use type with its= VID. =20 Doing it all with VID is simpler and allows continuity between draft and RF= C implementations. In IKEv1 it was common to use VIDs to indicate support f= or an externsion. See for example, RFC 3947.= Email secured by Check Point From rsjenwar@gmail.com Sun May 24 20:07: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 7A7603A6AA8 for ; Sun, 24 May 2009 20:07: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.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 XUdEKD0Lqkco for ; Sun, 24 May 2009 20:07:10 -0700 (PDT) Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by core3.amsl.com (Postfix) with ESMTP id 77A593A6A51 for ; Sun, 24 May 2009 20:07:10 -0700 (PDT) Received: by pzk10 with SMTP id 10so1859623pzk.29 for ; Sun, 24 May 2009 20:08:49 -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=76apVi5wew2L0R2Bv4P0gUE39gFS9+ZApiL1KEPkoUQ=; b=vMZD7jj5wRJqDAKguVVMkQYgCe0CSWjrymEHbr4FPa1MxYruVaH6TU9hPPHoMnt07A NVqqp1C7zP9VOQDlfhfKjxaNNcDb8T1+Tr2ST7w/i7zkKJ8UzgT6IDydLzQDNGnsqJka TD/k6wdXejeAPgkvDhqM/10PeSqHRV0PU0HF0= 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=D+bG36ACXTNjwkwF8d4Z8CLeePESykURaqCoze6SI5H807tu38/hI+5kO6SaMNfsE/ sljPlIdhZxChia6+CS1pOCzdRoGnY7llUZuBqtxjUEBUipTqK61mkEvH54uLL0XOZSTP jYazO7UZxRk+C1D86yldtFvHQ1vl/7A4aqq8M= MIME-Version: 1.0 Received: by 10.142.144.16 with SMTP id r16mr2144885wfd.349.1243220929179; Sun, 24 May 2009 20:08:49 -0700 (PDT) In-Reply-To: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> References: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> Date: Mon, 25 May 2009 08:38:49 +0530 Message-ID: <7ccecf670905242008k7d8744a3h59a6110dc3d693cc@mail.gmail.com> From: Raj Singh To: "Gunduzhan, Emre" Content-Type: multipart/alternative; boundary=000e0cd32746dc71a6046ab3edf0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Inconsistent usage of 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, 25 May 2009 03:07:17 -0000 --000e0cd32746dc71a6046ab3edf0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Emre, IKE SA is bi-directional i.e. one SA is used in both directions, initiator to responder and responder to initiator. CHILD_SAs i.e. IPsec SAs (AH, ESP) are uni-directional, one in each direction. So we 2 IPsec SAs per connection. Thanks, Raj On Fri, May 22, 2009 at 7:41 PM, Gunduzhan, Emre wrote: > Greetings, > > I am new to this group, so I hope I am not raising an issue which was > addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came > across some inconsistent terminology which I believe also exists in RFC > 4306. > > RFC 4301 defines a SA as a simplex "connection", and states that (section > 4.1): > "To secure typical, bi-directional communication between two IPsec-enabled > systems, a pair of SAs (one in each direction) is required. IKE explicitly > creates SA pairs in recognition of this common usage requirement." > > However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2bis, > it seems that an SA can be used to carry traffic in both directions: > " Suppose that host A has a policy whose effect is that traffic to > 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other > hosts in 192.0.1.0/24 is also sent via B, but must use 3DES. Suppose also > that host B accepts any combination of AES and 3DES. > > If host A now proposes an SA that uses 3DES, and includes TSr containing > (192.0.1.0-192.0.1.255), this will be accepted by host B. Now, host B can > also use this SA to send traffic from 192.0.1.66, but those packets will be > dropped by A since it requires the use of AES for those traffic. Even if > host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely > continue to use the first SA for the traffic. In this situation, when > proposing the SA, host A should have followed its own policy, and included a > TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead." > > Because of the same issue, when RFC 4306 or draft-ietf-ipsecme-ikev2bis > talks about creating an IKE SA, this would imply that the IKE SA would be a > simplex "connection". Similarly, it is not clear from RFC 4306 or > draft-ietf-ipsecme-ikev2bis whether a CREATE_CHILD_SA exchange (or, the > initial IKE_AUTH exchange) creates a single SA, i.e. a simplex "connection", > or a pair of SAs. > > Can someone please clarify which usage is correct? Would the workgroup > consider resolving this ambiguity in the revision to IKEv2? > > Thanks and best regards, > Emre > > -- > Emre Gunduzhan, Ph.D > The Johns Hopkins University Applied Physics Laboratory > Applied Information Sciences Department > Communication and Networking Systems Group (VCS) > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --000e0cd32746dc71a6046ab3edf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Emre,

IKE SA is bi-directional i.e. one SA is used in both direct= ions, initiator to responder and responder to initiator.
CHILD_SAs i.e. = IPsec SAs (AH, ESP) are uni-directional, one in each direction. So we 2 IPs= ec SAs per connection.

Thanks,
Raj

On Fri, May 22, 2009 a= t 7:41 PM, Gunduzhan, Emre <Emre.Gunduzhan@jhuapl.edu> wrote:
Greetings,
=C2=A0
I am new to this=20 group, so I hope I am not raising an issue which was addressed earlier. I w= as=20 reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent=20 terminology which I believe also exists in RFC 4306.
=C2=A0
RFC 4301=20 defines a SA as a simplex "connection", and states that (section= =20 4.1):
"To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each=20 direction) is required. IKE explicitly creates SA p= airs in=20 recogni= tion of this=20 common usage requirement."
=C2=A0
However=C2=A0in=20 an=C2=A0example scenario in section 2.9.1 of=C2=A0draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry=20 traffic in both directions:
" Suppose that host A has=20 a=C2=A0policy whose effect is that traffic to 192.0.1.66 is sent via host B= =20 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also sent=20 via B, but must use 3DES.=C2=A0 Suppose also that host B accepts any combin= ation=20 of AES and 3DES.

=C2=A0If host A now proposes an SA that uses 3DES, = and=20 includes TSr=C2=A0containing (192.0.1.0-192.0.1.255), this will be accepted= by=20 host B. Now, host B can also use this SA to send traffic from 192.0.1.66, b= ut=20 those packets will be dropped by A since it requires the use of AES for tho= se=20 traffic.=C2=A0 Even if host A creates a new SA only for 192.0.1.66 that use= s=20 AES, host B may freely continue to use the first SA for the traffic.=C2=A0 = In=20 this situation, when proposing the SA, host A should have followed its own= =20 policy, and included a TSr containing=20 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255))=20 instead."
=C2=A0
Because of the same issue, when=20 RFC 4306 or draft-ietf-ipsecme-ikev2bis talks about creating an IKE SA, thi= s=20 would imply that the IKE SA would be a simplex "connection". Simi= larly, it is=20 not clear from RFC 4306 or draft-ietf-ipsecme-ikev2bis whether a CREATE_CHI= LD_SA=20 exchange (or, the initial IKE_AUTH exchange) creates a single SA, i.e. a si= mplex=20 "connection", or a pair of SAs.
=C2=A0
<= span>Can someone please=20 clarify which usage is correct? Would the workgroup consider resolving this= =20 ambiguity in the revision to IKEv2?
=C2= =A0
Thanks and=20 best regards,
Emre<= /div>
=C2=A0
--
Emre=20 Gunduzhan, Ph.D
The Johns Hopkins University Applied Physics=20 Laboratory
Applied Information Sciences=20 Department
Commu= nication and=20 Networking Systems Group (VCS)
=C2=A0
=C2=A0
=C2=A0

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


--000e0cd32746dc71a6046ab3edf0-- From rsjenwar@gmail.com Sun May 24 20:22: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 1BC573A6CC8 for ; Sun, 24 May 2009 20:22:11 -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 bsMmBy+VIXMK for ; Sun, 24 May 2009 20:22:10 -0700 (PDT) Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by core3.amsl.com (Postfix) with ESMTP id F1B0A3A6C8A for ; Sun, 24 May 2009 20:22:09 -0700 (PDT) Received: by pzk10 with SMTP id 10so1864028pzk.29 for ; Sun, 24 May 2009 20:23:49 -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=7nQZMLwt6h30MI8ofMir1HPKuCSHyEwDgc+qNw2mhL4=; b=fp5YwsRR+fO29TbQBwhaSZhLUl+IkBp1FhOOVouY7N546PNwXQXLAlbLBRxIkjheyK KBKGV+eVwChM1SS/XG7mgRdDfuAbOhFirC+QR9Vr8MIRzQVoi62vrxRcpVV5pliNz/ED UF+CV2UfeagS/ocfhe2DYLERcHYO0Dk11pxkc= 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=p6zlU/pqqh/wqXySYlAGKtkP0F1N5NgfGzGFbifQvEKrndDv5TYEBFDZD3iyXrDKfJ rywEWVotvExDkvduzf2UlKAkXCBMOn9/RsxinWp0OGSNAxaXsNXM8xLg6P34VP27n8qt UCtQ4VGITsgFGAGsBw2SRSSNBNMZyIfWHJpc4= MIME-Version: 1.0 Received: by 10.142.14.18 with SMTP id 18mr2102463wfn.304.1243221828961; Sun, 24 May 2009 20:23:48 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FE76A543E@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@il-ex01.ad.checkpoint.com> <7ccecf670905211143k965d039u136a3eec59608bd5@mail.gmail.com> <006FEB08D9C6444AB014105C9AEB133FE76A543E@il-ex01.ad.checkpoint.com> Date: Mon, 25 May 2009 08:53:48 +0530 Message-ID: <7ccecf670905242023iabe103dh97ab39c88c957082@mail.gmail.com> From: Raj Singh To: Yoav Nir Content-Type: multipart/alternative; boundary=000e0cd1776a7e0848046ab4237a Cc: "ipsec@ietf.org" , Hui Deng Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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: Mon, 25 May 2009 03:22:11 -0000 --000e0cd1776a7e0848046ab4237a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yoav, On Sun, May 24, 2009 at 3:38 PM, Yoav Nir wrote: > Hi Raj > > On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote: > > Hi Yoav, > > > > 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want > > to create child sa? > > We don't. That comes from (note careful enough) cut-and-paste. Good catch. > > > 2. Also, please mention clearly in draft that what should be the > > behavior of responder if a faulty initiator sends modified > > IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD > > VID payload. > > There can be two reasons why a certain implementation has not sent the VID: > 1. The responder does not support this extension. In that case, I can't > specify any behavior for it, and it should send an INVALID_SYNTAX. > 2. It does support this extension, but the administrator has deliberately > turned it off. In that case, I think the responder should respond exactly as > if it didn't support the extension at all, and reply with an INVALID_SYNTAX. > I'll add a line to the draft saying this explicitly. > > > 3. Also, why its a VID payload, Notify suits better. Because a third > > party client will want to connect to some other server. Please give > > justification for IKE_AUTH_NO_CHILD to be a VID. > > Section 3.12 of -bis document says "A Vendor ID payload MAY announce that > the sender is capable of accepting certain extensions to this protcol..." > Using a VID has one advantage over a Notify, in that you don't need IANA to > allocate a value. With a Notify, I would not be able to get a number from > IANA until the document was ready for publication which can take over a > year. Implementations that want to support this would need to use a > temporary private use notify type, and then protect it with a VID payload > (which would not be interoperable, because every vendor would choose a > different value and VID). After the document is published, a new version of > the product can use a IANA-assigned notify type, but because different > products are out there, you need to support for a long time the old > private-use type with its VID. > Doing it all with VID is simpler and allows continuity between draft and > RFC implementations. In IKEv1 it was common to use VIDs to indicate support > for an externsion. See for example, RFC 3947. > Email secured by Check Point > If we think we are going to allow IKE_AUTH without CHILD SA, i feel notification of IKE_AUTH_NO_CHILD_SA type will be better because VIDs are limited to proprietary use and if any implementation want to support this extension for their products, it can choose a VALUE value for this notification and can update to a new value when IANA assigns it. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good example of it. Thanks, Raj --000e0cd1776a7e0848046ab4237a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

On Sun, May 24, 2009 at 3:38 PM,= Yoav Nir <ynir= @checkpoint.com> wrote:
Hi Raj

On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote:
> Hi Yoav,
>
> 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want
> to create child sa?

We don't. That comes from (note careful enough) cut-and-paste. = =C2=A0Good catch.

> 2. Also, please mention clearly in draft that what should be the
> behavior of responder if a faulty initiator sends modified
> IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD
> VID payload.

There can be two reasons why a certain implementation has not sent th= e VID:
1. The responder does not support this extension. In that case, I can't= specify any behavior for it, and it should send an INVALID_SYNTAX.
2. It does support this extension, but the administrator has deliberately t= urned it off. In that case, I think the responder should respond exactly as= if it didn't support the extension at all, and reply with an INVALID_S= YNTAX. I'll add a line to the draft saying this explicitly.

> 3. Also, why its a VID payload, Notify suits better. Because a third > party client will want to connect to some other server. Please give > justification for IKE_AUTH_NO_CHILD to be a VID.

Section 3.12 of -bis document says "A Vendor ID payload MAY anno= unce that the sender is capable of accepting certain extensions to this pro= tcol..."
Using a VID has one advantage over a Notify, in that you don't need IAN= A to allocate a value. With a Notify, I would not be able to get a number f= rom IANA until the document was ready for publication which can take over a= year. Implementations that want to support this would need to use a tempor= ary private use notify type, and then protect it with a VID payload (which = would not be interoperable, because every vendor would choose a different v= alue and VID). After the document is published, a new version of the produc= t can use a IANA-assigned notify type, but because different products are o= ut there, you need to support for a long time the old private-use type with= its VID.
Doing it all with VID is simpler and allows continuity between draft and RF= C implementations. In IKEv1 it was common to use VIDs to indicate support f= or an externsion. See for example, RFC 3947.
Email secured by Check Point
<= /blockquote>
If we think we are going to allow IKE_AUTH without CHILD S= A, i feel notification of=C2=A0 IKE_AUTH_NO_CHILD_SA type will be better be= cause VIDs are limited to proprietary use and if any implementation want to= support this extension for their products, it can choose a VALUE value for= =C2=A0 this notification and can update to a new value when IANA assigns it= .
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is goo= d example of it.

Thanks,
Raj

--000e0cd1776a7e0848046ab4237a-- From ynir@checkpoint.com Mon May 25 00:26:33 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 F3E633A68DC for ; Mon, 25 May 2009 00:26:32 -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.036, 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 Ig-w6k9qYtFq for ; Mon, 25 May 2009 00:26:32 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 933013A68D5 for ; Mon, 25 May 2009 00:26:31 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0C51829C005; Mon, 25 May 2009 10:28:12 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B4BE329C001; Mon, 25 May 2009 10:28:11 +0300 (IDT) X-CheckPoint: {4A1A477B-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 n4P7SAn6027170; Mon, 25 May 2009 10:28:10 +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, 25 May 2009 10:28:10 +0300 From: Yoav Nir To: Raj Singh Date: Mon, 25 May 2009 10:28:08 +0300 Thread-Topic: [IPsec] FW: I-D Action:draft-nir-ike-nochild-00.txt Thread-Index: Acnc6D14+J/Q91YBSzmLFRUJSslOZgAHi83g Message-ID: <006FEB08D9C6444AB014105C9AEB133FE76A0CFE@il-ex01.ad.checkpoint.com> References: <9FB7C7CE79B84449B52622B506C7803613410EDDE4@il-ex01.ad.checkpoint.com> <7ccecf670905211143k965d039u136a3eec59608bd5@mail.gmail.com> <006FEB08D9C6444AB014105C9AEB133FE76A543E@il-ex01.ad.checkpoint.com> <7ccecf670905242023iabe103dh97ab39c88c957082@mail.gmail.com> In-Reply-To: <7ccecf670905242023iabe103dh97ab39c88c957082@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_006FEB08D9C6444AB014105C9AEB133FE76A0CFEilex01adcheckpo_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Hui Deng Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-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: Mon, 25 May 2009 07:26:33 -0000 --_000_006FEB08D9C6444AB014105C9AEB133FE76A0CFEilex01adcheckpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj > 3. Also, why its a VID payload, Notify suits better. Because a third > party client will want to connect to some other server. Please give > justification for IKE_AUTH_NO_CHILD to be a VID. Section 3.12 of -bis document says "A Vendor ID payload MAY announce that t= he sender is capable of accepting certain extensions to this protcol..." Using a VID has one advantage over a Notify, in that you don't need IANA to= allocate a value. With a Notify, I would not be able to get a number from = IANA until the document was ready for publication which can take over a yea= r. Implementations that want to support this would need to use a temporary = private use notify type, and then protect it with a VID payload (which woul= d not be interoperable, because every vendor would choose a different value= and VID). After the document is published, a new version of the product ca= n use a IANA-assigned notify type, but because different products are out t= here, you need to support for a long time the old private-use type with its= VID. Doing it all with VID is simpler and allows continuity between draft and RF= C implementations. In IKEv1 it was common to use VIDs to indicate support f= or an externsion. See for example, RFC 3947. Email secured by Check Point If we think we are going to allow IKE_AUTH without CHILD SA, i feel notific= ation of IKE_AUTH_NO_CHILD_SA type will be better because VIDs are limited= to proprietary use and if any implementation want to support this extensio= n for their products, it can choose a VALUE value for this notification an= d can update to a new value when IANA assigns it. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good exa= mple of it. Thanks, Raj I don't see why VIDs are limited to proprietary use, and implementations do= n't get updated fast enough to allow them to just "switch" to the new IANA-= assigned value. The example of RFC 3947 is illuminating. The drafts had a different VID val= ue then the RFC. Microsoft implemented the draft version (from draft-02 IIR= C) and all gateways that support L2TP clients still must support both the d= raft VID and the RFC VID. While we might rely on vendors updating their im= plementations, we can't rely on customers to do so. =0D=0A Email secured by Check Point=0D=0A --_000_006FEB08D9C6444AB014105C9AEB133FE76A0CFEilex01adcheckpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Raj

>= ; 3. Also,=20 why its a VID payload, Notify suits better. Because a third
> party= =20 client will want to connect to some other server. Please give
>=20 justification for IKE_AUTH_NO_CHILD to be a VID.

Section 3.12 of -bis document says "A Vendor ID paylo= ad=20 MAY announce that the sender is capable of accepting certain extensions= to=20 this protcol..."
Using a VID has one advantage over a Notify, in tha= t you=20 don't need IANA to allocate a value. With a Notify, I would not be able= to=20 get a number from IANA until the document was ready for publication whi= ch=20 can take over a year. Implementations that want to support this would n= eed=20 to use a temporary private use notify type, and then protect it with a = VID=20 payload (which would not be interoperable, because every vendor would c= hoose=20 a different value and VID). After the document is published, a new vers= ion=20 of the product can use a IANA-assigned notify type, but because differe= nt=20 products are out there, you need to support for a long time the old=20 private-use type with its VID.
Doing it all with VID is simpler and= =20 allows continuity between draft and RFC implementations. In IKEv1 it wa= s=20 common to use VIDs to indicate support for an externsion. See for examp= le,=20 RFC 3947.
Email secured by Check Point
If we think we are going to allow IKE_AUTH without CHILD SA, i feel= =20 notification of  IKE_AUTH_NO_CHILD_SA type will be better because VI= Ds=20 are limited to proprietary use and if any implementation want to support = this=20 extension for their products, it can choose a VALUE value for  this= =20 notification and can update to a new value when IANA assigns it.
= http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10=20 is good example of it.

Thanks,
Raj
I=20 don't see why VIDs are limited to proprietary use, and implementations don'= t get=20 updated fast enough to allow them to just "switch" to the new IANA-assigned= =20 value.
 
The=20 example of RFC 3947 is illuminating. The drafts had a different VID va= lue=20 then the RFC. Microsoft implemented the draft version (from draft-02 I= IRC)=20 and all gateways that support L2TP clients still must support both the draf= t VID=20 and the RFC VID.  While we might rely on vendors updating their=20 implementations, we can't rely on customers to do so.
 
 

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

= --_000_006FEB08D9C6444AB014105C9AEB133FE76A0CFEilex01adcheckpo_-- From kent@bbn.com Mon May 25 08:20: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 576D43A6C37 for ; Mon, 25 May 2009 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 gOQRRSx7lrht for ; Mon, 25 May 2009 08:20:40 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 70BF23A67F4 for ; Mon, 25 May 2009 08:20:40 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[168.77.196.182]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M8c0K-00019T-Ea; Mon, 25 May 2009 11:22:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> References: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> Date: Sun, 24 May 2009 21:37:35 -0400 To: "Gunduzhan, Emre" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-968857556==_ma============" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Inconsistent usage of 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, 25 May 2009 15:20:47 -0000 --============_-968857556==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > > boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_" > >Greetings, > >I am new to this group, so I hope I am not raising an issue which >was addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, >and I came across some inconsistent terminology which I believe also >exists in RFC 4306. > >RFC 4301 defines a SA as a simplex "connection", and states that >(section 4.1): >"To secure typical, bi-directional communication between two >IPsec-enabled systems, a pair of SAs (one in each direction) is >required. IKE explicitly creates SA pairs in recognition of this >common usage requirement." > >However in an example scenario in section 2.9.1 >of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to >carry traffic in both directions: >" Suppose that host A has a policy whose effect is that traffic to >192.0.1.66 is sent via host B encrypted using AES, and traffic to >all other hosts in 192.0.1.0/24 is also sent via B, but must use >3DES. Suppose also that host B accepts any combination of AES and >3DES. > 4301 is correct. Sometimes folks refer to the pair of SAs that IKE always creates as an SA, but that is not the correct terminology. Steve --============_-968857556==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] Inconsistent usage of SA
At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_"
Greetings,
 
I am new to this group, so I hope I am not raising an issue which was addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent terminology which I believe also exists in RFC 4306.
 
RFC 4301 defines a SA as a simplex "connection", and states that (section 4.1):
"To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement."
 
However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry traffic in both directions:
" Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but must use 3DES.  Suppose also that host B accepts any combination of AES and 3DES.

4301 is correct. Sometimes folks refer to the pair of SAs that IKE always creates as an SA, but that is not the correct terminology.

Steve
--============_-968857556==_ma============-- From paul.hoffman@vpnc.org Mon May 25 19:19: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 047493A7057 for ; Mon, 25 May 2009 19:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 gKY6cxZrn2dj for ; Mon, 25 May 2009 19:19:42 -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 D8C3D3A7051 for ; Mon, 25 May 2009 19:19:41 -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 n4Q2LKJD081488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 May 2009 19:21:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090515163001.6D4AB28C106@core3.amsl.com> Date: Mon, 25 May 2009 19:21:18 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.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, 26 May 2009 02:19:43 -0000 [[ Just a nudge. It would be great to hear from folks who have read this document before the end of this week. If you are active in the WG but haven't read the document, please do: it's not that long. --Paul ]] At 1:06 PM -0700 5/15/09, Paul Hoffman wrote: >Greetings again. There has been almost no discussion on the -03 draft, and Yaron has made some small changes in the -04. As we discussed at the interim WG meeting, we would like to advance this before Stockholm. > >Therefore, this is the beginning of the two-week WG Last Call, which will end May 29. The current document is at . > >Even if you have not read the document before now, please do so. Having fresh eyes on the document often brings up important issues. Send any comments to the list, even if they are as simple as "I read it and it seems fine". We would like to gauge how much support there is or isn't for this protocol. > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --Paul Hoffman, Director --VPN Consortium From mcins1@gmail.com Mon May 25 23:42: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 A10FC3A6CCF for ; Mon, 25 May 2009 23:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 Mgev3xvrDuPr for ; Mon, 25 May 2009 23:42:14 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id A215328C18D for ; Mon, 25 May 2009 23:42:14 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so2667759qwe.31 for ; Mon, 25 May 2009 23:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=Yihda0ocqN22T8Mv4ZAewC5VQKo2V3a/W1r7x4bnRfA=; b=ARTHun7iitjq+aqJqBa6vGxQn02kAO7fBqbD1k9xKQK1uOW3qYaiU8Zl2ixLm4wl+K QGlNJnZJ9qlV5ypGMhcCyez5jOiI5vVNlez34Ju/igTR5rRQVNOR9sc8WC6cK+tmwYFh UTtAguL5CmVj2zb/DUE7eOqQhc93x+NrzLnpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=qV7ByOcmfwa15AhNSbdF4t1Y4dhKVwZuoOQazXQQj8B0A1kS2o31WAY6oeXslpAUhw HD4Q63riUzK2cFXkmmNBT+k8sUgEtu42kNdETk9Q/D9luK+/2rdgt/h30qQ7dgTMUigt yngheA7LtzdF4wsNQXzrFDPc2ffQKPyDn6eTc= MIME-Version: 1.0 Received: by 10.220.90.3 with SMTP id g3mr5844769vcm.80.1243320232126; Mon, 25 May 2009 23:43:52 -0700 (PDT) From: Matthew Cini Sarreo Date: Tue, 26 May 2009 08:43:32 +0200 Message-ID: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016e645fa8ac730ec046acb0cad Subject: [IPsec] IKEv2: RADIUS 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, 26 May 2009 06:42:20 -0000 --0016e645fa8ac730ec046acb0cad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello All, My apologies if this has already been asked. We are interested to have our implementation of IKEv2 to provide support for authentication with a RADIUS server. We did this in IKEv1 by implementing XAuth. For IKEv2, the only resource that seems to tackle this is http://www.employees.org/~ddukes/ikev2_cp_dhcp_radius_ietf56.pdf, which seems quite old. Is this still valid to use? Thanks & Regards, Matt --0016e645fa8ac730ec046acb0cad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,

My apologies if this has already been asked.

We ar= e interested to have our implementation of IKEv2 to provide support for aut= hentication with a RADIUS server. We did this in IKEv1 by implementing XAut= h. For IKEv2, the only resource that seems to tackle this is http://www.e= mployees.org/~ddukes/ikev2_cp_dhcp_radius_ietf56.pdf, which seems quite= old. Is this still valid to use?

Thanks & Regards,
Matt
--0016e645fa8ac730ec046acb0cad-- From Pasi.Eronen@nokia.com Tue May 26 01:16: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 4E2FF3A6A0B for ; Tue, 26 May 2009 01:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Mc8LcHoAp1Lb for ; Tue, 26 May 2009 01:16:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A04663A7055 for ; Tue, 26 May 2009 01:16:08 -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 n4Q8GhFE030612 for ; Tue, 26 May 2009 03:17:30 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 11:17:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 11:17:22 +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, 26 May 2009 10:17:11 +0200 From: To: Date: Tue, 26 May 2009 10:17:09 +0200 Thread-Topic: Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQ== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6ADCDFBE@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: 26 May 2009 08:17:22.0264 (UTC) FILETIME=[64ED1D80:01C9DDDA] X-Nokia-AV: Clean Subject: [IPsec] Final comments for ikev2-redirect-10 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, 26 May 2009 08:16:25 -0000 FYI: Tim will be the responsible AD for this draft (since I was listed as a co-author in an earlier version); he will hopefully do his AD evaluation soon (and might consider these as IETF Last Call comments). There's one remaining issue that was changed due to WGLC comments, but the result isn't quite what it IMHO should be. When doing redirection during IKE_AUTH, in some situations the IKE_AUTH response with the REDIRECT is the last message between the client and gateway (and the IKE_SA is not used, and cannot be used, for any other exchanges after that). In other situations, it *is* used for (at least) one additional exchange (Informational exchange with DELETE payload). When the Informational exchange is needed/allowed and when not is not totally random, but I don't expect that any readers would understand it (I do know Tero can explain it :-). It also creates room=20 for confusion whether the REDIRECT is just a "hint" and the IKE_SA=20 could still be used for other exchanges, too. I would suggest we get rid of this unnecessary complexity, and simply say that when you do REDIRECT during IKE_AUTH, no more exchanges are done (on that IKE_SA) after the REDIRECT is sent. There's also one place that is probably correct, but would=20 benefit from some clarification. Section 5 says:=20 "When the client receives this message, it MUST send an empty message as an acknowledgement. Until the client responds with an acknowledgement, the gateway SHOULD re-transmit the redirect INFORMATIONAL message as described in [2]." The MUST and SHOULD here give the impression that this Informational exchange is somehow special, and treated differently from ordinary Informational exchanges. As far as I can tell, it's *not* meant to be special, and this text isn't meant to specify any new requirements. I'd suggest rephrasing this something like "As in any other INFORMATIONAL exchange, the clients sends a response (usually empty), and the gateway retransmits the request if it doesn't receive a response." BTW, in Section 10, "expert review" probably should be "Expert Review as specified in [RFC5226]". Best regards, Pasi From andreas.steffen@strongswan.org Tue May 26 02:04: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 085B83A7029 for ; Tue, 26 May 2009 02:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2uFr3qckehM for ; Tue, 26 May 2009 02:04:48 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id E79603A6BA2 for ; Tue, 26 May 2009 02:04:47 -0700 (PDT) Received: from [152.96.15.205] (unknown [152.96.15.205]) by strongswan.org (Postfix) with ESMTP id 81DA6EF973; Tue, 26 May 2009 11:06:26 +0200 (CEST) Message-ID: <4A1BB112.3010403@strongswan.org> Date: Tue, 26 May 2009 11:06:26 +0200 From: Andreas Steffen Organization: Linux strongSwan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Matthew Cini Sarreo References: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> In-Reply-To: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2: RADIUS 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, 26 May 2009 09:04:49 -0000 Hi Matt, IKEv2 allows any EAP protocol to be used for VPN client authentication. Examples are EAP-SIM, EAP-AKA, EAP-MSCHAPv2, EAP-MD5, EAP-GTC, etc. On the VPN gateway you can just forward the EAP messages to a RADIUS server. The following sample scenario shows a strongSwan client doing IKEv2 EAP-SIM authentication with a strongSwan gateway forwarding the EAP messages to a FreeRADIUS server. http://www.strongswan.org/uml/testresults43/ikev2/rw-eap-sim-id-radius/ Here is another scenario for IKEv2 EAP-MD5 without EAP Identity: http://www.strongswan.org/uml/testresults43/ikev2/rw-eap-md5-radius/ Best regards Andreas Matthew Cini Sarreo wrote: > Hello All, > > My apologies if this has already been asked. > > We are interested to have our implementation of IKEv2 to provide support > for authentication with a RADIUS server. We did this in IKEv1 by > implementing XAuth. For IKEv2, the only resource that seems to tackle > this is > http://www.employees.org/~ddukes/ikev2_cp_dhcp_radius_ietf56.pdf, which > seems quite old. Is this still valid to use? > > Thanks & Regards, > Matt ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From emre.gunduzhan@jhuapl.edu Tue May 26 06:07: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 E89653A6B1D for ; Tue, 26 May 2009 06:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXrUMpZnq48G for ; Tue, 26 May 2009 06:07:02 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by core3.amsl.com (Postfix) with ESMTP id D5B9E3A70D0 for ; Tue, 26 May 2009 06:07:01 -0700 (PDT) Received: from ([128.244.198.90]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.5619915; Tue, 26 May 2009 09:08:40 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 26 May 2009 09:08:41 -0400 From: "Gunduzhan, Emre" To: "ipsec@ietf.org" Date: Tue, 26 May 2009 09:08:40 -0400 Thread-Topic: [IPsec] Inconsistent usage of SA Thread-Index: AcndTJouPRBoIb9bTBmORZeZ+Z5+qAAtMecw Message-ID: <068F06DC4D106941B297C0C5F9F446EA3CB241D43F@aplesstripe.dom1.jhuapl.edu> References: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> 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_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_" MIME-Version: 1.0 Subject: Re: [IPsec] Inconsistent usage of 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, 26 May 2009 13:07:03 -0000 --_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, Thanks for the clarification. So, at the end of the initial IKE_AUTH exchan= ge, there will (typically) be a pair of CHILD SAs created, one in each dire= ction, is this correct? That is, you never create a single SA by IKE_AUTH o= r CREATE_CHILD_SA, and create another SA in the other direction by a subseq= uent CREATE_CHILD_SA? This is really ambiguous in RFC 4306 (at least to me) and would be great if= it can be clarified in the revised version. Thanks, Emre ________________________________ From: Stephen Kent [mailto:kent@bbn.com] Sent: Sunday, May 24, 2009 9:38 PM To: Gunduzhan, Emre Cc: ipsec@ietf.org Subject: Re: [IPsec] Inconsistent usage of SA At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary=3D"_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripe= do_" Greetings, I am new to this group, so I hope I am not raising an issue which was addre= ssed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came across = some inconsistent terminology which I believe also exists in RFC 4306. RFC 4301 defines a SA as a simplex "connection", and states that (section 4= .1): "To secure typical, bi-directional communication between two IPsec-enabled = systems, a pair of SAs (one in each direction) is required. IKE explicitly = creates SA pairs in recognition of this common usage requirement." However in an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev2= bis, it seems that an SA can be used to carry traffic in both directions: " Suppose that host A has a policy whose effect is that traffic to 192.0.1.= 66 is sent via host B encrypted using AES, and traffic to all other hosts i= n 192.0.1.0/24 is also sent via B, but must use 3DES. Suppose also that ho= st B accepts any combination of AES and 3DES. 4301 is correct. Sometimes folks refer to the pair of SAs that IKE always c= reates as an SA, but that is not the correct terminology. Steve --_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [IPsec] Inconsistent usage of SA
Steve,
 
Thanks for the clarification. So, at the end of = the=20 initial IKE_AUTH exchange, there will (typically) be a pair of CH= ILD=20 SAs created, one in each direction, is this correct? That is, you never cre= ate a=20 single SA by IKE_AUTH or CREATE_CHILD_SA, and create another SA in the othe= r=20 direction by a subsequent CREATE_CHILD_SA?
 
This is really ambiguous in RFC 4306 (at least t= o me)=20 and would be great if it can be clarified in the revised=20 version.
 
Thanks,
= Emre<= /DIV>

&nbs= p;
 
 
 From: Stephen Kent= =20 [mailto:kent@bbn.com]
Sent: Sunday, May 24, 2009 9:38=20 PM
To: Gunduzhan, Emre
Cc: ipsec@ietf.org
Subject= :=20 Re: [IPsec] Inconsistent usage of SA

At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type= :=20 multipart/alternative;
    =20 boundary=3D"_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203apless= tripedo_"
Greetings,
 
I am new t= o this=20 group, so I hope I am not raising an issue which was addressed earlier. I= was=20 reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent= =20 terminology which I believe also exists in RFC 4306.
 
RFC 4301 d= efines a SA=20 as a simplex "connection", and states that (section 4.1):
"To secure= typical,=20 bi-directional communication between two IPsec-enabled systems, a pair of= SAs=20 (one in each direction) is required. IKE explicitly creates SA pairs in=20 recognition of this common usage requirement."
 
However&nb= sp;in=20 an example scenario in section 2.9.1 of draft-ietf-ipsecme-ikev= 2bis,=20 it seems that an SA can be used to carry traffic in both=20 directions:
" Suppose = that host A=20 has a policy whose effect is that traffic to 192.0.1.66 is sent via = host=20 B encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is = also=20 sent via B, but must use 3DES.  Suppose also that host B accepts any= =20 combination of AES and 3DES.

4301 is correct. Sometimes folks refer to= the pair=20 of SAs that IKE always creates as an SA, but that is not the correct=20 terminology.

Steve
--_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_-- From rsjenwar@gmail.com Tue May 26 07:21: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 1BB343A6C02 for ; Tue, 26 May 2009 07:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8ZeiEzk+IuN for ; Tue, 26 May 2009 07:21:46 -0700 (PDT) Received: from mail-px0-f125.google.com (mail-px0-f125.google.com [209.85.216.125]) by core3.amsl.com (Postfix) with ESMTP id 044D428C23D for ; Tue, 26 May 2009 07:21:45 -0700 (PDT) Received: by pxi31 with SMTP id 31so3122806pxi.29 for ; Tue, 26 May 2009 07:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jIU7sCSA6g9kz6OOww3azOJzX+bzGGwKpuCOL/i7fqU=; b=vHTzshE6ESuH5ysNPvfldccoKaibjnHdhZA474yBKtIE217zlfsiLf32L6T/AkBf13 2oXLyv9EvCdJ7We6C/JgyNKa024OshS36tzMWwyH+C3M6IXyTWS91xiPfKO74Aqo5O52 RYGlNf/N9McsSIc6K2Z3hkNgxOpdHZbjL5NQY= 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=PG2Q9S+MfgHvZDIAIltQgOJbz40oTw9HuOYVb2guSIYHFCSFQYX+l2OF+T3WuleWmR HDsaO0xo6YoNsBmqhG2m6sycenh4mZRmYi/sKvWcZ6D60UXyb2fte38BNRG+sQUI8T38 KHJ6GjT5VwM1ZPaktweWZ5y7qOA6KtzOG4cPs= MIME-Version: 1.0 Received: by 10.142.246.19 with SMTP id t19mr2737700wfh.216.1243347762165; Tue, 26 May 2009 07:22:42 -0700 (PDT) In-Reply-To: <068F06DC4D106941B297C0C5F9F446EA3CB241D43F@aplesstripe.dom1.jhuapl.edu> References: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> <068F06DC4D106941B297C0C5F9F446EA3CB241D43F@aplesstripe.dom1.jhuapl.edu> Date: Tue, 26 May 2009 19:52:42 +0530 Message-ID: <7ccecf670905260722t63e605cby39fb5748b07d644c@mail.gmail.com> From: Raj Singh To: "Gunduzhan, Emre" Content-Type: multipart/alternative; boundary=000e0cd2e6e6b23c5f046ad17549 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Inconsistent usage of 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, 26 May 2009 14:21:47 -0000 --000e0cd2e6e6b23c5f046ad17549 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Emre, On Tue, May 26, 2009 at 6:38 PM, Gunduzhan, Emre wrote: > Steve, > > Thanks for the clarification. So, at the end of the initial IKE_AUTH > exchange, there will (typically) be a pair of CHILD SAs created, one in each > direction, is this correct? > Yes. > That is, you never create a single SA by IKE_AUTH or CREATE_CHILD_SA, and > create another SA in the other direction by a subsequent CREATE_CHILD_SA? > We create a pair of SA, one for inbound and one for outbound traffic. These SAs will be uniquely identified on the peer by inside SPI and outside SPI. The inside SPI on one peer will the outside SPI on other peer and vice versa. Yes, we create a pair of SA using CREATE_CHILD_SA. Also, CREATE_CHILD_SA is used for REKEY of IKE SA, only in that case CREATE_CHILD_SA will create single SA. > > This is really ambiguous in RFC 4306 (at least to me) and would be great if > it can be clarified in the revised version. > > Thanks, > Emre > Thanks, Raj > > > ------------------------------ > > > *From:* Stephen Kent [mailto:kent@bbn.com] > *Sent:* Sunday, May 24, 2009 9:38 PM > *To:* Gunduzhan, Emre > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] Inconsistent usage of SA > > At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote: > > Content-Language: en-US > Content-Type: multipart/alternative; > boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203apless > tripedo_" > > Greetings, > > > > I am new to this group, so I hope I am not raising an issue which was > addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came > across some inconsistent terminology which I believe also exists in RFC > 4306. > > > > RFC 4301 defines a SA as a simplex "connection", and states that (section > 4.1): > > "To secure typical, bi-directional communication between two IPsec-enabled > systems, a pair of SAs (one in each direction) is required. IKE explicitly > creates SA pairs in recognition of this common usage requirement." > > > > However in an example scenario in section 2.9.1 > of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry > traffic in both directions: > > " Suppose that host A has a policy whose effect is that traffic to > 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other > hosts in 192.0.1.0/24 is also sent via B, but must use 3DES. Suppose also > that host B accepts any combination of AES and 3DES. > > > 4301 is correct. Sometimes folks refer to the pair of SAs that IKE always > creates as an SA, but that is not the correct terminology. > > Steve > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --000e0cd2e6e6b23c5f046ad17549 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Emre,


On Tue, May 26, 2009 at 6:38= PM, Gunduzhan, Emre <Emre.Gunduzhan@jhuapl.edu> wrote:
Steve,
=C2=A0
Thanks for the clarification. So, at the end of the=20 initial IKE_AUTH exchange, there will (typically) be=C2=A0a pair of=C2=A0CH= ILD=20 SAs created, one in each direction, is this correct?
=C2=A0Yes.
That is, you never create a=20 single SA by IKE_AUTH or CREATE_CHILD_SA, and create another SA in the othe= r=20 direction by a subsequent CREATE_CHILD_SA?
=C2=A0We create a pair of SA, one for inbound and one for outbou= nd traffic. These SAs will be uniquely identified on the peer by inside SPI= and outside SPI. The inside SPI on one peer will the outside SPI on other = peer and vice versa.
Yes, we create a pair of SA using CREATE_CHILD_SA. Also, CREATE_CHILD_SA is= used for REKEY of IKE SA, only in that case CREATE_CHILD_SA will create si= ngle SA.
=C2=A0
This is really ambiguous in RFC 4306 (at least to me)=20 and would be great if it can be clarified in the revised=20 version.
=C2=A0
Thanks,
Emre
Thanks,
Raj

=C2=A0
=C2=A0
=C2=A0
=C2=A0From: Stephen Kent=20 [mailto:kent@bbn.com]=
Sent: Sunday, May 24, 2009 9:38=20 PM
To: Gunduzhan, Emre
Cc: ipsec@ietf.org
Subject:=20 Re: [IPsec] Inconsistent usage of SA

<= /div>
At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type:=20 multipart/alternative;
=C2=A0=C2=A0=C2=A0=C2=A0=20 boundary=3D"_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_"
Greetings,
=C2=A0
I am new to this= =20 group, so I hope I am not raising an issue which was addressed earlier. I= was=20 reading draft-ietf-ipsecme-ikev2bis, and I came across some inconsistent= =20 terminology which I believe also exists in RFC 4306.
=C2=A0
RFC 4301 defines= a SA=20 as a simplex "connection", and states that (section 4.1):
"To secure = typical,=20 bi-directional communication between two IPsec-enabled systems, a pair of= SAs=20 (one in each direction) is required. IKE explicitly creates SA pairs in= =20 recognition of this common usage requirement."
=C2=A0
However=C2=A0in= =20 an=C2=A0example scenario in section 2.9.1 of=C2=A0draft-ietf-ipsecme-ikev= 2bis,=20 it seems that an SA can be used to carry traffic in both=20 directions:
" Suppose t= hat host A=20 has a=C2=A0policy whose effect is that traffic to 192.0.1.66 is sent via = host=20 B encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also=20 sent via B, but must use 3DES.=C2=A0 Suppose also that host B accepts any= =20 combination of AES and 3DES.

4301 is correct. Sometimes folks refe= r to the pair=20 of SAs that IKE always creates as an SA, but that is not the correct=20 terminology.

Steve

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


--000e0cd2e6e6b23c5f046ad17549-- From kent@bbn.com Tue May 26 07:48: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 A746928C234 for ; Tue, 26 May 2009 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.189, 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 64R6J3BKgb93 for ; Tue, 26 May 2009 07:48:20 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 21C2B28C291 for ; Tue, 26 May 2009 07:45:53 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[168.77.196.182]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M8xwA-0008SZ-Cc; Tue, 26 May 2009 10:47:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <068F06DC4D106941B297C0C5F9F446EA3CB241D43F@aplesstripe.dom1.jhuapl.edu> References: <068F06DC4D106941B297C0C5F9F446EA3CB241D203@aplesstripe.dom1.jhuapl.edu> <068F06DC4D106941B297C0C5F9F446EA3CB241D43F@aplesstripe.dom1.jhuapl.edu> Date: Tue, 26 May 2009 09:36:36 -0400 To: "Gunduzhan, Emre" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-968773246==_ma============" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Inconsistent usage of 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, 26 May 2009 14:48:20 -0000 --============_-968773246==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:08 AM -0400 5/26/09, Gunduzhan, Emre wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > > boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_" > >Steve, > >Thanks for the clarification. So, at the end of the initial IKE_AUTH >exchange, there will (typically) be a pair of CHILD SAs created, one >in each direction, is this correct? yes. >That is, you never create a single SA by IKE_AUTH or >CREATE_CHILD_SA, and create another SA in the other direction by a >subsequent CREATE_CHILD_SA? yes. > >This is really ambiguous in RFC 4306 (at least to me) and would be >great if it can be clarified in the revised version. > >Thanks, >Emre > > --============_-968773246==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] Inconsistent usage of SA
At 9:08 AM -0400 5/26/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_"
Steve,
 
Thanks for the clarification. So, at the end of the initial IKE_AUTH exchange, there will (typically) be a pair of CHILD SAs created, one in each direction, is this correct?

yes.
That is, you never create a single SA by IKE_AUTH or CREATE_CHILD_SA, and create another SA in the other direction by a subsequent CREATE_CHILD_SA?

yes.
 
This is really ambiguous in RFC 4306 (at least to me) and would be great if it can be clarified in the revised version.
 
Thanks,
Emre


--============_-968773246==_ma============-- From paul.hoffman@vpnc.org Tue May 26 08:02: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 D898A28C218 for ; Tue, 26 May 2009 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxFxX1X5QCcV for ; Tue, 26 May 2009 08:02:39 -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 A800628C25F for ; Tue, 26 May 2009 08:02:38 -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 n4QF4FI7040142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 08:04:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> References: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> Date: Tue, 26 May 2009 08:04:12 -0700 To: Matthew Cini Sarreo , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IKEv2: RADIUS 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, 26 May 2009 15:02:39 -0000 At 8:43 AM +0200 5/26/09, Matthew Cini Sarreo wrote: >We are interested to have our implementation of IKEv2 to provide support for authentication with a RADIUS server. We did this in IKEv1 by implementing XAuth. For IKEv2, the only resource that seems to tackle this is http://www.employees.org/~ddukes/ikev2_cp_dhcp_radius_ietf56.pdf, which seems quite old. Is this still valid to use? Not really. Most developers have used one or more of the popular EAP methods for this. --Paul Hoffman, Director --VPN Consortium From kohn.jack@gmail.com Tue May 26 20:48: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 7C8C23A6E77 for ; Tue, 26 May 2009 20:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 CLqXrPCUjOr0 for ; Tue, 26 May 2009 20:48:53 -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 AE9143A67E1 for ; Tue, 26 May 2009 20:48:53 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so3183284qwe.31 for ; Tue, 26 May 2009 20:50:33 -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=nChzCx8pQW//IQEVYMKex41djZogc469qMbwEMa5kN4=; b=L/TchHevSxTv6JgaDricll3r4XN0ZB6LQn+A6PZ68IgIAb8HF+Ajf7Y0ot+EMLhDvb Z6hw+YIQf5L+c1kyUkuxjHeDPFP02et5XPqte0IGrTxJFzFB63eB3hF4f7py/l+RO6XZ rWn8TgB5WHxpGKbALsFJo4bLBGu4n4A4DH9UM= 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=v8Of/SbJX78myL0wBHp1gua20AkiglvDkhpqpXi/klw/WBHU1TMAWohH5zVSFSkFnY rHI5vb8ZjeLgfFDkfOGq0xK6BamZg3lLdm3a2Cll2S7H8X5zt4CYcioyOtjFkgsEe4K3 VcyyvpKL6ja748rKDgVApMMEl7WoPzW/B3J4I= MIME-Version: 1.0 Received: by 10.229.99.208 with SMTP id v16mr2671453qcn.75.1243396233416; Tue, 26 May 2009 20:50:33 -0700 (PDT) In-Reply-To: References: <92c950310905251723o2efbdfdct5428556a8541daf7@mail.gmail.com> <7AF939ED-28E6-4814-A774-F75FED105888@merike.com> <06b201c9de3c$ac7fa3e0$057eeba0$@net> <4A1C570D.3060005@otd.com> Date: Wed, 27 May 2009 09:20:33 +0530 Message-ID: From: Jack Kohn To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=0016364ed06acecf71046adcbe7d Subject: [IPsec] Fwd: AH or 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: Wed, 27 May 2009 03:48:55 -0000 --0016364ed06acecf71046adcbe7d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sorry for cross post, but there is this interesting discussion going on in nanog. The discussion led me to think on why we still need to have AH around (Yes, i am aware of AH never being export restricted and all). Cant this be replaced with ESP-NULL? Why have two protocols that end up doing essentially the same thing? Jack ---------- Forwarded message ---------- From: Merike Kaeo Date: Wed, May 27, 2009 at 5:53 AM Subject: Re: AH or ESP To: Jack Kohn Cc: Dave Israel , nanog@nanog.org I agree as well that ESP-Null the way to go for integrity. From operational perspective if you are supporting both v4 and v6 (and you will) then having different protocols will be a nightmare. Common denominator is ESP-Null. Realistically for IPsec, unless you have the scalable credential issue resolved and easier configs from vendors, the operational time sync will have many looking elsewhere to accomplish what's needed in the name of security. (total bummer IMHO). - merike On May 26, 2009, at 4:35 PM, Jack Kohn wrote: >> >> The delusion that network operators can successfully use unhelpful >> protocols and/or smoke and mirrors to force idealist network design on >> others needs to end. People use new protocols because they are better. >> If the benefit of moving to a new protocol does not outweigh the pain >> of moving to it, people don't use it. That's why the OSI protocols did >> not kill IP like they were supposed to in the 90s, it is why the largely >> forgotten mandated move from Windows to secure OSes (ie, Unix) for all >> government employees never happened, and it is why IPv6 is sputtering. >> If people want to use NAT, they are going to use NAT. They may stop >> using it if the widespread adoption of peer to peer protocols means they >> are missing out on things other people are doing. They are not going to >> stop using NAT to use a protocol maliciously designed to break it; they >> will just wait, patiently and nearly always successfully, for somebody >> to come out with a version that has no such malice. They are certainly >> not going to stop using NAT because somebody tells them they should use >> a security protocol that does not secure anything worth securing. >> >> BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, >> less stick. >> >> > I agree. Folks are going to use ESP-NULL if they really want Integrity > Protection .. > > > -Dave >> >> >> --0016364ed06acecf71046adcbe7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for cross post, but there is this interesting discussion going on in = nanog.

The discussion led me to think on why we still need to have A= H around (Yes, i am aware of AH never being export restricted and all). Can= t this be replaced with ESP-NULL? Why have two protocols that end up doing = essentially the same thing?

Jack

---------- Forwarded message ---= -------
From: Merike Kaeo <kaeo@merike.com>=
Date: Wed, May 27, 2009 at 5:53 AM
Subject: Re: AH or ESP
To: Jack Ko= hn <kohn.jack@gmail.com>Cc: Dave Israel <davei@otd.com>= ;, nanog@nanog.org


I agree as well that ESP-Null the way to go for integrity. =A0From = operational perspective if you are supporting both v4 and v6 (and you will)= then having different protocols will be a nightmare. =A0Common denominator= is ESP-Null.

Realistically for IPsec, unless you have the scalable credential issue reso= lved and easier configs from vendors, the operational time sync will have m= any looking elsewhere to accomplish what's needed in the name of securi= ty. (total bummer IMHO).

- merike


On May 26, 2009, at 4:35 PM, Jack Kohn wrote:



The delusion that network operators can successfully use unhelpful
protocols and/or smoke and mirrors to force idealist network design on
others needs to end. =A0People use new protocols because they are better. If =A0the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. =A0That's why the OSI protoco= ls did
not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all
government employees never happened, and it is why IPv6 is sputtering.
If people want to use NAT, they are going to use NAT. =A0They may stop
using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. =A0They are not going to<= br> stop using NAT to use a protocol maliciously designed to break it; they
will just wait, patiently and nearly always successfully, for somebody
to come out with a version that has no such malice. =A0They are certainly not going to stop using NAT because somebody tells them they should use
a security protocol that does not secure anything worth securing.

BitTorrent is a better anti-NAT tool than AH ever will be. =A0More carrot,<= br> less stick.


I agree. Folks are going to use ESP-NULL if they really want Integrity
Protection ..


-Dave




--0016364ed06acecf71046adcbe7d-- From rsjenwar@gmail.com Tue May 26 22:09: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 4F8303A6C6C for ; Tue, 26 May 2009 22:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.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 I7G8ZruG9Zik for ; Tue, 26 May 2009 22:09:12 -0700 (PDT) Received: from mail-px0-f125.google.com (mail-px0-f125.google.com [209.85.216.125]) by core3.amsl.com (Postfix) with ESMTP id 7C6233A6D79 for ; Tue, 26 May 2009 22:09:12 -0700 (PDT) Received: by pxi31 with SMTP id 31so3480935pxi.29 for ; Tue, 26 May 2009 22:10: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; bh=QvLKRbZPYm2wJY01SP5Ujy3ZyGEO/vChePaefRLuDZA=; b=i6/8qnCnVfv5es+9JPtwQLEWxGuSOMYrytXEDE4gv43t1QDDnpFolrRdqI6/DCcSRv R4eZgV3xrvSV+XjsipBoCKw7aEpUHSbOBWH6GSjwWX1BeOMV0NmtQ4WqvQcbdGrACXf5 qcRGkwbGEvydLxX4Vsgoo1tmrzT6a6ysBJLeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IrRyaZSnsRnf/HojBpOUKC8nezFiB8uBIjAhotbkYcGkvWOd+lT/3I5BFlV8Kgrcad nXDrSGAt+1V3zSsO8BkGK67EoKpBAjTf1ivPrcVCK95flyBdf76A/P226TyGWwu+oPzH XPo+9LleaWihX3o5LdsAuekf5aWGfGKeHOhCU= MIME-Version: 1.0 Received: by 10.142.188.12 with SMTP id l12mr2353277wff.180.1243401050943; Tue, 26 May 2009 22:10:50 -0700 (PDT) Date: Wed, 27 May 2009 10:40:50 +0530 Message-ID: <7ccecf670905262210u30960243vfe1d7e585babc6b7@mail.gmail.com> From: Raj Singh To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd2d970f47272046adddd6b Subject: [IPsec] Questions on ikev2-redirect-10 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, 27 May 2009 05:09:13 -0000 --000e0cd2d970f47272046adddd6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Vijay, I have some question on ikev2-redirect-10 draft. In section 5, ------ Once the client sends an acknowledgment to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload. However, it should allow sufficient time for the client to setup the required security associations with the new security gateway. This time period should be configurable on the gateway. ------- Suppose after sending N[REDIRECT] in case of Gateway initiated redirect, there is a time gap for client to delete old SA and create new SA with redirected Gateway. During this time, IKE REKEY occurs from gateway or client, what should be the behavior, should it REKEY on old SA or defer the rekey ? Also, when deleting IKE SA, due to redirect, is there any way to know that this delete is sue to redirect ? Thanks, Raj --000e0cd2d970f47272046adddd6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Vijay,

I have some question on ikev2-redirect-10 draft.

In= section 5,
------
=C2=A0=C2=A0=C2=A0 Once the client sends an acknow= ledgment to the gateway, it SHOULD
=C2=A0=C2=A0 delete the existing secu= rity associations with the old gateway by
=C2=A0=C2=A0 sending an Informational message with a DELETE payload.=C2=A0 = The gateway
=C2=A0=C2=A0 MAY also decide to delete the security associat= ions without any
=C2=A0=C2=A0 signaling from the client, again by sendin= g an Informational message
=C2=A0=C2=A0 with a DELETE payload.=C2=A0 How= ever, it should allow sufficient time for
=C2=A0=C2=A0 the client to setup the required security associations with th= e new
=C2=A0=C2=A0 security gateway.=C2=A0 This time period should be co= nfigurable on the
=C2=A0=C2=A0 gateway.
-------

Suppose after = sending N[REDIRECT] in case of Gateway initiated redirect,
there is a time gap for client to delete old SA and create new SA with
= redirected Gateway.

During this time, IKE REKEY occurs from gateway = or client, what should be
the behavior, should it REKEY on old SA or de= fer the rekey ?

Also, when deleting IKE SA, due to redirect, is there any way to know t= hat
this delete is sue to redirect ?



Thanks,
Raj
--000e0cd2d970f47272046adddd6b-- From ynir@checkpoint.com Wed May 27 00:36: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 DF5D63A6F24 for ; Wed, 27 May 2009 00:36:35 -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 7700-bpz3X8s for ; Wed, 27 May 2009 00:36:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F36723A6E5F for ; Wed, 27 May 2009 00:36:34 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 119D229C002; Wed, 27 May 2009 10:38:17 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C74EA29C001 for ; Wed, 27 May 2009 10:38:16 +0300 (IDT) X-CheckPoint: {4A1CECBF-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 n4R7WA42023614 for ; Wed, 27 May 2009 10:38:15 +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, 27 May 2009 10:36:30 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Wed, 27 May 2009 10:36:29 +0300 Thread-Topic: Some comments about redirect Thread-Index: AQHJ3pz3PXheCyL8SUWCuOtY0AgqFQ== Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@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: [IPsec] Some comments about redirect 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, 27 May 2009 07:36:36 -0000 Hi. I've read through the draft again, and here are a few comments: Section 3 has the following line: If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT payload to the VPN client. This IMO should apply to all variations, not just to redirect during the In= itial exchange. I'm wondering if the REDIRECT notification type should not be allocated fro= m the error range. It makes more sense, since it always fails the exchange = (or at least part of it - the child SA in the IKE_AUTH exchange) Section 10 sets up an IANA registry for identity types. Couldn't we just re= use the "IKEv2 Identification Payload ID Types"? There's already IPv4, IPv= 6 and FQDN, and additionally KEY_ID for locally meaningful names and a rang= e of private use IP addresses. Why set up a new registry for the same thing= ? Yoav=20 Email secured by Check Point From kivinen@iki.fi Wed May 27 03:01: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 47C8B28C147 for ; Wed, 27 May 2009 03:01:18 -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 qQP2AxWuFEao for ; Wed, 27 May 2009 03:01:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD0D28C148 for ; Wed, 27 May 2009 03:01: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 n4RA2ntJ002084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 13:02:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4RA2mPl007373; Wed, 27 May 2009 13:02: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: <18973.4040.861505.953532@fireball.kivinen.iki.fi> Date: Wed, 27 May 2009 13:02:48 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" Subject: [IPsec] Some comments about redirect 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, 27 May 2009 10:01:18 -0000 Yoav Nir writes: > Section 10 sets up an IANA registry for identity types. Couldn't we > just reuse the "IKEv2 Identification Payload ID Types"? There's > already IPv4, IPv6 and FQDN, and additionally KEY_ID for locally > meaningful names and a range of private use IP addresses. Why set up > a new registry for the same thing? I do not think we want reuse IKEv2 Identification Payload ID types for this, as then we again create lots of values which are not defined (i.e. what does it mean to send ID_DER_ASN1_GN during redirect). I prefer to have separate registry for it. I would actually like to have separate registries for the two different use cases there is, as not all values are usable in both cases. Creating new IANA registries has small initial overhead, and if there will not be any more allocations there is no more overhead for having its own registry compared to sharing IKEv2 one. On the other hand if there will be new allocations then even better if we have separate registry for them so we do not mess up other registries. -- kivinen@iki.fi From ynir@checkpoint.com Wed May 27 03:13: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 C8B5F3A6FC3 for ; Wed, 27 May 2009 03:13:52 -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 ETlPj6qgmZ1W for ; Wed, 27 May 2009 03:13:52 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A469B3A6FBA for ; Wed, 27 May 2009 03:13:51 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 89BBB29C002; Wed, 27 May 2009 13:15:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 485D529C001; Wed, 27 May 2009 13:15:34 +0300 (IDT) X-CheckPoint: {4A1D119B-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 n4RAFW3d008228; Wed, 27 May 2009 13:15: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; Wed, 27 May 2009 13:15:32 +0300 From: Yoav Nir To: Tero Kivinen Date: Wed, 27 May 2009 13:11:45 +0300 Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyj Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF726@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@il-ex01.ad.checkpoint.com>, <18973.4040.861505.953532@fireball.kivinen.iki.fi> In-Reply-To: <18973.4040.861505.953532@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: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect 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, 27 May 2009 10:13:52 -0000 OK. In that case I would add to the initial registry 4 - locally meaningful name In our product, the gateways have "names" that appear both in the GUI and t= he configuration files (and logs). It's easier for them to fetch another ga= teway's "object" by name than by IP address. Such a name could be ASCII or = UTF-8. ________________________________________ From: Tero Kivinen [kivinen@iki.fi] Sent: Wednesday, May 27, 2009 13:02 To: Yoav Nir Cc: ipsec@ietf.org Subject: [IPsec] Some comments about redirect Yoav Nir writes: > Section 10 sets up an IANA registry for identity types. Couldn't we > just reuse the "IKEv2 Identification Payload ID Types"? There's > already IPv4, IPv6 and FQDN, and additionally KEY_ID for locally > meaningful names and a range of private use IP addresses. Why set up > a new registry for the same thing? I do not think we want reuse IKEv2 Identification Payload ID types for this, as then we again create lots of values which are not defined (i.e. what does it mean to send ID_DER_ASN1_GN during redirect). I prefer to have separate registry for it. I would actually like to have separate registries for the two different use cases there is, as not all values are usable in both cases. Creating new IANA registries has small initial overhead, and if there will not be any more allocations there is no more overhead for having its own registry compared to sharing IKEv2 one. On the other hand if there will be new allocations then even better if we have separate registry for them so we do not mess up other registries. -- kivinen@iki.fi Scanned by Check Point Total Security Gateway. Email secured by Check Point From RCHARLET@nortel.com Wed May 27 10: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 005D53A6F45 for ; Wed, 27 May 2009 10:02:12 -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 W0hHc7EiO3tz for ; Wed, 27 May 2009 10:02:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 749F13A6F5A for ; Wed, 27 May 2009 10:02:09 -0700 (PDT) Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4RH0dS29864; Wed, 27 May 2009 17:00:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 13:01:46 -0400 Message-ID: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on exponent size as discussed in RFC 3526 Thread-Index: Acne7NGcDA+OOfMRTZWY5fDPiqcKiw== From: "Ricky Charlet" To: , , , , Subject: [IPsec] Question on exponent size as discussed in RFC 3526 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, 27 May 2009 17:02:12 -0000 Hi folks, I'm having difficulty interpreting RFC3526, "More Modular Exponential (MODP) Diffie-Hellman groups" section 1, "Introduction". Quoting from the RFC ---------cut------------ The exponent size used in the Diffie-Hellman must be selected so that it matches other parts of the system. It should not be the weakest link in the security system. It should have double the entropy of the strength of the entire system, i.e., if you use a group whose strength is 128 bits, you must use more than 256 bits of randomness in the exponent used in the Diffie-Hellman calculation. ----------paste--------- Alright here... I'm trying to interpret what is meant, in very pragmatic terms, by "exponent size". I take the exponent to be the 'a' or 'b' in the Diffie-Hellman calculations... That is the random number chosen by each peer in an implementation specific way.=20 What confuses me is the juxtaposition of the statement that it must be double the size of the group but with examples given which are *far* below sizes of even the weakest groups. In fact, the examples seem to indicate a corilation with key sizes of symetric key ciphers/hmacs.=20 So should a exponent size be double the size of the Diffie-Hellman "p", or double the size of the symetric key? Or is there a formula for "strength of group in bits" that I am missing? In RFC 3766, "Determining Strengths for Public Keys", I found this: ---------cut-------------- Because of Pollard's rho method, the search space in a DH key exchange for the key (the exponent in a g^a term), must be twice as large as the symmetric key. Therefore, to securely derive a key of K bits, an implementation must use an exponent with at least 2*K bits. See [ODL99] for more detail. --------paste---------------- So I think I'm very close to answering my own question... The exponent must be twice the size of the symentric key in use. I hesitate because that is not quite what RFC3526 says ( "twice the size of the group" ).=20 Any illumination would be appreciated. -- Ricky Charlet=20 rcharlet@nortel.com USA 408-495-5726 From sfluhrer@cisco.com Wed May 27 10:47: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 F0CEC3A6F6D for ; Wed, 27 May 2009 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 6dmzSPStuYHa for ; Wed, 27 May 2009 10:47:51 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0EF1728C143 for ; Wed, 27 May 2009 10:47:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="164926352" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 May 2009 17:48:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHmwvr010234; Wed, 27 May 2009 10:48:58 -0700 Received: from sfluhrerwxp (stealth-10-32-244-82.cisco.com [10.32.244.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHmvaP027961; Wed, 27 May 2009 17:48:57 GMT From: "Scott Fluhrer" To: "'Ricky Charlet'" , , , , , References: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> Date: Wed, 27 May 2009 13:48:56 -0400 Message-ID: <033b01c9def3$693a7df0$52f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acne7NGcDA+OOfMRTZWY5fDPiqcKiwAAwOLA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5331; t=1243446538; x=1244310538; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20Question=20on=20exponent=20si ze=20as=20discussed=20in=20RFC=203526 |Sender:=20; bh=9YKhV8fS9GkitWWgDTb6tf2dEkiyIT5tOwD9baTWBNk=; b=JJL1d2cFPI1Xr0pljyJXUINASJrlT2u3aZd5NdfD7bxqorGqNmjy4lQfEZ 28rbpnDxsfzguHipkPN0/IfUeuc54o4djA058MpeqhUnGMntxpdCDVF+0qsp g7vc1AxMVUpNGq8t2bBAfko9YB9wCB/UuayXPArAwmOcBWc2zWRNc=; Authentication-Results: sj-dkim-1; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [IPsec] Question on exponent size as discussed in RFC 3526 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, 27 May 2009 17:47:53 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Ricky Charlet > Sent: Wednesday, May 27, 2009 1:02 PM > To: ipsec@ietf.org; kivinen@ssh.fi; mika.kojo@helsinki.fi; > hilarie@purplestreak.com; paul.hoffman@vpnc.org > Subject: [IPsec] Question on exponent size as discussed in RFC 3526 > > Hi folks, > > I'm having difficulty interpreting RFC3526, "More > Modular Exponential (MODP) Diffie-Hellman groups" section 1, > "Introduction". > Quoting from the RFC > > ---------cut------------ > The exponent size used in the Diffie-Hellman must be selected so that > it matches other parts of the system. It should not be the weakest > link in the security system. It should have double the entropy of > the strength of the entire system, i.e., if you use a group whose > strength is 128 bits, you must use more than 256 bits of randomness > in the exponent used in the Diffie-Hellman calculation. > ----------paste--------- > > Alright here... I'm trying to interpret what is meant, in > very pragmatic terms, by "exponent size". I take the > exponent to be the 'a' or 'b' in the Diffie-Hellman > calculations... That is the random number chosen by each peer > in an implementation specific way. I don't know what you mean by 'a' or 'b'; there's no standard naming convention for the various parts of the operation. For phase 1, the operation is: g ** e mod p where: g is the generator listed in the RFC (for all groups listed in this RFC, it is 2) p is the prime listed in the RFC e is a random exponent ** is the (modular) exponentiation operation When you chose a random value e, you need to pick a value out of a range. The "exponent size" is the number of random bits you use; that is, if you pick a 200 bit exponent size, you would pick a random number between 1 and 2**200. > > What confuses me is the juxtaposition of the statement that > it must be double the size of the group but with examples > given which are *far* below sizes of even the weakest groups. > In fact, the examples seem to indicate a corilation with key > sizes of symetric key ciphers/hmacs. The reason that the examples seem to indicate a correlation with the symmetric key sizes is because there is a correlation with the symmetric key sizes. When attacking a system that uses DH to generate keys, the attacker has three possible strategies to employ: - Attack the generated symmetric keys directly For example, if the symmetric keys are 128 bit AES keys, the attacker can brute force that with O(2**128) effort. - Use a generic group attack based on the exponent length to recover the private exponent If the attacker knows that one side picks N bit exponents, then the attacker can recover that exponent in about O(2**(N/2)) work (see Pollard Rho or Big Step/Little Step methods) - Use a NFS-based attack to recover the exponent This attack recovers the private exponent with time dependant only on the modulus For the last one, well, we don't have any really good models on how long it would take; the 'Strength Estimates' in section 8 reflect two different guesses by various experts. On the other hand, for picking exponent length, what we want to do is make sure that it isn't the weakest part of the system; if we pick a length that's double the symmetric key size, then we know that the attack based on exponent length will take about as long as attacking the symmetric key directly. > > So should a exponent size be double the size of the > Diffie-Hellman "p", or double the size of the symetric key? Double the size of the symmetric key. BTW: double the size of p would be silly; it turns out that: x ** e mod p == x ** (e mod p-1) mod p (This is known as "Fermat's Little Theorem", and is true for any x, e and prime p). So, if you pick an exponent larger than p, there's an equivilant exponent smaller than p that does exactly the same thing, and would probably work a lot faster. > Or is there a formula for "strength of group in bits" that I > am missing? > > > In RFC 3766, "Determining Strengths for Public Keys", I found this: > ---------cut-------------- > Because of > Pollard's rho method, the search space in a DH key exchange for the > key (the exponent in a g^a term), must be twice as large as the > symmetric key. Therefore, to securely derive a key of K bits, an > implementation must use an exponent with at least 2*K bits. See > [ODL99] for more detail. > --------paste---------------- > > So I think I'm very close to answering my own question... The > exponent must be twice the size of the symentric key in use. > I hesitate because that is not quite what RFC3526 says ( > "twice the size of the group" ). Actually, it's closer to "twice the size of the strength of the group". The "strength of the group" is its resistance to the attack #3 I have listed (NFS). > > > Any illumination would be appreciated. > > > -- > Ricky Charlet > rcharlet@nortel.com > USA 408-495-5726 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From RCHARLET@nortel.com Wed May 27 11:56: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 28E153A6D76 for ; Wed, 27 May 2009 11:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yBNTJAjb79W for ; Wed, 27 May 2009 11:56:36 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0DDF73A6BA9 for ; Wed, 27 May 2009 11:56:17 -0700 (PDT) Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4RIvfD00066; Wed, 27 May 2009 18:57:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 14:57:36 -0400 Message-ID: <8221DA6CC97A584CB6C8875FF71759DE03732015@zrtphxm0.corp.nortel.com> In-Reply-To: <033b01c9def3$693a7df0$52f4200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question on exponent size as discussed in RFC 3526 Thread-Index: Acne7NGcDA+OOfMRTZWY5fDPiqcKiwAAwOLAAAMFfSA= References: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> <033b01c9def3$693a7df0$52f4200a@amer.cisco.com> From: "Ricky Charlet" To: "Scott Fluhrer" , , , , , Subject: Re: [IPsec] Question on exponent size as discussed in RFC 3526 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, 27 May 2009 18:56:37 -0000 Hi Scott, Thanks for your reply. Unfortunatly, your reply continues my exact same confusion. Should e be twice the size of the key you need or twice the size of the dh group in use?=20 You state that=20 > the reason that the examples seem to indicate a correlation with the > symmetric key sizes is because there is a correlation with=20 > the symmetric key > sizes. =20 And > On the other hand, for picking exponent length, what we want=20 > to do is make > sure that it isn't the weakest part of the system; if we pick a length > that's double the symmetric key size, then we know that the=20 > attack based on > exponent length will take about as long as attacking the symmetric key > directly. =20 And > Double the size of the symmetric key. BTW: double the size=20 > of p would be > silly; it turns out that: These statements combine into a very forceful endorcement of the idea that the exponent should be double the size of the key you need to generate.=20 Yet in your last statement you also said: > Actually, it's closer to "twice the size of the strength of=20 > the group". The > "strength of the group" is its resistance to the attack #3 I=20 > have listed > (NFS). That really threw me. I have been taking the term "group" to mean the size of the modp group in bits (which is basically the size of p). In the context of the introdution section of RFC 3526, I'm pretty sure this is what was meant: definition group =3D dh group. But you seem to have a different defintion of 'group'? -- Ricky Charlet=20 rcharlet@nortel.com USA 408-495-5726=20 > -----Original Message----- > From: Scott Fluhrer [mailto:sfluhrer@cisco.com]=20 > Sent: Wednesday, May 27, 2009 10:49 AM > To: Charlet, Ricky (SC100:0000); ipsec@ietf.org;=20 > kivinen@ssh.fi; mika.kojo@helsinki.fi;=20 > hilarie@purplestreak.com; paul.hoffman@vpnc.org > Subject: RE: [IPsec] Question on exponent size as discussed=20 > in RFC 3526 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > > On Behalf Of Ricky Charlet > > Sent: Wednesday, May 27, 2009 1:02 PM > > To: ipsec@ietf.org; kivinen@ssh.fi; mika.kojo@helsinki.fi;=20 > > hilarie@purplestreak.com; paul.hoffman@vpnc.org > > Subject: [IPsec] Question on exponent size as discussed in RFC 3526 > >=20 > > Hi folks, > >=20 > > I'm having difficulty interpreting RFC3526, "More=20 > > Modular Exponential (MODP) Diffie-Hellman groups" section 1,=20 > > "Introduction". > > Quoting from the RFC > >=20 > > ---------cut------------ > > The exponent size used in the Diffie-Hellman must be=20 > selected so that > > it matches other parts of the system. It should not be=20 > the weakest > > link in the security system. It should have double the=20 > entropy of > > the strength of the entire system, i.e., if you use a group whose > > strength is 128 bits, you must use more than 256 bits of=20 > randomness > > in the exponent used in the Diffie-Hellman calculation. > > ----------paste--------- > >=20 > > Alright here... I'm trying to interpret what is meant, in=20 > > very pragmatic terms, by "exponent size". I take the=20 > > exponent to be the 'a' or 'b' in the Diffie-Hellman=20 > > calculations... That is the random number chosen by each peer=20 > > in an implementation specific way.=20 >=20 > I don't know what you mean by 'a' or 'b'; there's no standard naming > convention for the various parts of the operation. For phase 1, the > operation is: >=20 > g ** e mod p >=20 > where: > g is the generator listed in the RFC (for all groups listed=20 > in this RFC, > it is 2) > p is the prime listed in the RFC > e is a random exponent > ** is the (modular) exponentiation operation >=20 > When you chose a random value e, you need to pick a value out=20 > of a range. > The "exponent size" is the number of random bits you use;=20 > that is, if you > pick a 200 bit exponent size, you would pick a random number=20 > between 1 and > 2**200. >=20 > >=20 > > What confuses me is the juxtaposition of the statement that=20 > > it must be double the size of the group but with examples=20 > > given which are *far* below sizes of even the weakest groups.=20 > > In fact, the examples seem to indicate a corilation with key=20 > > sizes of symetric key ciphers/hmacs.=20 >=20 > The reason that the examples seem to indicate a correlation with the > symmetric key sizes is because there is a correlation with=20 > the symmetric key > sizes. When attacking a system that uses DH to generate=20 > keys, the attacker > has three possible strategies to employ: >=20 > - Attack the generated symmetric keys directly > For example, if the symmetric keys are 128 bit AES keys,=20 > the attacker can > brute force that with O(2**128) effort. >=20 > - Use a generic group attack based on the exponent length to=20 > recover the > private exponent > If the attacker knows that one side picks N bit exponents, then the > attacker can recover that exponent in about O(2**(N/2)) work=20 > (see Pollard > Rho or Big Step/Little Step methods) >=20 > - Use a NFS-based attack to recover the exponent > This attack recovers the private exponent with time=20 > dependant only on the > modulus >=20 > For the last one, well, we don't have any really good models=20 > on how long it > would take; the 'Strength Estimates' in section 8 reflect two=20 > different > guesses by various experts. >=20 > On the other hand, for picking exponent length, what we want=20 > to do is make > sure that it isn't the weakest part of the system; if we pick a length > that's double the symmetric key size, then we know that the=20 > attack based on > exponent length will take about as long as attacking the symmetric key > directly. =20 >=20 >=20 >=20 > >=20 > > So should a exponent size be double the size of the=20 > > Diffie-Hellman "p", or double the size of the symetric key? >=20 > Double the size of the symmetric key. BTW: double the size=20 > of p would be > silly; it turns out that: >=20 > x ** e mod p =3D=3D x ** (e mod p-1) mod p >=20 > (This is known as "Fermat's Little Theorem", and is true for=20 > any x, e and > prime p). So, if you pick an exponent larger than p, there's=20 > an equivilant > exponent smaller than p that does exactly the same thing, and=20 > would probably > work a lot faster. > =20 > > Or is there a formula for "strength of group in bits" that I=20 > > am missing? > >=20 > >=20 > > In RFC 3766, "Determining Strengths for Public Keys", I found this: > > ---------cut-------------- > > Because of > > Pollard's rho method, the search space in a DH key=20 > exchange for the > > key (the exponent in a g^a term), must be twice as large as the > > symmetric key. Therefore, to securely derive a key of K bits, an > > implementation must use an exponent with at least 2*K bits. See > > [ODL99] for more detail. > > --------paste---------------- > >=20 > > So I think I'm very close to answering my own question... The=20 > > exponent must be twice the size of the symentric key in use.=20 > > I hesitate because that is not quite what RFC3526 says (=20 > > "twice the size of the group" ). >=20 > Actually, it's closer to "twice the size of the strength of=20 > the group". The > "strength of the group" is its resistance to the attack #3 I=20 > have listed > (NFS). > =20 > >=20 > >=20 > > Any illumination would be appreciated. > >=20 > >=20 > > -- > > Ricky Charlet > > rcharlet@nortel.com > > USA 408-495-5726 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > >=20 >=20 >=20 From sfluhrer@cisco.com Wed May 27 13:52: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 17D873A6F61 for ; Wed, 27 May 2009 13:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG+npnQ8bb-9 for ; Wed, 27 May 2009 13:52:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 146313A6CD2 for ; Wed, 27 May 2009 13:52:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,261,1241395200"; d="scan'208";a="164989924" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 May 2009 20:53:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4RKroSK019951; Wed, 27 May 2009 13:53:50 -0700 Received: from sfluhrerwxp (stealth-10-32-244-82.cisco.com [10.32.244.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RKrnYV023775; Wed, 27 May 2009 20:53:50 GMT From: "Scott Fluhrer" To: "'Ricky Charlet'" , , , , , References: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> <033b01c9def3$693a7df0$52f4200a@amer.cisco.com> <8221DA6CC97A584CB6C8875FF71759DE03732015@zrtphxm0.corp.nortel.com> Date: Wed, 27 May 2009 16:53:49 -0400 Message-ID: <037f01c9df0d$3cf9e9f0$52f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8221DA6CC97A584CB6C8875FF71759DE03732015@zrtphxm0.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acne7NGcDA+OOfMRTZWY5fDPiqcKiwAAwOLAAAMFfSAAA8lJAA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3354; t=1243457630; x=1244321630; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20Question=20on=20exponent=20si ze=20as=20discussed=20in=20RFC=203526 |Sender:=20; bh=BIBFFoNDsKJwutvGc7Ve22gUMg7MVVSYDRIZmJpVCoQ=; b=Cf+kfbik34Ff6wrOi7SVa0cMgZgoqJwRYTpYwPSsDGCf9V5DzbUBg0xc9y W6ZP3QIq4//NmBXGc6MhbzR82fWxkAB1h3dvOVDyKlj5o14QQM80+kBMTKgz KdUaMVarHT87X8e/6DqnRw4CdjAnHyb72/YgzVW7LtczBMOjCPCu4=; Authentication-Results: sj-dkim-1; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [IPsec] Question on exponent size as discussed in RFC 3526 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, 27 May 2009 20:52:09 -0000 > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@nortel.com] > Sent: Wednesday, May 27, 2009 2:58 PM > To: Scott Fluhrer; ipsec@ietf.org; kivinen@ssh.fi; > mika.kojo@helsinki.fi; hilarie@purplestreak.com; paul.hoffman@vpnc.org > Subject: RE: [IPsec] Question on exponent size as discussed > in RFC 3526 > > Hi Scott, > Thanks for your reply. Unfortunatly, your reply > continues my exact same confusion. Should e be twice the size > of the key you need or twice the size of the dh group in use? Twice the size of the key you need. > > You state that > > > the reason that the examples seem to indicate a correlation > with the > > symmetric key sizes is because there is a correlation with the > > symmetric key sizes. > > And > > On the other hand, for picking exponent length, what we > want to do is > > make sure that it isn't the weakest part of the system; if > we pick a > > length that's double the symmetric key size, then we know that the > > attack based on exponent length will take about as long as > attacking > > the symmetric key directly. > > And > > Double the size of the symmetric key. BTW: double the size > > of p would be > > silly; it turns out that: > > These statements combine into a very forceful endorcement of the idea > that the exponent should be double the size of the key you need to > generate. > > Yet in your last statement you also said: > > Actually, it's closer to "twice the size of the strength of > > the group". The > > "strength of the group" is its resistance to the attack #3 I > > have listed > > (NFS). > > That really threw me. I have been taking the term "group" to mean the > size of the modp group in bits (which is basically the size of p). In > the context of the introdution section of RFC 3526, I'm > pretty sure this > is what was meant: definition group = dh group. But you seem to have a > different defintion of 'group'? No; the distinction you appear to be missing is that 'size of the group' != 'strength of the group'. 'The size of the group' is, basically, p (well, actually, it's (p-1)/2, because we're working in a subgroup of that size; that's only one bit less, and so we can ignore it). 'The strength of the group' is how much effort it is to solve the discrete log problem in that group. This is considerably less than the size of the group. Now, for most symmetric ciphers, there's really no such distinction; an 128 bit AES key has a size of 128 bits and (to the best of our knowledge) it takes about 2**128 trial decryptions to recover the key, and so it has a strength of 128 bits. Counterexample: 3DES, which has a key size of either 168 or 192 bits (depending on whether you count the ignored bits), and appears to have a strength of about 112 bits (assuming you have access to a huge amount of memory). However, this isn't true for DH; the group size and the strength differ widely. For example, take DH group 14; that has a group size of 2048 bits; however, using NFS, it is believed that you can recover a private exponent after between 2**110 and 2**160 operations (and, yes, that's a large range; no one is quite sure how NFS scales with a modulus that size), and so appears to have a strength of between 110 and 160 bits. From RCHARLET@nortel.com Wed May 27 13:56: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 989D628C168 for ; Wed, 27 May 2009 13:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6+0QUFINp-H for ; Wed, 27 May 2009 13:56:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9E2B63A6A7E for ; Wed, 27 May 2009 13:55:46 -0700 (PDT) Received: from zrtphxm0.corp.nortel.com (zrtphxm0.corp.nortel.com [47.140.202.49]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4RKuDS11293; Wed, 27 May 2009 20:56:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 May 2009 16:57:19 -0400 Message-ID: <8221DA6CC97A584CB6C8875FF71759DE03732443@zrtphxm0.corp.nortel.com> In-Reply-To: <037f01c9df0d$3cf9e9f0$52f4200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question on exponent size as discussed in RFC 3526 Thread-Index: Acne7NGcDA+OOfMRTZWY5fDPiqcKiwAAwOLAAAMFfSAAA8lJAAAAoGCw References: <8221DA6CC97A584CB6C8875FF71759DE036EE1B1@zrtphxm0.corp.nortel.com> <033b01c9def3$693a7df0$52f4200a@amer.cisco.com> <8221DA6CC97A584CB6C8875FF71759DE03732015@zrtphxm0.corp.nortel.com> <037f01c9df0d$3cf9e9f0$52f4200a@amer.cisco.com> From: "Ricky Charlet" To: "Scott Fluhrer" , , , , , Subject: Re: [IPsec] Question on exponent size as discussed in RFC 3526 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, 27 May 2009 20:56:32 -0000 Ah, thanks. You helped me tremedously there with the size-of-group vs strength-of-group distinction. Very much appreciated. -- Ricky Charlet=20 rcharlet@nortel.com USA 408-495-5726=20 > -----Original Message----- > From: Scott Fluhrer [mailto:sfluhrer@cisco.com]=20 > Sent: Wednesday, May 27, 2009 1:54 PM > To: Charlet, Ricky (SC100:0000); ipsec@ietf.org;=20 > kivinen@ssh.fi; mika.kojo@helsinki.fi;=20 > hilarie@purplestreak.com; paul.hoffman@vpnc.org > Subject: RE: [IPsec] Question on exponent size as discussed=20 > in RFC 3526 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Ricky Charlet [mailto:rcharlet@nortel.com]=20 > > Sent: Wednesday, May 27, 2009 2:58 PM > > To: Scott Fluhrer; ipsec@ietf.org; kivinen@ssh.fi;=20 > > mika.kojo@helsinki.fi; hilarie@purplestreak.com;=20 > paul.hoffman@vpnc.org > > Subject: RE: [IPsec] Question on exponent size as discussed=20 > > in RFC 3526 > >=20 > > Hi Scott, > > Thanks for your reply. Unfortunatly, your reply=20 > > continues my exact same confusion. Should e be twice the size=20 > > of the key you need or twice the size of the dh group in use?=20 >=20 > Twice the size of the key you need. >=20 > >=20 > > You state that=20 > >=20 > > > the reason that the examples seem to indicate a correlation=20 > > with the=20 > > > symmetric key sizes is because there is a correlation with the=20 > > > symmetric key sizes. > >=20 > > And > > > On the other hand, for picking exponent length, what we=20 > > want to do is=20 > > > make sure that it isn't the weakest part of the system; if=20 > > we pick a=20 > > > length that's double the symmetric key size, then we know=20 > that the=20 > > > attack based on exponent length will take about as long as=20 > > attacking=20 > > > the symmetric key directly. > >=20 > > And > > > Double the size of the symmetric key. BTW: double the size=20 > > > of p would be > > > silly; it turns out that: > >=20 > > These statements combine into a very forceful endorcement=20 > of the idea > > that the exponent should be double the size of the key you need to > > generate.=20 > >=20 > > Yet in your last statement you also said: > > > Actually, it's closer to "twice the size of the strength of=20 > > > the group". The > > > "strength of the group" is its resistance to the attack #3 I=20 > > > have listed > > > (NFS). > >=20 > > That really threw me. I have been taking the term "group"=20 > to mean the > > size of the modp group in bits (which is basically the size=20 > of p). In > > the context of the introdution section of RFC 3526, I'm=20 > > pretty sure this > > is what was meant: definition group =3D dh group. But you=20 > seem to have a > > different defintion of 'group'? >=20 > No; the distinction you appear to be missing is that 'size of=20 > the group' !=3D > 'strength of the group'. >=20 > 'The size of the group' is, basically, p (well, actually,=20 > it's (p-1)/2, > because we're working in a subgroup of that size; that's only=20 > one bit less, > and so we can ignore it). >=20 > 'The strength of the group' is how much effort it is to solve=20 > the discrete > log problem in that group. This is considerably less than=20 > the size of the > group. >=20 > Now, for most symmetric ciphers, there's really no such=20 > distinction; an 128 > bit AES key has a size of 128 bits and (to the best of our=20 > knowledge) it > takes about 2**128 trial decryptions to recover the key, and=20 > so it has a > strength of 128 bits. Counterexample: 3DES, which has a key=20 > size of either > 168 or 192 bits (depending on whether you count the ignored bits), and > appears to have a strength of about 112 bits (assuming you=20 > have access to a > huge amount of memory). >=20 > However, this isn't true for DH; the group size and the=20 > strength differ > widely. For example, take DH group 14; that has a group size=20 > of 2048 bits; > however, using NFS, it is believed that you can recover a=20 > private exponent > after between 2**110 and 2**160 operations (and, yes, that's=20 > a large range; > no one is quite sure how NFS scales with a modulus that size), and so > appears to have a strength of between 110 and 160 bits. >=20 >=20 From vijay@wichorus.com Wed May 27 14: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 576833A691F for ; Wed, 27 May 2009 14:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=0.733, 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 KTt2dGc65Q7W for ; Wed, 27 May 2009 14:50:03 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 237413A6DC2 for ; Wed, 27 May 2009 14:50:03 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Wed, 27 May 2009 21:51:36 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 27 May 2009 14:51:36 -0700 From: Vijay Devarapalli To: , Message-ID: Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnr In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6ADCDFBE@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Final comments for ikev2-redirect-10 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, 27 May 2009 21:50:04 -0000 Hi Pasi, On 5/26/09 1:17 AM, "Pasi.Eronen@nokia.com" wrote: > There's one remaining issue that was changed due to WGLC comments, but > the result isn't quite what it IMHO should be. > > When doing redirection during IKE_AUTH, in some situations the > IKE_AUTH response with the REDIRECT is the last message between the > client and gateway (and the IKE_SA is not used, and cannot be used, > for any other exchanges after that). In other situations, it *is* > used for (at least) one additional exchange (Informational exchange > with DELETE payload). > > When the Informational exchange is needed/allowed and when not is > not totally random, but I don't expect that any readers would > understand it (I do know Tero can explain it :-). It also creates room > for confusion whether the REDIRECT is just a "hint" and the IKE_SA > could still be used for other exchanges, too. > > I would suggest we get rid of this unnecessary complexity, and simply > say that when you do REDIRECT during IKE_AUTH, no more exchanges are > done (on that IKE_SA) after the REDIRECT is sent. In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is not valid is when EAP is used and the redirect is done based on the unauthenticated ID. In all other cases, the IKEv2 SA is valid and should be torn down with an INFORMATIONAL exchange. IMHO, this is clear enough and is captured in the current draft. > There's also one place that is probably correct, but would > benefit from some clarification. Section 5 says: > > "When the client receives this message, it MUST send an empty > message as an acknowledgement. Until the client responds with an > acknowledgement, the gateway SHOULD re-transmit the redirect > INFORMATIONAL message as described in [2]." > > The MUST and SHOULD here give the impression that this Informational > exchange is somehow special, and treated differently from ordinary > Informational exchanges. As far as I can tell, it's *not* meant to be > special, and this text isn't meant to specify any new requirements. > I'd suggest rephrasing this something like > > "As in any other INFORMATIONAL exchange, the clients sends a > response (usually empty), and the gateway retransmits the request if > it doesn't receive a response." > > BTW, in Section 10, "expert review" probably should be "Expert Review > as specified in [RFC5226]". Made these two changes, Thanks. Vijay From vijay@wichorus.com Wed May 27 14:53: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 39A5C3A6768 for ; Wed, 27 May 2009 14:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.818 X-Spam-Level: X-Spam-Status: No, score=0.818 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 dEpLOfLPXtFF for ; Wed, 27 May 2009 14:53:14 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 624B83A6CE5 for ; Wed, 27 May 2009 14:53:14 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Wed, 27 May 2009 21:54:56 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 27 May 2009 14:54:57 -0700 From: Vijay Devarapalli To: Raj Singh , "ipsec@ietf.org" Message-ID: Thread-Topic: [IPsec] Questions on ikev2-redirect-10 Thread-Index: AcnfFcY9dFMQl/poRk2B0illndZegA== In-Reply-To: <7ccecf670905262210u30960243vfe1d7e585babc6b7@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [IPsec] Questions on ikev2-redirect-10 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, 27 May 2009 21:53:15 -0000 Hi, On 5/26/09 10:10 PM, "Raj Singh" wrote: > Hi Vijay, >=20 > I have some question on ikev2-redirect-10 draft. >=20 > In section 5, > ------ > =A0=A0=A0 Once the client sends an acknowledgment to the gateway, it SHOULD > =A0=A0 delete the existing security associations with the old gateway by > =A0=A0 sending an Informational message with a DELETE payload.=A0 The gateway > =A0=A0 MAY also decide to delete the security associations without any > =A0=A0 signaling from the client, again by sending an Informational message > =A0=A0 with a DELETE payload.=A0 However, it should allow sufficient time for > =A0=A0 the client to setup the required security associations with the new > =A0=A0 security gateway.=A0 This time period should be configurable on the > =A0=A0 gateway. > ------- >=20 > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect, > there is a time gap for client to delete old SA and create new SA with > redirected Gateway. >=20 > During this time, IKE REKEY occurs from gateway or client, what should be > the behavior, should it REKEY on old SA or defer the rekey ? The rekey should be deferred. The IKEv2 SA is going to be torn down anyway. > Also, when deleting IKE SA, due to redirect, is there any way to know tha= t > this delete is sue to redirect ? Well, the gateway redirected the client. If following that, there is a delete from the client, the gateway would know that the IKEv2 SA is being deleted because it redirected the client. Anyway, does it matter? Vijay From vijay@wichorus.com Wed May 27 15:00: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 3D49B3A67EB for ; Wed, 27 May 2009 15:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=0.656, 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 3BsaDXYaDng5 for ; Wed, 27 May 2009 15:00:28 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3C22F28C1B5 for ; Wed, 27 May 2009 15:00:27 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Wed, 27 May 2009 22:02:09 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 27 May 2009 15:02:09 -0700 From: Vijay Devarapalli To: Yoav Nir , "ipsec@ietf.org" Message-ID: Thread-Topic: [IPsec] Some comments about redirect Thread-Index: AQHJ3pz3PXheCyL8SUWCuOtY0AgqFZAqcFVN In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Some comments about redirect 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, 27 May 2009 22:00:29 -0000 Hello, On 5/27/09 12:36 AM, "Yoav Nir" wrote: > Hi. > > I've read through the draft again, and here are a few comments: > > Section 3 has the following line: > > If the > IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, > the responder MUST NOT send the REDIRECT payload to the VPN client. > > > This IMO should apply to all variations, not just to redirect during the > Initial exchange. We could add one sentence at the end of the paragraph. The new one would be 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 payload, the responder MUST NOT send the REDIRECT payload to the VPN client. This is applicable to all REDIRECT scenarios described in this document. Is this is sufficient? > I'm wondering if the REDIRECT notification type should not be allocated from > the error range. It makes more sense, since it always fails the exchange (or > at least part of it - the child SA in the IKE_AUTH exchange) I don't think the REDIRECT is an error message. In some cases, you have to delete the IKEv2 SA. Then there is the gateway-initiated redirect in the middle of a session. > Section 10 sets up an IANA registry for identity types. Couldn't we just reuse > the "IKEv2 Identification Payload ID Types"? There's already IPv4, IPv6 and > FQDN, and additionally KEY_ID for locally meaningful names and a range of > private use IP addresses. Why set up a new registry for the same thing? In addition to what Tero said, I think the current registry "IKEv2 Identification Payload ID Types" explicitly refers to the ID payload. It doesn't say "ID Types". If it had said "ID types", it could have been used for the REDIRECT payload. Vijay From vijay@wichorus.com Wed May 27 15:03: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 462393A6F6F for ; Wed, 27 May 2009 15:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.065 X-Spam-Level: X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[AWL=0.597, 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 0rCCKsUyebnv for ; Wed, 27 May 2009 15:03:13 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 732333A6F2B for ; Wed, 27 May 2009 15:03:13 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Wed, 27 May 2009 22:04:55 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 27 May 2009 15:04:55 -0700 From: Vijay Devarapalli To: Yoav Nir , Tero Kivinen Message-ID: Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTw= In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0522CDF726@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect 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, 27 May 2009 22:03:14 -0000 Hi Yoav, On 5/27/09 3:11 AM, "Yoav Nir" wrote: > OK. In that case I would add to the initial registry > > 4 - locally meaningful name The client should be able to resolve this "locally meaningful name" to an IP address to which it can initiate a new IKE_SA_INIT exchange. These "locally meaningful names" might make sense to the pool of IKEv2 gateways, but would it make sense to the client? How does the client figure out what the new VPN gateway is? Am I missing something? Vijay > > In our product, the gateways have "names" that appear both in the GUI and the > configuration files (and logs). It's easier for them to fetch another > gateway's "object" by name than by IP address. Such a name could be ASCII or > UTF-8. > ________________________________________ > From: Tero Kivinen [kivinen@iki.fi] From ynir@checkpoint.com Wed May 27 15:15: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 C0CEE28C1B5 for ; Wed, 27 May 2009 15:15:40 -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 kXOUxiHOsMDp for ; Wed, 27 May 2009 15:15:40 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8FB1A28C1A7 for ; Wed, 27 May 2009 15:15:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E1C7929C002; Thu, 28 May 2009 01:17:14 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 541EE29C001; Thu, 28 May 2009 01:17:14 +0300 (IDT) X-CheckPoint: {4A1DBAB9-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 n4RMHC3d007471; Thu, 28 May 2009 01:17:12 +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, 28 May 2009 01:17:12 +0300 From: Yoav Nir To: Vijay Devarapalli , Tero Kivinen Date: Thu, 28 May 2009 01:14:16 +0300 Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTwAAFOqHw== Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF72D@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0522CDF726@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: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect 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, 27 May 2009 22:15:40 -0000 The client has to have a PAD that includes the gateways.=20 Our implementation has the client downloading the configuration (by a propr= ietary protocol) that includes the gateway names (and how to find them - IP= address or DNS name). These gateway names can optionally be shown to the = user in the GUI. In any case, the client is as aware of the names as the g= ateways. ________________________________________ From: Vijay Devarapalli [vijay@wichorus.com] Sent: Thursday, May 28, 2009 01:04 To: Yoav Nir; Tero Kivinen Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments about redirect Hi Yoav, On 5/27/09 3:11 AM, "Yoav Nir" wrote: > OK. In that case I would add to the initial registry > > 4 - locally meaningful name The client should be able to resolve this "locally meaningful name" to an I= P address to which it can initiate a new IKE_SA_INIT exchange. These "locally meaningful names" might make sense to the pool of IKEv2 gateways, but would it make sense to the client? How does the client figure out what the new VP= N gateway is? Am I missing something? Vijay > > In our product, the gateways have "names" that appear both in the GUI and= the > configuration files (and logs). It's easier for them to fetch another > gateway's "object" by name than by IP address. Such a name could be ASCII= or > UTF-8. > ________________________________________ > From: Tero Kivinen [kivinen@iki.fi] Scanned by Check Point Total Security Gateway. Email secured by Check Point From ynir@checkpoint.com Wed May 27 15:17: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 6161528C116 for ; Wed, 27 May 2009 15:17:47 -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 inSsRFrvNOjw for ; Wed, 27 May 2009 15:17:46 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5999A3A6AEE for ; Wed, 27 May 2009 15:17:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D609729C002; Thu, 28 May 2009 01:19:12 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 86D4429C001; Thu, 28 May 2009 01:19:12 +0300 (IDT) X-CheckPoint: {4A1DBB2F-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 n4RMJA3d007805; Thu, 28 May 2009 01:19:10 +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, 28 May 2009 01:19:10 +0300 From: Yoav Nir To: Vijay Devarapalli , "ipsec@ietf.org" Date: Thu, 28 May 2009 01:17:23 +0300 Thread-Topic: [IPsec] Some comments about redirect Thread-Index: AQHJ3pz3PXheCyL8SUWCuOtY0AgqFZAqcFVNgAAEQus= Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF72E@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0522CDF724@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 Subject: Re: [IPsec] Some comments about redirect 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, 27 May 2009 22:17:47 -0000 The change is sufficient OK about the status (rather than error) type OK about using a new registry (though I still think you need to allocate th= e "locally meaningful name" and some space for private use) Thanks Yoav ________________________________________ From: Vijay Devarapalli [vijay@wichorus.com] Sent: Thursday, May 28, 2009 01:02 To: Yoav Nir; ipsec@ietf.org Subject: Re: [IPsec] Some comments about redirect Hello, On 5/27/09 12:36 AM, "Yoav Nir" wrote: > Hi. > > I've read through the draft again, and here are a few comments: > > Section 3 has the following line: > > If the > IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, > the responder MUST NOT send the REDIRECT payload to the VPN client. > > > This IMO should apply to all variations, not just to redirect during the > Initial exchange. We could add one sentence at the end of the paragraph. The new one would be 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 payload, the responder MUST NOT send the REDIRECT payload to the VPN client. This is applicable to all REDIRECT scenarios described in this document. Is this is sufficient? > I'm wondering if the REDIRECT notification type should not be allocated f= rom > the error range. It makes more sense, since it always fails the exchange = (or > at least part of it - the child SA in the IKE_AUTH exchange) I don't think the REDIRECT is an error message. In some cases, you have to delete the IKEv2 SA. Then there is the gateway-initiated redirect in the middle of a session. > Section 10 sets up an IANA registry for identity types. Couldn't we just = reuse > the "IKEv2 Identification Payload ID Types"? There's already IPv4, IPv6 = and > FQDN, and additionally KEY_ID for locally meaningful names and a range of > private use IP addresses. Why set up a new registry for the same thing? In addition to what Tero said, I think the current registry "IKEv2 Identification Payload ID Types" explicitly refers to the ID payload. It doesn't say "ID Types". If it had said "ID types", it could have been used for the REDIRECT payload. Vijay Scanned by Check Point Total Security Gateway. Email secured by Check Point From rsjenwar@gmail.com Wed May 27 20:06: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 477B83A68B4 for ; Wed, 27 May 2009 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, 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 gJ-bKdGUsnrX for ; Wed, 27 May 2009 20:06:18 -0700 (PDT) Received: from mail-px0-f125.google.com (mail-px0-f125.google.com [209.85.216.125]) by core3.amsl.com (Postfix) with ESMTP id 6CBDE3A6781 for ; Wed, 27 May 2009 20:06:09 -0700 (PDT) Received: by pxi31 with SMTP id 31so3991159pxi.29 for ; Wed, 27 May 2009 20:07:49 -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=LX4bywvBr/wJH344fo1t8J0HvuVCVZiI0r3PCZemiZw=; b=OuLy/wj+bgFEG5/TF2ovGhvjBc8cRfdAUEqm7TvQTQlmKZ6WA30iysOca8zdw1hU4+ J9SpPsa11HHP/5pZ1E68s+Wouc6BRcnLdEQzzV0OlBugOgn5+95VdRApTNR8HIigEJZg IVwgJtyNjLJToH4akHTM31OR06slQrqNsH2ls= 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=KStXUPywdVnTrtH4kobbd2bT4DxNpw/pJFY3zVvY/Om7MtfwPHApnfPFQ7kIk82N2Y KaTr3MvhKUZtSI1y1rZWt92mwpUa+VVJqkuLtOAxh3K90O/aOQIMIi/RyBmBY4y3EBTV DNZaY61td9kOo/UtBwmIlfbEKArw9bm7DB2yo= MIME-Version: 1.0 Received: by 10.142.43.7 with SMTP id q7mr217005wfq.346.1243480069165; Wed, 27 May 2009 20:07:49 -0700 (PDT) In-Reply-To: References: <7ccecf670905262210u30960243vfe1d7e585babc6b7@mail.gmail.com> Date: Thu, 28 May 2009 08:37:49 +0530 Message-ID: <7ccecf670905272007p72d86312y32d82d7fc07cae7b@mail.gmail.com> From: Raj Singh To: Vijay Devarapalli Content-Type: multipart/alternative; boundary=000e0cd30470ced35b046af0435f Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Questions on ikev2-redirect-10 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, 28 May 2009 03:06:19 -0000 --000e0cd30470ced35b046af0435f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Vijay, On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote: > Hi, > > On 5/26/09 10:10 PM, "Raj Singh" wrote: > > > Hi Vijay, > > > > I have some question on ikev2-redirect-10 draft. > > > > In section 5, > > ------ > > Once the client sends an acknowledgment to the gateway, it SHOULD > > delete the existing security associations with the old gateway by > > sending an Informational message with a DELETE payload. The gateway > > MAY also decide to delete the security associations without any > > signaling from the client, again by sending an Informational message > > with a DELETE payload. However, it should allow sufficient time for > > the client to setup the required security associations with the new > > security gateway. This time period should be configurable on the > > gateway. > > ------- > > > > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect, > > there is a time gap for client to delete old SA and create new SA with > > redirected Gateway. > > > > During this time, IKE REKEY occurs from gateway or client, what should be > > the behavior, should it REKEY on old SA or defer the rekey ? > > The rekey should be deferred. The IKEv2 SA is going to be torn down anyway. Can you make a mention of this in the draft ? According to me, we can make it simple by saying that after REDIRECT, IKE SA will be marked for deletion i.e. we will send/accept only DELETE informational exchange on that SA. > > > > Also, when deleting IKE SA, due to redirect, is there any way to know > that > > this delete is sue to redirect ? > > Well, the gateway redirected the client. If following that, there is a > delete from the client, the gateway would know that the IKEv2 SA is being > deleted because it redirected the client. > > Anyway, does it matter? > It does. There is a time gap between REDIRECT and DELETE for the IKE SA. If any activity happens during that period due to valid reasons ( REKEY, DELETION due to lifetime etc.), we will not be sure what to do ? Also, for administrative purpose we need to know that DELETE happened due to REDIRECT or valid reasons. Accepting only DELETE after REDIRECT solves all these problems. > > Vijay > > Thanks, Raj --000e0cd30470ced35b046af0435f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Vijay,

On Thu, May 28, 2009 at 3:24 AM= , Vijay Devarapalli <vijay@wichorus.com> wrote:
Hi,

On 5/26/09 10:10 PM, "Raj Singh" wrote:

> Hi Vijay,
>
> I have some question on ikev2-redirect-10 draft.
>
> In section 5,
> ------
> =C2=A0=C2=A0=C2=A0 Once the client sends an acknowledgment to the gate= way, it SHOULD
> =C2=A0=C2=A0 delete the existing security associations with the old ga= teway by
> =C2=A0=C2=A0 sending an Informational message with a DELETE payload.= =C2=A0 The gateway
> =C2=A0=C2=A0 MAY also decide to delete the security associations witho= ut any
> =C2=A0=C2=A0 signaling from the client, again by sending an Informatio= nal message
> =C2=A0=C2=A0 with a DELETE payload.=C2=A0 However, it should allow suf= ficient time for
> =C2=A0=C2=A0 the client to setup the required security associations wi= th the new
> =C2=A0=C2=A0 security gateway.=C2=A0 This time period should be config= urable on the
> =C2=A0=C2=A0 gateway.
> -------
>
> Suppose after sending N[REDIRECT] in case of Gateway initiated redirec= t,
> there is a time gap for client to delete old SA and create new SA with=
> redirected Gateway.
>
> During this time, IKE REKEY occurs from gateway or client, what should= be
> the behavior, should it REKEY on old SA or defer the rekey ?

The rekey should be deferred. The IKEv2 SA is going to be torn down a= nyway.
Can you make a mention of this in the draft ? Accor= ding to me, we can make it simple by
saying that after REDIRECT, IKE SA= will be marked for deletion i.e. we will send/accept only DELETE informati= onal exchange on that SA.


> Also, when deleting IKE SA, due to redirect, is there any way to know = that
> this delete is sue to redirect ?

Well, the gateway redirected the client. If following that, there is = a
delete from the client, the gateway would know that the IKEv2 SA is being deleted because it redirected the client.

Anyway, does it matter?
It does. There is a time g= ap between REDIRECT and DELETE for the IKE SA. If any activity happens duri= ng that period due to valid reasons ( REKEY, DELETION due to lifetime etc.)= , we will not be sure what to do ? Also, for administrative purpose we need= to know that DELETE happened due to REDIRECT or valid reasons.
Accepting only DELETE after REDIRECT solves all these problems.
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Vijay

Thanks,
Raj
--000e0cd30470ced35b046af0435f-- From alex@um.es Thu May 28 00:31: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 EDE5C3A6928 for ; Thu, 28 May 2009 00:31:22 -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 8Fj2N5bzETpL for ; Thu, 28 May 2009 00:31:16 -0700 (PDT) Received: from xenon1.um.es (xenon1.um.es [155.54.212.161]) by core3.amsl.com (Postfix) with ESMTP id 3E7DE3A6BE6 for ; Thu, 28 May 2009 00:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon1.um.es (Postfix) with ESMTP id CD5B61612E; Thu, 28 May 2009 09:32:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon1.um.es Received: from xenon1.um.es ([127.0.0.1]) by localhost (xenon1.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b53eeYzrpYHk; Thu, 28 May 2009 09:32:46 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.um.es [155.54.205.224]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon1.um.es (Postfix) with ESMTP id 36C6A16154; Thu, 28 May 2009 09:32:46 +0200 (CEST) From: Alejandro Perez Mendez To: Matthew Cini Sarreo In-Reply-To: <4A1BB112.3010403@strongswan.org> References: <99043b4a0905252343s5e862f6dw497d8f82e27612a1@mail.gmail.com> <4A1BB112.3010403@strongswan.org> Content-Type: text/plain Date: Thu, 28 May 2009 09:32:45 +0200 Message-Id: <1243495965.13651.29.camel@diffie> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2: RADIUS 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, 28 May 2009 07:33:32 -0000 Hi Matt, As commented by Andreas, IKEv2 allows any EAP method to be used. For instance, the OpenIKEv2 implementation (http://openikev2.sourceforge.net) allows you to configure the VPN gateway as an EAP pass-throwgh authenticator, that is, just forwarding the received EAP packets from the client (thought the IKEv2 channel) to the RADIUS server (using RADIUS transport) and vice-versa. On the client side, OpenIKEv2 is easily extensible to add support for any EAP method just by adding a new subclass of the EapClient abstract class. The scenarios would be similar to those indicated by Andreas. Best regards, Alejandro > Hi Matt, > > IKEv2 allows any EAP protocol to be used for VPN client authentication. > Examples are EAP-SIM, EAP-AKA, EAP-MSCHAPv2, EAP-MD5, EAP-GTC, etc. > On the VPN gateway you can just forward the EAP messages to a RADIUS > server. The following sample scenario shows a strongSwan client doing > IKEv2 EAP-SIM authentication with a strongSwan gateway forwarding the > EAP messages to a FreeRADIUS server. > > http://www.strongswan.org/uml/testresults43/ikev2/rw-eap-sim-id-radius/ > > Here is another scenario for IKEv2 EAP-MD5 without EAP Identity: > > http://www.strongswan.org/uml/testresults43/ikev2/rw-eap-md5-radius/ > > Best regards > > Andreas > > Matthew Cini Sarreo wrote: > > Hello All, > > > > My apologies if this has already been asked. > > > > We are interested to have our implementation of IKEv2 to provide support > > for authentication with a RADIUS server. We did this in IKEv1 by > > implementing XAuth. For IKEv2, the only resource that seems to tackle > > this is > > http://www.employees.org/~ddukes/ikev2_cp_dhcp_radius_ietf56.pdf, which > > seems quite old. Is this still valid to use? > > > > Thanks & Regards, > > Matt > > ====================================================================== > Andreas Steffen andreas.steffen@strongswan.org > strongSwan - the Linux VPN Solution! www.strongswan.org > Institute for Internet Technologies and Applications > University of Applied Sciences Rapperswil > CH-8640 Rapperswil (Switzerland) > ===========================================================[ITA-HSR]== > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu May 28 06:07: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 2912C3A6C72 for ; Thu, 28 May 2009 06:07:12 -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 tOeksHNPirnY for ; Thu, 28 May 2009 06:07:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 32D5C3A6884 for ; Thu, 28 May 2009 06:07:09 -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 n4SD8gGD021458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 16:08:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n4SD8e5h020483; Thu, 28 May 2009 16:08: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=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18974.36055.894616.454006@fireball.kivinen.iki.fi> Date: Thu, 28 May 2009 16:08:39 +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: 16 min X-Total-Time: 16 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, 28 May 2009 13:07:12 -0000 Pasi.Eronen@nokia.com writes: > 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. > > 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: > > 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. > > "TBD4" for ESP_NULL_AUTH_AES_GMAC > > (where we will in TBD1..4 after we know the numbers) When I was checking out this thing more I found that we need to do even more for GMAC. The reason is that In IKEv1 the AH_* "Transform Identifiers" MUST include "Authentication Algorithm" attribute also. I.e. it is not enough to just set "AH Transform Identifier" to AH_AES_128_GMAC, but in addition to that the proposal MUST include "Authentication Algorithm" attribute with suitable value. Text from RFC2407: ---------------------------------------------------------------------- 4.4.3 IPSEC AH Transform Identifiers ... Note: the Authentication Algorithm attribute MUST be specified to identify the appropriate AH protection suite. For example, AH_MD5 can best be thought of as a generic AH transform using MD5. To request the HMAC construction with AH, one specifies the AH_MD5 transform ID along with the Authentication Algorithm attribute set to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the following sections. Transform ID Value ------------ ----- RESERVED 0-1 AH_MD5 2 AH_SHA 3 AH_DES 4 ... 4.4.3.1 AH_MD5 ... All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5]. The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826. Use of AH_MD5 with any other Authentication Algorithm attribute value is currently undefined. 4.4.3.2 AH_SHA The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined. All implementations within the IPSEC DOI MUST support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA]. Use of AH_SHA with any other Authentication Algorithm attribute value is currently undefined. ... Authentication Algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4 Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use. There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case. When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal. When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL. ... ---------------------------------------------------------------------- I.e it is not enough to add the AH_AES_*_GMAC values, but we also need to specify the corresponding "Authentication Algorithm" attribute values. As those "Authentication Algorithm" numbers requires more text explaining for example that they are no other Authentication Algorithm than AES_128_GMAC is to be allowed with AH_AES_128_GMAC, this might actually require more than just errata... There is also multiple ways to define those, i.e. we might for example just make one "IPSEC AH Transform Identifier" called AH_AES_GMAC which is used for 3 different "Authentication Algorithms" for different key lengths, or we can keep the current practice which makes one Transform ID to have one allowed Authenticating Algorithm (except for MD5, where the KPDK is also allowed). Actually only AH_MD5, AH_SHA1 and AH_DES restrict valid "Authentication Algorithms", none of the other documents adds such limitations, so actually it would be valid to be using AH_SHA2-256 with Auth(KPDK) or even with HMAC-MD5, in which case I guess HMAC-MD5 algorithm would actually be used... I am not more sure how we should fix this problem, as the deeper we get there the more we need to fix, and we already have solution called IKEv2 to fix these problems... :) -- kivinen@iki.fi From Pasi.Eronen@nokia.com Thu May 28 09:41: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 7545F3A691E for ; Thu, 28 May 2009 09:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 ct2S0UVc7fAR for ; Thu, 28 May 2009 09:41:15 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 97C583A6E38 for ; Thu, 28 May 2009 09:41:01 -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 n4SGGNAU023113; Thu, 28 May 2009 19:16:39 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 19:16:14 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 19:16:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 19:16:03 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 28 May 2009 18:16:03 +0200 From: To: Date: Thu, 28 May 2009 18:16:02 +0200 Thread-Topic: [IPsec] Transform IDs for AES-GMAC in IKEv1 Thread-Index: AcnflXyCSQGy5wTnRT6QHdjIXeA5bgAGU4dA Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AE799F0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D5096@NOK-EUMSG-01.mgdnok.nokia.com> <18974.36055.894616.454006@fireball.kivinen.iki.fi> In-Reply-To: <18974.36055.894616.454006@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 May 2009 16:16:03.0666 (UTC) FILETIME=[990AC320:01C9DFAF] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [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, 28 May 2009 16:41:16 -0000 Thanks for looking into this, Tero! I would propose we just allocate both AH transform identifier=20 and Authentication Algorithm numbers for AH_AES_128/192/256_GMAC. This is what e.g. RFC 3566 did for XCBC-PRF.=20 While in theory it could be nice to have more text explaining how this works, compared to the other ambiguous places in IKEv1 specs, this one looks something implementors would quite likely get right even without the additional explanation.... Best regards, Pasi > -----Original Message----- > From: ext Tero Kivinen [mailto:kivinen@iki.fi] > Sent: 28 May, 2009 16:09 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: [IPsec] Transform IDs for AES-GMAC in IKEv1 >=20 > Pasi.Eronen@nokia.com writes: > > 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. > > > > 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: > > > > 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. > > > > "TBD4" for ESP_NULL_AUTH_AES_GMAC > > > > (where we will in TBD1..4 after we know the numbers) >=20 > When I was checking out this thing more I found that we need to do > even more for GMAC. The reason is that In IKEv1 the AH_* "Transform > Identifiers" MUST include "Authentication Algorithm" attribute also. > I.e. it is not enough to just set "AH Transform Identifier" to > AH_AES_128_GMAC, but in addition to that the proposal MUST include > "Authentication Algorithm" attribute with suitable value. >=20 > Text from RFC2407: > ---------------------------------------------------------------------- > 4.4.3 IPSEC AH Transform Identifiers > ... > Note: the Authentication Algorithm attribute MUST be specified to > identify the appropriate AH protection suite. For example, AH_MD5 > can best be thought of as a generic AH transform using MD5. To > request the HMAC construction with AH, one specifies the AH_MD5 > transform ID along with the Authentication Algorithm attribute set > to > HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the > following sections. >=20 > Transform ID Value > ------------ ----- > RESERVED 0-1 > AH_MD5 2 > AH_SHA 3 > AH_DES 4 > ... > 4.4.3.1 AH_MD5 > ... > All implementations within the IPSEC DOI MUST support AH_MD5 along > with the Auth(HMAC-MD5) attribute. This suite is defined as the > HMAC-MD5-96 transform described in [HMACMD5]. >=20 > The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH > transform (Key/Pad/Data/Key) described in RFC-1826. >=20 > Use of AH_MD5 with any other Authentication Algorithm attribute > value > is currently undefined. >=20 > 4.4.3.2 AH_SHA >=20 > The AH_SHA type specifies a generic AH transform using SHA-1. The > actual protection suite is determined in concert with an associated > SA attribute list. A generic SHA transform is currently undefined. >=20 > All implementations within the IPSEC DOI MUST support AH_SHA along > with the Auth(HMAC-SHA) attribute. This suite is defined as the > HMAC-SHA-1-96 transform described in [HMACSHA]. >=20 > Use of AH_SHA with any other Authentication Algorithm attribute > value > is currently undefined. > ... > Authentication Algorithm > RESERVED 0 > HMAC-MD5 1 > HMAC-SHA 2 > DES-MAC 3 > KPDK 4 >=20 > Values 5-61439 are reserved to IANA. Values 61440-65535 are > for private use. >=20 > There is no default value for Auth Algorithm, as it must be > specified to correctly identify the applicable AH or ESP > transform, except in the following case. >=20 > When negotiating ESP without authentication, the Auth > Algorithm attribute MUST NOT be included in the proposal. >=20 > When negotiating ESP without confidentiality, the Auth > Algorithm attribute MUST be included in the proposal and the > ESP transform ID must be ESP_NULL. > ... > ---------------------------------------------------------------------- >=20 > I.e it is not enough to add the AH_AES_*_GMAC values, but we also need > to specify the corresponding "Authentication Algorithm" attribute > values. >=20 > As those "Authentication Algorithm" numbers requires more text > explaining for example that they are no other Authentication Algorithm > than AES_128_GMAC is to be allowed with AH_AES_128_GMAC, this might > actually require more than just errata... >=20 > There is also multiple ways to define those, i.e. we might for example > just make one "IPSEC AH Transform Identifier" called AH_AES_GMAC which > is used for 3 different "Authentication Algorithms" for different key > lengths, or we can keep the current practice which makes one Transform > ID to have one allowed Authenticating Algorithm (except for MD5, where > the KPDK is also allowed). >=20 > Actually only AH_MD5, AH_SHA1 and AH_DES restrict valid > "Authentication Algorithms", none of the other documents adds such > limitations, so actually it would be valid to be using AH_SHA2-256 > with Auth(KPDK) or even with HMAC-MD5, in which case I guess HMAC-MD5 > algorithm would actually be used... >=20 > I am not more sure how we should fix this problem, as the deeper we > get there the more we need to fix, and we already have solution called > IKEv2 to fix these problems... :) > -- > kivinen@iki.fi From Pasi.Eronen@nokia.com Thu May 28 10:36: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 DB9483A6E87 for ; Thu, 28 May 2009 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 nnhjxcBSOR23 for ; Thu, 28 May 2009 10:36:42 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id F331B3A6CA8 for ; Thu, 28 May 2009 10:36:41 -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 n4SHcGFH002479; Thu, 28 May 2009 12:38:25 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 20:38:14 +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); Thu, 28 May 2009 20:38:09 +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, 28 May 2009 19:38:09 +0200 From: To: , Date: Thu, 28 May 2009 19:38:08 +0200 Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AE79A63@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A6ADCDFBE@NOK-EUMSG-01.mgdnok.nokia.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 X-OriginalArrivalTime: 28 May 2009 17:38:09.0890 (UTC) FILETIME=[114CE420:01C9DFBB] X-Nokia-AV: Clean Subject: Re: [IPsec] Final comments for ikev2-redirect-10 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, 28 May 2009 17:36:49 -0000 Vijay Devarapalli wrote: > In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is > not valid is when EAP is used and the redirect is done based on the > unauthenticated ID. In all other cases, the IKEv2 SA is valid and > should be torn down with an INFORMATIONAL exchange. >=20 > IMHO, this is clear enough and is captured in the current draft. Well.. I'm a bit skeptical about it being clear to folks who didn't participate in writing this draft. And having these two cases is more complex than having just one (IKE_SA is not used for any more exchanges). What benefits does this additional complexity (both=20 in spec and in implementation) get us? If nothing, let's just remove it.... Best regards, Pasi=20 From Pasi.Eronen@nokia.com Fri May 29 11:46: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 341473A67AC for ; Fri, 29 May 2009 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouf6oPUJ-eCz for ; Fri, 29 May 2009 11:46:16 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 544DA3A69A7 for ; Fri, 29 May 2009 11:45:54 -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 n4TIlOfL011523 for ; Fri, 29 May 2009 21:47:32 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 21:46:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 May 2009 21:46:54 +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; Fri, 29 May 2009 20:46:54 +0200 From: To: Date: Fri, 29 May 2009 20:46:52 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFw Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 May 2009 18:46:54.0633 (UTC) FILETIME=[D6407990:01C9E08D] X-Nokia-AV: Clean Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.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, 29 May 2009 18:46:17 -0000 1) First, sending a comment I already sent to the mailing list on=20 March 17: In TLS session resumption, resumption basically creates a new TLS "connection" (using information from local session cache, or ticket in case of RFC5077), and does *not* really resume the old connection. The old connection can still exist (and the session resumption handshake won't cause it to be closed), or it could have been interrupted earlier, or it could have been cleanly closed earlier. The current ikev2-resumption draft, on the other hand, seems to assume a quite different model, where resumption replaces the old connection, and can be done only if the old connection was interrupted. This would seem to preclude one case discussed earlier: I close my laptop (cleanly) at work, commute, and reconnect at home (without having to do EAP again; e.g. type in one-time password). Or "switch off my phone (cleanly), fly to IETF meeting, and switch it back on". In case of IKEv2, having multiple parallel IKE connections is probably less common than with TLS (where it's very common), but to me it seems using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly closed would be quite useful, and should be supported. (And making the "new connection" completely independent of the old one might simplify the protocol anyway.) (Or in other words: I'd propose changing Section 7.2, 1st paragraph, and making these MUSTs MAYs.) 2) The draft is currently very vague about the use cases for this mechanism. As the discussion has shown, there's more than one use case, and folks clearly have different opinions about which of them are important and which are not.=20 However, being vague makes the draft quite difficult to understand for a reader that hasn't participated in the discussions. I think the draft should mention that there are several different use cases, and give concrete examples (but not take an opinion about which of them are important or not). Perhaps something like this (going somewhere in Section 1): Possible situations where the mechanism specified in this document could be useful include the following (note that this list is not meant to be exhaustive, and any particular deployment may not care about all of these): - If a client temporarily loses network connectivity (and the IKE SA times out), this mechanism could be used to re-establish the=20 SA with less overhead (network, CPU, authentication infrastructure) and without requiring user interaction for authentication. - If the connectivity problems affect a large number of clients (e.g., a large remote access VPN gateway), when the connectivity is restored, all the clients might reconnect almost simultaneously. This mechanism could be used to reduce the load spike for =20 cryptographic operations and authentication infrastructure. - Losing connectivity can also be predictable and planned; for=20 example, putting a laptop to "stand-by" mode before travelling. This mechanisms could be used to re-establish the SA when=20 the laptop is switch backed on (again, with less overhead and without requiring user interaction for authentication). 3) Section 1, 2nd paragraph should also mention one additional reason someone might have for using this mechanism (even if roundtrips or CPU time is not an issue): doing the authentication from scratch could require user interaction. 4) Some aspects of the protocol are described very thinly. For example: - Section 4.2 describes what message is sent by the gateway, but not=20 what the client should do when it receives it - Section 4.3 just says the gateway "accepts the ticket", but not all the steps involved in this (there's lot about this in Sections 5 and 6 though) - Section 4.3 says the client initiates an IKE_AUTH exchange, but=20 doesn't say much about how this differs from an ordinary IKE_AUTH=20 exchange (except for AUTH payload) - Section 4.4 it's possible to use N(COOKIE) in IKE_SESSION_RESUME, but nothing else (e.g. in IKE_SA_INIT request, N(COOKIE) must=20 always be the first payload -- but the message diagram earlier puts other notifications at the end. Which is it?) For all of these, I'm sure the authors have some idea how this is supposed to work -- but I don't think the current text is very likely to lead to interoperable implementations. I'd recommend taking Sections 4.1...4.6, 4.8, 5 and 6 and doing a reorganization for that text (Section 4.7 could probably be separate). 5) Section 5 and 6 present roughly the same information, and need to be combined. Currently, the table I sent was just added to the end of the old text (and some of the old text was plain wrong -- for example, the client cannot obviously take the SA value from the ticket). 6) Section 6: The word "Unspecified" is probably wrong here -- this document has to specify these (but clearly an implementation doesn't have to include in the ticket any data it never uses). 7) Section 9.6, "using channel security" sounds like it would refer to the IKEv2 encrypted payloads -- but that would be clearly wrong? 8) The text about handling IDr is very unclear -- certainly the gateway can't start to use some other IDr in the new IKE_SA, without authenticating it? 9) Section 7.1: Why are storing SPIi/SPIr and the authentication=20 method "MUST"s? (The gateway doesn't seem to really need those for anything) Best regards, Pasi From vijay@wichorus.com Fri May 29 14:44: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 D14463A6922 for ; Fri, 29 May 2009 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.324 X-Spam-Level: X-Spam-Status: No, score=0.324 tagged_above=-999 required=5 tests=[AWL=0.237, 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 Nimdmie6KFQa for ; Fri, 29 May 2009 14:44:56 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 077D73A68FF for ; Fri, 29 May 2009 14:44:55 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Fri, 29 May 2009 21:46:38 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 29 May 2009 14:46:26 -0700 From: Vijay Devarapalli To: , Message-ID: Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHAAOwvwhA== In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AE79A63@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Final comments for ikev2-redirect-10 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, 29 May 2009 21:44:56 -0000 Hi Pasi, On 5/28/09 10:38 AM, "Pasi.Eronen@nokia.com" wrote: > Vijay Devarapalli wrote: > >> In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is >> not valid is when EAP is used and the redirect is done based on the >> unauthenticated ID. In all other cases, the IKEv2 SA is valid and >> should be torn down with an INFORMATIONAL exchange. >> >> IMHO, this is clear enough and is captured in the current draft. > > Well.. I'm a bit skeptical about it being clear to folks who didn't > participate in writing this draft. I would be worried if that is the case. But, IMO, the draft currently clearly describes when the IKEv2 SA is valid and when it needs to be explicitly deleted. > And having these two cases is more > complex than having just one (IKE_SA is not used for any more > exchanges). What benefits does this additional complexity (both > in spec and in implementation) get us? > > If nothing, let's just remove it.... When the AUTH payloads are exchanged and verified, the IKEv2 SA is valid. This seems straightforward. We are not doing anything out of the ordinary here by not invalidating the IKEv2 SA just because the gateway sent the REDIRECT payload to the client. I can imagine extensions tomorrow that would let the client convey additional information using the IKEv2 SA to the gateway, after the gateway had sent a REDIRECT payload to the client. Vijay > > Best regards, > Pasi > From vijay@wichorus.com Fri May 29 14:49: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 2035C3A6FD2 for ; Fri, 29 May 2009 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.306 X-Spam-Level: X-Spam-Status: No, score=0.306 tagged_above=-999 required=5 tests=[AWL=0.219, 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 DdluYAUIno3t for ; Fri, 29 May 2009 14:49:09 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 4BC8C3A6C5D for ; Fri, 29 May 2009 14:49:09 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) 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 ; Fri, 29 May 2009 21:50:51 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 29 May 2009 14:50:50 -0700 From: Vijay Devarapalli To: Yoav Nir , Tero Kivinen Message-ID: Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTwAAFOqHwBjw6Aq In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0522CDF72D@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect 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, 29 May 2009 21:49:10 -0000 Ok. Anyone else have any comments on including "4 - Locally Meaningful Name"? Vijay On 5/27/09 3:14 PM, "Yoav Nir" wrote: > The client has to have a PAD that includes the gateways. > > Our implementation has the client downloading the configuration (by a > proprietary protocol) that includes the gateway names (and how to find them - > IP address or DNS name). These gateway names can optionally be shown to the > user in the GUI. In any case, the client is as aware of the names as the > gateways. > ________________________________________ > From: Vijay Devarapalli [vijay@wichorus.com] > Sent: Thursday, May 28, 2009 01:04 > To: Yoav Nir; Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Some comments about redirect > > Hi Yoav, > > On 5/27/09 3:11 AM, "Yoav Nir" wrote: > >> OK. In that case I would add to the initial registry >> >> 4 - locally meaningful name > > The client should be able to resolve this "locally meaningful name" to an IP > address to which it can initiate a new IKE_SA_INIT exchange. These "locally > meaningful names" might make sense to the pool of IKEv2 gateways, but would > it make sense to the client? How does the client figure out what the new VPN > gateway is? > > Am I missing something? > > Vijay > >> >> In our product, the gateways have "names" that appear both in the GUI and the >> configuration files (and logs). It's easier for them to fetch another >> gateway's "object" by name than by IP address. Such a name could be ASCII or >> UTF-8. >> ________________________________________ >> From: Tero Kivinen [kivinen@iki.fi] > > > Scanned by Check Point Total Security Gateway. > > Email secured by Check Point From yaronf@checkpoint.com Sun May 31 01:17: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 388B63A68E4 for ; Sun, 31 May 2009 01:17:24 -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 jL-leieeNr8F for ; Sun, 31 May 2009 01:17:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A7B163A6895 for ; Sun, 31 May 2009 01:17:22 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3194B29C001; Sun, 31 May 2009 11:19:09 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E05E220037B; Sun, 31 May 2009 11:19:08 +0300 (IDT) X-CheckPoint: {4A223C21-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 n4V8J53d023763; Sun, 31 May 2009 11:19: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; Sun, 31 May 2009 11:19:05 +0300 From: Yaron Sheffer To: Vijay Devarapalli , Yoav Nir , Tero Kivinen Date: Sun, 31 May 2009 11:19:04 +0300 Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTwAAFOqHwBjw6AqAEf+1zA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E3CF@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0522CDF72D@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_0208_01C9E1E1.9B1B2B30" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect 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, 31 May 2009 08:17:24 -0000 ------=_NextPart_000_0208_01C9E1E1.9B1B2B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think we should *not* add this type. I don't see how a client and a gateway can agree on such a "locally meaningful name", without non-interoperable protocols (or configuration databases). And I don't think we should add this new concept, of all places, to the Redirect draft. But of course we should reserve a portion of the new ID Type registry for private use. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Saturday, May 30, 2009 0:51 > To: Yoav Nir; Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Some comments about redirect > > Ok. > > Anyone else have any comments on including "4 - Locally Meaningful Name"? > > Vijay > > > On 5/27/09 3:14 PM, "Yoav Nir" wrote: > > > The client has to have a PAD that includes the gateways. > > > > Our implementation has the client downloading the configuration (by a > > proprietary protocol) that includes the gateway names (and how to find > them - > > IP address or DNS name). These gateway names can optionally be shown to > the > > user in the GUI. In any case, the client is as aware of the names as > the > > gateways. > > ________________________________________ > > From: Vijay Devarapalli [vijay@wichorus.com] > > Sent: Thursday, May 28, 2009 01:04 > > To: Yoav Nir; Tero Kivinen > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] Some comments about redirect > > > > Hi Yoav, > > > > On 5/27/09 3:11 AM, "Yoav Nir" wrote: > > > >> OK. In that case I would add to the initial registry > >> > >> 4 - locally meaningful name > > > > The client should be able to resolve this "locally meaningful name" to > an IP > > address to which it can initiate a new IKE_SA_INIT exchange. These > "locally > > meaningful names" might make sense to the pool of IKEv2 gateways, but > would > > it make sense to the client? How does the client figure out what the new > VPN > > gateway is? > > > > Am I missing something? > > > > Vijay > > > >> > >> In our product, the gateways have "names" that appear both in the GUI > and the > >> configuration files (and logs). It's easier for them to fetch another > >> gateway's "object" by name than by IP address. Such a name could be > ASCII or > >> UTF-8. > >> ________________________________________ > >> From: Tero Kivinen [kivinen@iki.fi] > > > > > > 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 > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0208_01C9E1E1.9B1B2B30 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUzMTA4MTkwNFowIwYJKoZIhvcNAQkEMRYEFM6bJ/xdbIaK qcfkHkFOwDiyOFcLMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA IS7u2QLSnurXm6seBlXV+xQ2xeqpmZ77Rv56U5O0lNMM6ujT4DlGBCDkgQ6TlRS0fh43ORT59X3W F07XH7hf9AUGvltzZNuOrfwJk5SwcaPwrZizkMSObo4zzKUE1nIPIUx1wDRHrDk7mzVlzoa3/1Qs JjxbtNVT5bk98a/fS1kFviY0xH2XWXGUyxzRxUU9LsJGwKSkvCElqajGNWvR1Lx/frFBwC/L2bX3 2PXTtLbukCAJgt4Ab2qqPAlWkm0lhqu9ywPzQ+iYyHYKvFDg9Re5GfFH28cxHjUbY3u5cvV6YZMa RPG4d3Pg3iUMTk1oR3re7Nkxuc0rt/yB9JnkqQAAAAAAAA== ------=_NextPart_000_0208_01C9E1E1.9B1B2B30-- From ynir@checkpoint.com Sun May 31 08:07:53 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 9F4753A6B3B for ; Sun, 31 May 2009 08:07:53 -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 XWz0bFDe9Tf5 for ; Sun, 31 May 2009 08:07:52 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B78803A68F5 for ; Sun, 31 May 2009 08:07:52 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C72B8200E12; Sun, 31 May 2009 18:09:39 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7FA1F20037B; Sun, 31 May 2009 18:09:39 +0300 (IDT) X-CheckPoint: {4A229C54-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 n4VF9a3d024181; Sun, 31 May 2009 18: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; Sun, 31 May 2009 18:09:36 +0300 From: Yoav Nir To: "'ipsec@ietf.org'" Date: Sun, 31 May 2009 18:09:34 +0300 Thread-Topic: New Version Notification for draft-nir-ike-nochild-01 Thread-Index: AcniAUPCUPV1Q1CURMKV5hKZv+xUfAAAHa2g Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CE5C04@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: "'denghui02@gmail.com'" , "'rsjenwar@gmail.com'" Subject: [IPsec] FW: New Version Notification for draft-nir-ike-nochild-01 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, 31 May 2009 15:07:53 -0000 Hi all I've submitted version -01 of this private draft with a few of the changes = that Raj has suggested. I'm still not entirely convinced this is a necessary extension, and would l= ike to see whether there is an interest in this. Comments are, as always, welcome. Yoav -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Sunday, May 31, 2009 6:03 PM To: Yoav Nir Subject: New Version Notification for draft-nir-ike-nochild-01=20 A new version of I-D, draft-nir-ike-nochild-01.txt has been successfuly sub= mitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ike-nochild Revision: 01 Title: A Childless Initiation of the IKE SA Creation_date: 2009-05-31 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA. = =20 The IETF Secretariat. Email secured by Check Point From yaronf@checkpoint.com Sun May 31 09: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 3311F3A6B43 for ; Sun, 31 May 2009 09:14:52 -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 vSKV6taiOVFK for ; Sun, 31 May 2009 09:14:50 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D28BD3A6CEB for ; Sun, 31 May 2009 09:14:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 969AE29C001; Sun, 31 May 2009 19:16:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 43F5420037B; Sun, 31 May 2009 19:16:34 +0300 (IDT) X-CheckPoint: {4A22AC02-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 n4VGGU3d008049; Sun, 31 May 2009 19:16: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; Sun, 31 May 2009 19:16:30 +0300 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Sun, 31 May 2009 19:16:27 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAF31gbA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.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_0256_01C9E224.4B7E7AD0" MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.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: Sun, 31 May 2009 16:14:52 -0000 ------=_NextPart_000_0256_01C9E224.4B7E7AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pasi, Thanks for your review. Please see my comments below. Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Friday, May 29, 2009 21:47 > To: ipsec@ietf.org > Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption- > 04.txt > > > > 1) First, sending a comment I already sent to the mailing list on > March 17: > > In TLS session resumption, resumption basically creates a new TLS > "connection" (using information from local session cache, or ticket in > case of RFC5077), and does *not* really resume the old connection. > The old connection can still exist (and the session resumption > handshake won't cause it to be closed), or it could have been > interrupted earlier, or it could have been cleanly closed earlier. > > The current ikev2-resumption draft, on the other hand, seems to assume > a quite different model, where resumption replaces the old connection, > and can be done only if the old connection was interrupted. > > This would seem to preclude one case discussed earlier: I close my > laptop (cleanly) at work, commute, and reconnect at home (without > having to do EAP again; e.g. type in one-time password). Or "switch > off my phone (cleanly), fly to IETF meeting, and switch it back on". > > In case of IKEv2, having multiple parallel IKE connections is probably > less common than with TLS (where it's very common), but to me it seems > using the IKE_SESSION_RESUME handshake when the old IKE_SA was cleanly > closed would be quite useful, and should be supported. (And making the > "new connection" completely independent of the old one might simplify > the protocol anyway.) > > (Or in other words: I'd propose changing Section 7.2, 1st paragraph, > and making these MUSTs MAYs.) > [YS] Let me answer at two levels, the principle of session resumption and the particular use case you present. At the principle level, I think SSL/TLS history, going back to HTTP 1.0, required support of many concurrent "cloned" sessions. Typical use of IKE, at least for RA VPN, is different, preferring a single instance per client. So much so that even the concept of reauthentication was only recognized post 4306 (RFC 4478). Regarding the use case, most security policies will require you to reauthenticate after a logout/suspend. But even if your scenario is legit, I don't see why the current draft precludes the client from implementing this behavior. One interesting use case that would support your view is setting up simultaneous IKE SAs to multiple gateways, with no need to authenticate to each one separately. But that's of course WAY out of scope. Also, I believe your issue is NOT with the MUSTs in Sec. 7.2, it is rather with the last paragraph of 4.3, quoted here: When the responder receives a ticket for an IKE SA that is still active and if the responder accepts it, then the old SA SHOULD be silently deleted without sending a DELETE informational exchange. Consequently, all the dependent IPsec child SAs are also deleted. This happens after both peers have been authenticated. > > 2) The draft is currently very vague about the use cases for this > mechanism. As the discussion has shown, there's more than one use > case, and folks clearly have different opinions about which of them > are important and which are not. > > However, being vague makes the draft quite difficult to understand for > a reader that hasn't participated in the discussions. I think the > draft should mention that there are several different use cases, and > give concrete examples (but not take an opinion about which of them > are important or not). Perhaps something like this (going somewhere in > Section 1): > > Possible situations where the mechanism specified in this document > could be useful include the following (note that this list is not > meant to be exhaustive, and any particular deployment may not care > about all of these): > > - If a client temporarily loses network connectivity (and the IKE > SA times out), this mechanism could be used to re-establish the > SA with less overhead (network, CPU, authentication infrastructure) > and without requiring user interaction for authentication. > > - If the connectivity problems affect a large number of clients > (e.g., a large remote access VPN gateway), when the connectivity > is restored, all the clients might reconnect almost simultaneously. > This mechanism could be used to reduce the load spike for > cryptographic operations and authentication infrastructure. > > - Losing connectivity can also be predictable and planned; for > example, putting a laptop to "stand-by" mode before travelling. > This mechanisms could be used to re-establish the SA when > the laptop is switch backed on (again, with less overhead and > without requiring user interaction for authentication). > > [YS] Agree, pending the above discussion. > 3) Section 1, 2nd paragraph should also mention one additional reason > someone might have for using this mechanism (even if roundtrips or CPU > time is not an issue): doing the authentication from scratch could > require user interaction. > [YS] Yes. > > 4) Some aspects of the protocol are described very thinly. For example: > > - Section 4.2 describes what message is sent by the gateway, but not > what the client should do when it receives it > - Section 4.3 just says the gateway "accepts the ticket", but not > all the steps involved in this (there's lot about this in Sections 5 > and 6 though) > - Section 4.3 says the client initiates an IKE_AUTH exchange, but > doesn't say much about how this differs from an ordinary IKE_AUTH > exchange (except for AUTH payload) > - Section 4.4 it's possible to use N(COOKIE) in IKE_SESSION_RESUME, > but nothing else (e.g. in IKE_SA_INIT request, N(COOKIE) must > always be the first payload -- but the message diagram earlier > puts other notifications at the end. Which is it?) > > For all of these, I'm sure the authors have some idea how this is > supposed to work -- but I don't think the current text is very likely > to lead to interoperable implementations. I'd recommend taking > Sections 4.1...4.6, 4.8, 5 and 6 and doing a reorganization for that > text (Section 4.7 could probably be separate). > [YS] OK. I disagree on some of the editorials (some of the crypto is better off in a separate section), but on the whole I agree and will reorganize the text. > 5) Section 5 and 6 present roughly the same information, and need to > be combined. Currently, the table I sent was just added to the end of > the old text (and some of the old text was plain wrong -- for example, > the client cannot obviously take the SA value from the ticket). > > 6) Section 6: The word "Unspecified" is probably wrong here -- this > document has to specify these (but clearly an implementation doesn't > have to include in the ticket any data it never uses). > [YS] I have used "unspecified" as synonymous with "implementation specific". Or do you want to propose alternative text? > 7) Section 9.6, "using channel security" sounds like it would > refer to the IKEv2 encrypted payloads -- but that would be clearly > wrong? [YS] The ticket is "self protecting". I will reword. > > 8) The text about handling IDr is very unclear -- certainly the > gateway can't start to use some other IDr in the new IKE_SA, > without authenticating it? > [YS] Unfortunately you are right, but this eliminates important flexibility in naming the gateways. We *could* say that the client trusts the gateway to identify itself, because the gateway is clearly a member of the "trusted gateways" group (it is able to decrypt the ticket). But that still sounds wrong. > 9) Section 7.1: Why are storing SPIi/SPIr and the authentication > method "MUST"s? (The gateway doesn't seem to really need those > for anything) > [YS] SPIi/SPIr are used to identify the SA we are resuming (see discussion above). The authentication method seems to be useful, e.g. to know that you should expect a cert to be included. But yes, the auth method could be left implementation-dependent. > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0256_01C9E224.4B7E7AD0 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 BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDUzMTE2MTYyN1owIwYJKoZIhvcNAQkEMRYEFOqWHwio5k95 3/lYwaxKwydtBObfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA C0i+Lklcwz/NDJrpsr2i58CH35VTGes9J36+3FyD3gQAW5sWwr/I9B0ej9LRPPLuzhKPob/4B6QG rOAHHc06mxnwR/KCp1MGPgZIT+JBixOw/s/S60CWoH/+4PBOvDCJ4g8/FpPZSG77KOQAHfWY16Mt hYUuf5IFUomyXeGeDTSk9LlB7+7S+cMRYIQw5wZrucEEzJ1yFQ+9UrY/TWVE7c5glj9mwmo/cjlA QyuCvSMgdF6qLi5y7kPBDhlis7aL2pesoqg7W/yPRehr24JpANs3J/HJio7Y6JahgjPLghjgTIGv 4ceR6QpfkbXvoWnZ8dob5nEIVnRkE3TqoqRwlAAAAAAAAA== ------=_NextPart_000_0256_01C9E224.4B7E7AD0-- From paul.hoffman@vpnc.org Sun May 31 12:21: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 3EDCF3A6C95 for ; Sun, 31 May 2009 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 LJA-og3JaLx4 for ; Sun, 31 May 2009 12:21:24 -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 039553A6E08 for ; Sun, 31 May 2009 12:21:17 -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 n4VJHwGk042776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2009 12:17:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> Date: Sun, 31 May 2009 12:17:34 -0700 To: Yaron Sheffer , "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.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: Sun, 31 May 2009 19:21:25 -0000 At 7:16 PM +0300 5/31/09, Yaron Sheffer wrote: > > 6) Section 6: The word "Unspecified" is probably wrong here -- this >> document has to specify these (but clearly an implementation doesn't >> have to include in the ticket any data it never uses). >> >[YS] I have used "unspecified" as synonymous with "implementation specific". >Or do you want to propose alternative text? FWIW, I think "implementation-specific" is probably right here. > > 8) The text about handling IDr is very unclear -- certainly the >> gateway can't start to use some other IDr in the new IKE_SA, >> without authenticating it? >> >[YS] Unfortunately you are right, but this eliminates important flexibility >in naming the gateways. We *could* say that the client trusts the gateway to >identify itself, because the gateway is clearly a member of the "trusted >gateways" group (it is able to decrypt the ticket). But that still sounds >wrong. Being a member of the "trusted gateways" group doesn't sound wrong to me: in fact, it sounds like the correct way to say it. If that group has just one member, so be it. --Paul Hoffman, Director --VPN Consortium From rsjenwar@gmail.com Sun May 31 20:42: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 9A7883A6CA8 for ; Sun, 31 May 2009 20:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKXPX7j6Uu6u for ; Sun, 31 May 2009 20:42:40 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id A37403A6B27 for ; Sun, 31 May 2009 20:42:40 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so2506410wff.31 for ; Sun, 31 May 2009 20:42: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=+Owr1GT593eXymxOZbPGct2uCe2T+UbdugdU5MyXpC0=; b=LY0lfv/kZXEEVkLLH8Z1GA73ztWfuN0eluBXTAm33h9DG30d1qJfQ6xPmEZWyuhOPD uMbBANBaWTE+vAv5gGUL1+MxZmE4Bmmd8JV8tJfo33e1kImhpzJfNM4teFw3qlMD8n+f JpnzcnPyfHuqT0XYDXp+tq5uFQ7THLthycYLA= 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=RKHMfI7GnMfYWzrmG91V4MVyNTkQLl/uMDQa4p2eW6Kj6ZlmQMmFiopJSrV1BG1B63 jXNcSdsyNiszOAm8mNJB+Rqu1RQ0n3ExwsX9vs8e61wMcn3WqqfICV1ELZaN64lBMHKr cxfQqzyFrUYhJUp5e76h7OUUM+jFELtk4EluI= MIME-Version: 1.0 Received: by 10.142.44.14 with SMTP id r14mr1709703wfr.270.1243827759169; Sun, 31 May 2009 20:42:39 -0700 (PDT) In-Reply-To: <7ccecf670905272007p72d86312y32d82d7fc07cae7b@mail.gmail.com> References: <7ccecf670905262210u30960243vfe1d7e585babc6b7@mail.gmail.com> <7ccecf670905272007p72d86312y32d82d7fc07cae7b@mail.gmail.com> Date: Mon, 1 Jun 2009 09:12:39 +0530 Message-ID: <7ccecf670905312042q1e9b49f4rf07675e03e886813@mail.gmail.com> From: Raj Singh To: Vijay Devarapalli Content-Type: multipart/alternative; boundary=000e0cd15744bf4229046b41373a Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Questions on ikev2-redirect-10 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, 01 Jun 2009 03:42:41 -0000 --000e0cd15744bf4229046b41373a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit A gentle reminder. On Thu, May 28, 2009 at 8:37 AM, Raj Singh wrote: > Hi Vijay, > > On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote: > >> Hi, >> >> On 5/26/09 10:10 PM, "Raj Singh" wrote: >> >> > Hi Vijay, >> > >> > I have some question on ikev2-redirect-10 draft. >> > >> > In section 5, >> > ------ >> > Once the client sends an acknowledgment to the gateway, it SHOULD >> > delete the existing security associations with the old gateway by >> > sending an Informational message with a DELETE payload. The gateway >> > MAY also decide to delete the security associations without any >> > signaling from the client, again by sending an Informational message >> > with a DELETE payload. However, it should allow sufficient time for >> > the client to setup the required security associations with the new >> > security gateway. This time period should be configurable on the >> > gateway. >> > ------- >> > >> > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect, >> > there is a time gap for client to delete old SA and create new SA with >> > redirected Gateway. >> > >> > During this time, IKE REKEY occurs from gateway or client, what should >> be >> > the behavior, should it REKEY on old SA or defer the rekey ? >> >> The rekey should be deferred. The IKEv2 SA is going to be torn down >> anyway. > > Can you make a mention of this in the draft ? According to me, we can make > it simple by > saying that after REDIRECT, IKE SA will be marked for deletion i.e. we will > send/accept only DELETE informational exchange on that SA. > >> >> >> > Also, when deleting IKE SA, due to redirect, is there any way to know >> that >> > this delete is sue to redirect ? >> >> Well, the gateway redirected the client. If following that, there is a >> delete from the client, the gateway would know that the IKEv2 SA is being >> deleted because it redirected the client. >> >> Anyway, does it matter? >> > It does. There is a time gap between REDIRECT and DELETE for the IKE SA. If > any activity happens during that period due to valid reasons ( REKEY, > DELETION due to lifetime etc.), we will not be sure what to do ? Also, for > administrative purpose we need to know that DELETE happened due to REDIRECT > or valid reasons. > Accepting only DELETE after REDIRECT solves all these problems. > >> >> Vijay >> >> Thanks, > Raj > --000e0cd15744bf4229046b41373a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A gentle reminder.

On Thu, May 28, 2009 a= t 8:37 AM, Raj Singh <rsjenwar@gmail.com> wrote:
Hi Vijay,

On Thu, May 2= 8, 2009 at 3:24 AM, Vijay Devarapalli <vijay@wichorus.com> = wrote:
Hi,

On 5/26/09 10:10 PM, "Raj Singh" wrote:

> Hi Vijay,
>
> I have some question on ikev2-redirect-10 draft.
>
> In section 5,
> ------
> =C2=A0=C2=A0=C2=A0 Once the client sends an acknowledgment to the gate= way, it SHOULD
> =C2=A0=C2=A0 delete the existing security associations with the old ga= teway by
> =C2=A0=C2=A0 sending an Informational message with a DELETE payload.= =C2=A0 The gateway
> =C2=A0=C2=A0 MAY also decide to delete the security associations witho= ut any
> =C2=A0=C2=A0 signaling from the client, again by sending an Informatio= nal message
> =C2=A0=C2=A0 with a DELETE payload.=C2=A0 However, it should allow suf= ficient time for
> =C2=A0=C2=A0 the client to setup the required security associations wi= th the new
> =C2=A0=C2=A0 security gateway.=C2=A0 This time period should be config= urable on the
> =C2=A0=C2=A0 gateway.
> -------
>
> Suppose after sending N[REDIRECT] in case of Gateway initiated redirec= t,
> there is a time gap for client to delete old SA and create new SA with=
> redirected Gateway.
>
> During this time, IKE REKEY occurs from gateway or client, what should= be
> the behavior, should it REKEY on old SA or defer the rekey ?

The rekey should be deferred. The IKEv2 SA is going to be torn down a= nyway.
Can you make a mention of this in the draft ?= According to me, we can make it simple by
saying that after REDIRECT, = IKE SA will be marked for deletion i.e. we will send/accept only DELETE inf= ormational exchange on that SA.


> Also, when deleting IKE SA, due to redirect, is there any way to know = that
> this delete is sue to redirect ?

Well, the gateway redirected the client. If following that, there is = a
delete from the client, the gateway would know that the IKEv2 SA is being deleted because it redirected the client.

Anyway, does it matter?
It does. There is a = time gap between REDIRECT and DELETE for the IKE SA. If any activity happen= s during that period due to valid reasons ( REKEY, DELETION due to lifetime= etc.), we will not be sure what to do ? Also, for administrative purpose w= e need to know that DELETE happened due to REDIRECT or valid reasons.
Accepting only DELETE after REDIRECT solves all these problems.
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Vijay

Thanks,
Raj

--000e0cd15744bf4229046b41373a--